Imagine this scenario: Your organization has moved to cross-functional, project-based teams, and you, once a developer, are now a project manager. You understand how to make development work, but testing is like a black box. Until now, you thought testing was something that other people—those in the testing group—did. Now you're responsible for the testers' effectiveness. What do you do?
Understand Testing for What It Is
Testing is one of the least understood parts of a project. Successful project teams recognize that testing is a continuum and is a part of everyone's role.
Not everyone on the team tests at the same level or for the same information. Testing provides information about the product, and it is the first feedback to the developers. That's all. It doesn't ensure or prove anything. Testing helps people (the developers, the testers, the managers, the customers) understand what the product does and how well it does it.
What You Need to Know About Testing
Project managers need to realize that only people can do everything above the line in the testing continuum (see figure 1 below). People read work products, using any of the reviewing techniques: inspections, reviews, walkthroughs, buddy reviews, or pairing. Since only people can perform this work, project teams tend to postpone work product review, unless it's built into how people do their work (like pairing), or if the time to do this work is built into the project schedule. The more serial the lifecycle, the more project managers need to help the team make time to do work product review, because it's the earliest feedback about the project's progress anyone can get.
|Figure 1: A testing continuum diagram from Manage It! Your Guide to Modern, Pragmatic Project Management.|
One of the most valuable services the project manager can deliver to the project is to ask about all the testing that needs to happen below the line in the testing continuum in figure 1. All the below-the-line testing is testing that can be automated (not that all of it should, but it's possible for much of it to be automated).
The project manager, along with all the other managers and the testers, needs to assess the cost of automation against the value the automation provides. For example, automating unit testing makes sense because automated unit tests help developers recognize if they've made a mistake as they add code. However, automating integration testing may not make as much sense depending on how you integrate. If you integrate small pieces every hour or every day, you might not need to automate the integration testing because your unit testing is likely to find broken areas. If you integrate only once a week or less frequently, chances are quite good you will break pieces of the system as you integrate; so automated tests might help. (As with any advice about automation, this is dependent on your product and how short your projects are. Your mileage will vary.)
Automating system-level testing (especially below the GUI) can provide the team significantly valuable information. If you have a troublesome feature area, or are adding more features to an area of the product, automating feature-level testing can also provide valuable feedback to the product team.
Project managers need to work with the other people on the project to see which kinds of testing the entire team is doing and how well that testing is supplying information about the product—which they can't do if they don't know much about testing.