Home > Articles > Programming

Developing a Project Test Strategy

Michael Kelly
  • PrintPrint
  • Share ThisShare This
  • DiscussDiscuss
"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.

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 ThisShare This
  • Your Account

Discussions

Make a New Comment

You must log in in order to post a comment.

Related Resources

Jennifer  BortelWin FREE iPhone Developer Books and Videos- Introducing @InformIT Giveaways
By Jennifer Bortel on February 5, 2010 No Comments

Apples’s recent iPad announcement made our hearts flutter so we couldn’t resist making an announcement of our own!

Today marks the first ever @InformIT Giveaway!

We’ll regularly post a video like this one profiling spectacular prizes we’re giving away—from books and videos to T-shirts and other exciting stuff. Check out the video below to see the giveaways for today, and then scroll down for more prize details and instructions on how to win them!

Dustin Sullivan"Every OSX developer should have this book on their desk."
By Dustin Sullivan on February 1, 2010 No Comments

That was the sentence Mike Riley ended his recent Dr Dobb's CodeTalk review of Cocoa Programming Developer's Handbook with.

David ChisnallCocoa Tip of the Day, 1/29/10
By David Chisnall on January 29, 2010 No Comments

Don't ignore old versions of OS X.

See All Related Blogs

There are currently no related titles. Please check back later.

Informit Network