Home > Articles > Programming

Developing a Project Test Strategy

  • Print
  • + Share This
"Yep, works for me. Ship it." Sorry, but that's not good enough when you're developing software! You need a plan for how to test your code all along the way, and Michael Kelly's whiteboard technique is an easy and inexpensive method.
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.

  • + Share This
  • 🔖 Save To Your Account