How to Automate Testing for Geographically-Distributed Development

Automate and coordinate the process of sharing source code across geographically-distributed teams to make it sustainable.

Policies for sharing source code between groups are much more effective when they are enforced using automation. Automation is important for reducing dependencies on the manual resources required to make source code sharing effective, as well as to make sure that set policies are followed every day, despite human laziness.

Where to Apply Automation

Each development group can leverage automation to document, protect, enhance, and secure the source code for each module.

• Automated enforcement of policies to document public interfaces, parameter inputs, and return values will increase understanding of code by developers who read documentation as well as those who write it.
• The dangers of erroneous modifications or style changes by developers from different groups are mitigated when automation is used to enforce quality and compliance.  Any non-compliant changes are either immediately denied or flagged for review.
• Automation can also verify that unit testing is covering a majority of the source code, and in some cases can even create supplemental tests to expose defects and enhance quality.
• Automated code analysis with the ability to identify custom patterns will expedite the process of one group learning from the mistakes of another.  A source code pattern for a defect in one group can be shared with the rest of the groups and applied against the entire existing code base to find similar errors.

Obstacles to Automation

The key obstacles in adopting automated processes are deployment resources and objections to policy enforcement from individual developers.

Automated tools will take some time and effort to configure to specific environments.  Some code analysis tools are freely available open source, and so is JUnit, the unit-testing framework for Java.  Commercial tools are also available to automate common development policy enforcement, but those require a monetary investment.  Some developers will resist policy enforcement that conflicts with their preferred programming practices.  Naming conventions, possible errors, and unit testing requirements are controversial subjects.  Even though automation helps to make a code base shareable between several distributed teams, the process is not entirely trivial.

Supplementing collaborative development with automation may present the solutions to its own problems.  The investment of time and money is unavoidable, but the benefits will far outweigh the sacrifice once the system is set up and working.  Most automated approaches to enforcing development policy are very customizable.  Stubborn development groups who do not want to conform to a company-wide standard are easily appeased if some exceptions can be made for their group.  Policy needs to be defined in terms of what is mandatory for the entire organization, and what is required only for individual groups.  Developers must verify that their code complies with a policy inherited from the company-wide policy and supplemented with group-specific requirements.  An automated process with the right abilities will address most concerns, but careful planning is important to identify which functionality will be required.

Coordination is Key

Sharing a source code base between development groups requires clearly defined goals.  Developers and managers will stumble across plenty of obstacles during the transition to a shared code base, and many people involved will question the desired benefits.

One obvious benefit is that a unified development process results in similarities in product appearance and functionality.  One group’s shared experiences may prevent other groups from making the same mistakes.

However, the added complexity of each development group relying on code written by other groups will make this level of sharing difficult.  For instance, different groups and cultures tend to favor different programming styles, hindering the tight collaboration and unified development process.  Moreover, development work spread out across multiple time zones will decrease the odds of the full code base building successfully. At any given time, someone somewhere will likely be in the middle of changing something.  When one component does break, whether functionally or with respect to compilation, then every other group that is attempting to build the full code base, or that depends on that one component, will be negatively impacted.

Nevertheless, overcoming these and other challenges of implementing a process for shared development is well worth it, considering the end result of more uniform applications and source code.