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.
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.
Creating Career Development
So, if everyone needs to know about peer review, unit test frameworks, integration testing, smoke testing, and system-level testing, what's a project manager to do? New project managers don't necessarily have all this knowledge, but if they manage the developers and testers in a project-based team, they will still need to learn so they can help each team member with career development opportunities.
I'm not a fan of certifications, so I don't advocate people being sent to certification courses to learn how to do a particular form of testing (or project management, for that matter). Instead, consider team-based learning. Select some books that explain peer review or testing of some sort, read them chapter-by-chapter one week at a time, and then discuss them in team meetings. Have each person try something from each chapter once a week. In the course of a year, you can get through three or four books, applying what the books suggest. Since you're learning as a team, you've helped everyone learn and apply something new—a form of career development. (The cost of all the books for everyone on your team is significantly less than the cost of a certification class.)
If you don't like the idea of team-based learning, consider reading the books yourself. It's harder and less likely you'll be able to get through everything in a year, but it might be worth a try.
An alternative to reading books is attending experiential workshops. If you have the money, bring in an expert to train your staff in some form of testing. The best way to do this is to have the expert train your staff and then, immediately after the workshop, help the team members apply their newly discovered knowledge to their products with the expert's help.
Another option is to consider sending your entire team to a conference. At a conference, you'll each have a chance to try different tutorials and attend different talks. If you meet as a team in the evenings to debrief, you can select the tutorials and experts you like best.
Whatever you choose to do, make sure you don't try to learn everything yourself and then “teach” it to your team. As the project manager, you will run out of time and then you'll be ignoring everyone's need for learning and career development.
Project-based teams can help the organization develop and finish great products faster than matrixed or functional teams. But they place an extra burden on the project manager not just to manage the project, but also to manage her learning curve. Consider what you and the team members need to know, and consider leading the team in learning and applying that learning to your project. Everyone's career will soar.
© 2007 Johanna Rothman. This article was originally published on Stickyminds.com.
Like this article? See the other articles. Or, look at my workshops, so you can see how to use advice like this where you work.