Solving Problems
These are just some of the various lessons I've learned, gathered from years working on various automated testing programs. But it's not an exhaustive list. How should you deal with the problems you'll encounter? In Automated Software Testing: Introduction, Management, and Performance, my co-authors and I discuss the following test improvement process: As part of its culture, the test team needs to adopt an ongoing iterative process focusing on lessons learned. Such a program encourages test engineers to raise corrective action proposals immediately, when such actions could potentially have a significant effect on test program performance. Test managers, meanwhile, need to promote such leadership behavior from each test engineer.
The metrics that are collected throughout the test lifecycleand especially during the test execution phasewill help pinpoint problems that need to be addressed. Consequently, the test team should periodically "take a pulse" on the quality of the test effort. This will help improve test results, whenever necessary, by altering the specific ways that the test team performs its business. Not only should the test team concentrate on lessons learned for the test lifecycle, but it should also point out issues pertaining to the system development lifecycle.
Lessons you have learned, metrics evaluations, and any corresponding improvement activity or corrective actions need to be documented throughout the entire test process in an easily accessible central repository. A test team intranet site can prove very effective in maintaining such documentation. For example, lessons learned could be documented using a requirements management tool database, such as DOORS. Keeping an up-to-date database of important lessons learned provides all individuals on the project team with the ability to monitor the progress and status of issues throughout the project. A test team intranet can also make lessons learned available to all software professionals within the organization.
The test manager needs to ensure that records of lessons learned are viewed as improvement opportunities. The records, for example, should not list the names of the individuals involved in the particular activity. Each record should include at least one corrective action that suggests how the process or process output can be improved.
When lessons learned and metrics evaluation sessions take place at the end of a system development lifecycle, it's too late to take any corrective action for the current project. Nevertheless, lessons learned that are recorded at this stage can help to improve future test efforts; so it's still worthwhile for the test team to document lessons learned, even at this late stage. The time and energy you invest in recording what you've learned will pay off on your next project.