Developing a Project Test Strategy

"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.