E-MailHUMAN INTERACTION DURING TESTING ON TWO CONTINENTS
by Thomas M. Cagley, Jr.
Testing is the means of proving that the development process has understood and built what was required. In its purest form, testing provides a set of proofs that validate the "whole" development lifecycle. Regardless of the test model used, there is one overriding goal: to deliver the best product possible within the constraints of budget, scope, and time. 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 and the external system and user testing looming. Development and testing were to be done on two continents. In a nutshell, the project was troubled: over budget, late, and plagued by runaway requirements and feuding subteams. 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, if so, by whom)?
- Were there test cases that actually proved the
requirements?
- Had developers been party to the creation of
these cases?
- Had user acceptance tests been defined?
- What were the criteria for acceptance
(functionality, quality, and schedule)?
- When was the last time that the test managers
(and/or the project manager) actually talked rather
than e-mailed one another?
- What was driving the current project delivery
date?
- Was there a phone list of project
participants?
- What time was it in India?
Testing is a human activity built on communication and interaction involving both the project deliverables and the participants. My first stop was the world clock at www.timeanddate.com/worldclock, 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 the following:
- An overall statement defining the minimum level
of testing that is acceptable
- Test ownership
- The application components and subcomponents with
their relationships
- A test schedule (including effort, duration, and
resources)
- The test metrics
- The acceptance criteria
- The communication plans
Defining the minimum level of testing for the project creates the baseline: that is, a tool to define what the quality goal of the project really is. Then the job is to resist cutting testing below a level that would meet the goal.
In any project, it is important to determine the kinds of tests to be done. Examples include regression testing, usability testing, and 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. An individual point of contact -- or, at worst, a single team -- must be identified to lead and be responsible for a specific test. Note that this doesn't mean that only one team can be involved but that someone must be in charge. This is critical to ensuring that 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 roadmap to plan testing and to build a schedule for performing the test.
Metrics provide a means to monitor in-progress testing rather than simply relying on verbal status. While important, verbal status can easily be misinterpreted or represent progress that is out of date. Metrics provide information and knowledge that cuts across any cultural boundaries. Metrics should describe software functionality tested, degree of code coverage, and progress compared with a schedule; these are core management issues. Publishing test metrics provides a language to synchronize not only the test teams but the project team as a whole.
Acceptance criteria serve 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. Acceptance criteria provide a language of acceptance that, again, 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 of making testing happen and become even more important when more than one team is involved or when testing is done on two continents. With adequate information, testers can plan better, perform their tasks more efficiently, and get an accurate picture of the system. And did I mention communication was important and that it must happen during the entire project lifecycle?
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 the different perspectives of testing and system development (schedules, functionality, code, and problem resolution) make it possible to understand and manage software testing. Communication based on a plan allows you to manage the testing process on one continent or two rather than letting it manage you.