What is your testing strategy?
The design of a testing strategy is primarily a process of identifying and prioritizing project risks and deciding what actions to take to mitigate them. A good testing strategy has many positive effects:
- Establishes confidence that the software is working as it should, which means fewer bugs, reduced support costs, and improved reputation.
- Provides a constraint on the development process which encourages good development practices.
Too often we run into projects with poor testing strategies that rely on the following principles:
- Testing is something that should be treated as a distinct phase of the project, generally towards the end of the project before releasing the application.
- Testing should be carried out by specialists.
However, anyone who has worked in projects that follow the above broken testing strategy know by now that it is a recipe for low quality products.
A good testing strategy should assign the responsibility of carrying out testing to everybody involved in delivering software and should be practiced right from the beginning of the project and throughout its life. Such strategy acknowledges the fact that testing is a cross-functional activity that involves the whole team, and should be done continuously from the beginning of the project.
The right testing strategy builds in by writing automated tests at multiple levels (unit, component, and acceptance) and running them as part of the deployment pipeline, which is triggered every time a change is made to your application, its configuration, or the environment and software stack that it runs on.
Manual testing is also an essential part of building quality in: Showcases, usability testing, and exploratory testing need to be done continuously throughout the project.
These tests do not just test the functional aspects of the system. Capacity, security, and other nonfunctional requirements are established early on, and automated test suites are written to enforce them. These automated tests ensure that any problems that compromise the fulfillment of these requirements are caught early when the cost of fixing them is low.
We think that this ideal world is fully achievable in projects that adopt the appropriate discipline early on. If you need to implement them on a project that has already been running for some time things are probably a little more difficult, but by no means impossible.