“Bug prevention is the testing’s first goal” – B.Beizer
Beizer stated that “the act of designing tests is one of the most effective bug preventers known,” which extended the definition of testing to error prevention as well as error detection activities. This article gives insight into the power of early testing.
Most of the testers find bugs weeks/months after the designers and developers inject the bug into the product. How many testers proactively engage with their development partners to prevent the bug from ever getting into the product in the first place? If we continue to think of testing as an after-the-development process then our role is nothing more than a bug finder.
To advance our discipline of testing, the testers need to partner with the developers earlier in the lifecycle to move quality upstream and prevent issues. One of the most powerful ways of improving the quality of the product and the team effectiveness is to focus the testing efforts on defect prevention rather than defect detection. This doesn’t negate or eliminate the need for testing. Testing for defect detection alone is like simply treating the symptoms of the problem and ignoring the root cause of the real problem. Defect prevention is about addressing the real problem.
Here are some of the ways for the tester to work in a symbiotic relationship with the developer and move quality upstream:
The test plan defines the scope, approach, resources and schedule of the intended testing activities. It identifies the features to be tested, the testing tasks and who will do the tasks.
The three main elements of a test plan are:
The Test Plan contains the following:
The scheduling of the testing tasks and milestones is done considering the below factors:
Each of these factors could be rated as high, medium or low.
For large projects, there will be a single test strategy document. There will be many test plans that draws its content from the test strategy. The Test Strategy is a high level document that defines the testing approach to achieve the testing objectives. It is prepared by the project manager and it will not be updated often. The test plan is derived from Software Requirements Specification, Technical Design Document, and Functional Specification Document. It includes test strategy/test approach as well. It is prepared by the test lead. The test plan needs to be updated often to reflect any deviation from the original plan.
Credit: Jurvetson (flickr)
If a feature is not to be tested the test plan should state why it is not. For ex: It could be: a low risk feature, tested and found to be stable in the past, not pushed in the current release.
There are several inherent software risk factors in a project like complexity or newness. A well rounded test plan notes all the risks and tasks interdependencies in the test plan and communicates to the stakeholders regarding those dependencies and risks. Dependencies could be like cross-functional impact of a new feature, delay in getting stable builds, late change in original requirements, late delivery of fix and resource availability.
Once the test plan is documented it requires review and approval by the test manager /release management team in order to move the next phase of testing.