Developing a Project Test Strategy
- Why You Need a Test Strateg
- Getting Started
- Keeping It Simple: Whiteboard Planning
- Implementation
- References
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Why You Need a Test Strategy
I recently worked on a project in which I needed to develop a test strategy from the ground up. When I arrived on the project, the developers were attempting to follow a broken waterfall lifecycle. What that really meant was that development took place on a mostly ad hoc basis. The team had just doubled its number of developers (to about a dozen), and was in the process of exploring a more iterative approach with parallel development efforts. One novice tester, struggling to keep his head above water, provided the only testing for the project. At the same time that I arrived to help with testing, the team was hiring a new project manager and an architect, and was taking on very aggressive release commitments for the remainder of the year. Does this dismal situation sound familiar? I'm guessing it does, because this is not the first time I've encountered it.
The first order of business (besides learning where the nearest Coke machine was in relation to my cube) was to develop a test strategy. What is a test strategy? It depends on whom you ask. For the purposes of this article, we'll look at the test strategy as the objectives of all the test stages, test techniques, and test tools that apply to the project. Most importantly, the test strategy should help in facilitating the communication of the test process and its effects on the entire project team.
To guide our efforts in developing our test strategy, management was experiencing specific problems and was looking for some ways to solve them:
Lack of test repeatability—the project was doing little to no regression testing
Lack of test visibility—no metrics were gathered, and the only criterion for releasing code was the deadline
Reactive build process—they did builds in response to project emergencies, without anticipating the needs of other build contributors
No control over test environments or test data
No unit or integration testing or code reviews after code moved to production
No automation of simple processes or tests
This is the story of how we defined and implemented a test strategy for this project.