Human Interaction During Testing on Two Continents
Thomas M. Cagley Jr.

Audio Version on SPaMCAST 175 

Testing is the means of proving that the development process has understood and built what was required.  In its purist form it provides a set of proofs that validate the ‘whole’ development life cycle.  Regardless of the test model used there is one overriding goal; to deliver the best product possible within the constraints of time, budget and scope.  Meeting the goal of testing requires a strong level of interaction and communication between the testing and development teams.  This requirement becomes an imperative when testing occurs on two continents.


One day I woke up to a gorgeous sunrise then the phone rang and I inherited the testing component of a development project.  The project was well along, with development nearly complete with the external system and user testing looming.  Development and testing were to be done on two continents.  In a nutshell, the project was troubled (the usual cast of characters were at work; over budget, late, feuding sub-teams and subject to runaway requirements).  Reviewing how the testing had been distributed had to be reviewed to determine whether the most efficient use of the project’s limited remaining resources was occuring.  Of course this begged the question whether resources could be redistributed.  As soon as I heard the words; project, testing and soon, a mental assessment checklist popped to mind:


  • Had test planning been performed and reviewed (and by whom)?
  • Could the test cases actually prove the requirements?
  • Had the developers been a party to the creation of these cases?
  • Had user acceptance tests been defined when the stories were created?
  • What were the criteria for acceptance (functionally, quality and date)?
  • When was the last time that the test managers (and/or the project manager) actually talked, rather than emailed each other?
  • What was driving the current project delivery date?
  • Could I impact how the work had been distributed (sources and teams)?
  • Was there a phone list of project participants?
  • What time was it inIndia?


Testing is a human activity built on communication and interaction both with the project deliverables and the participants.  My first stop was the world clock at ( and then the phone list.  The test plan was my third stop.  If done correctly it would provide the basis to synchronize the test teams.  The test plan is a core management communications and negotiation tool.  The plan compiles and communicates the information about testing activities to provide a common way for all involved parties to understand and track test activity.  The plan lines up resources so that even a manager can know what will be done, when it will be done and who will do it.  The critical components of a test plan to drive multiple testing groups on two continents are:


  • An overall statement defining the minimum level of testing that will be acceptable.
  • Test ownership
  • The application components and subcomponents with their relationships
  • A test schedule (with effort, duration and resources)
  • The test metrics
  • The acceptance criteria
  • The communication plans


Defining the minimum level of testing for the project creates a baseline, a tool to define what the quality goal of the project really is and then to resist cutting testing below a level that would meet the goal.


In any project it is important to determine the types of tests to be done.  Examples include regression testing, usability testing, system testing to name a few; however, when testing is done with more than one team it is imperative to determine who will be responsible for each test.  A single point of contact is (or at worst a single team) must be identified to lead and be responsible for a specific test.  Note, this does not mean that only one team can be involved just that someone needs to be in charge.  Determining ownership is best driven by its relationship to the development lifecycle, unit testing is best owned by the development team. Understanding the relationship between types of tests and the development lifecycle is an important piece of knowledge in the ownership decision process.  Oversight of the process should always be driven by the organization that sourced the project.  This is critical to making sure communication and information flow can be managed.


Components and the schedules are related items.  Knowing the components and subcomponents of the application being built or modified and their relationships provides the knowledge needed to create a road map to plan testing and for building a schedule for actually performing the test.


Metrics provide a means to monitor testing while in progress, rather than simply relying on verbal status.  Verbal status, while important, can easily be misinterpreted or represent progress that is out of date.  Metrics provide information and knowledge that cuts across any cultural boundaries.  The metrics should describe software functionality tested, degree of code coverage and progress against a schedule which are core management issues.  Publishing test metrics provides a language to synchronize not only the test teams but the project team, as a whole regardless of organization or culture.


Acceptance criteria serves two purposes.  First, acceptance criteria define when a project is complete.  Second, if created and documented early in a project (before coding to take a page from the agile methodologies) they serve as a communication tool for validating requirements.  The definition of acceptance criteria must be led by the organization owning the project and ‘users’, all parties should participate but ownership stays at home.  Acceptance criteria provide a language of acceptance that cuts across communication barriers.


Providing a plan for the compilation and communication of complete information about the plans, progress and problems for testing allows both continents to provide support and anticipate changes in their own schedule. Interaction, communication and knowledge are important components to making testing happen and becomes even more important when more than one team is involved or when testing done on two continents.  With adequate information, testers are better able to plan and perform their tasks more efficiently and to get an accurate picture of the system. Did I mention communication was important and that it must happen over the entire project life cycle?


Testing is frequently unpredictable, and unpredictability, the bane of managers, creates painful schedule surprises and Maalox moments. This is especially true when multiple teams in multiple locations with multiple cultures are involved.  Communication and coordination based on planning that combines all of the different perspectives of testing and system development  (schedules, functionality, code and problem resolution) makes it is possible to understand and manage software testing.  Defining how to source testing is important to all outsourced projects, the test plan or test architecture is a decision making tool and a tool to synchronize activities between sources.  Communication based on a plan lets you manage the testing process on one continent or two rather than to allowing  it to manage you.