Managing the Testing Process

Opening the Black Box

by managers, developers, and the testers themselves, work can be done to head problems off while they are still small. This in turn ensures that the testing group is better prepared for the software and that the software is better prepared for testing.

Organizations can avoid last-minute quality issues by addressing testing problems earlier in the process, when they are still small. Doing this requires better insight into a project than what can be gotten from a Gantt chart. During test development, management needs to know the status of test planning and preparation to properly gauge the readiness of the test team to test the software. This knowledge comes from understanding

  • the relationship between the software functionality and the testing to be done on that functionality
  • the relationship between the software design and the tests expected to verify that software
  • specific problems the tests are intended to address

It is not just management that needs to know this information. Software developers and testers also need to be able to see and work with this information, and to understand the parts that are relevant to their own work. With adequate information, testers are better able to plan and perform their tasks more efficiently, and to get an accurate picture of the system. For example, it is not uncommon for a set of unmeasured functional tests to repeatedly test one part of the code, while partially or completely missing other parts. In addition, feedback and questions from testers can help to prevent problems later as inconsistencies and inaccuracies are found. Likewise, the developers are able to anticipate potential problems with either the software or the tests, and work with the testers to address these before they have a significant impact.

While testing is in progress, results should be measured in terms of software functionality tested, degree of code coverage, progress against schedule, and problems found. Usually these factors provide a much clearer picture of the status of the testing (and the overall quality of the software) than how long the testing has been running.

Compiling and communicating complete information about test activities provides a common way for everyone on the project to track test activity progress. Testing status needs to be presented to each member of the team in a way that is understandable and that lets them make the best decisions possible. The project manager needs to have a comprehensive view of the progress of test preparation and execution, understanding at a global level what tests are being designed, what tests were run against different versions of the software, what areas of functionality are affected by significant bugs, and what parts of the code will be affected by the bugs that have been found. Developers need to have information specific to their part of the software process, knowing what tests will touch on their area, what problems have been found in their area, how significant those problems are, and what testing has actually been done on their software. Testers and QA staff need to have a different, but similarly detailed view of the system. In short, each person on the project has a different role, and so each needs information that is appropriate to their function.

To support these different needs, different levels of detail in each of the following categories must be provided to each group.

  1. Schedule: What tests will be run? When will the tests be ready? How much effort will it take? When will it be complete?
  2. Functionality: What requirements will be tested and where? How will tests divide up application requirements? How much of the functionality has

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.