Lessons Learned in Software Testing: A Context-Driven Approach

Chapter 8. Managing the Testing Project

Managing a testing project is like managing any other kind of project—in some respects. But there's at least one special feature of a testing project: It's driven by the programming project. What you do is a reaction to what they do. That's why using a tool like Microsoft Project to plot the tasks of testing can be so frustrating. You have to squint pretty hard to fit the work of your team into those little Gantt bars. In this chapter, we review the lessons we've learned about the dynamics of testing projects and how to control them.

Lesson 157: Create a service culture.

Project teams develop software in order to provide benefits to customers. The customers might be in-house or external, paying or nonpaying. The customers might be the same people as the developers (for example, when we build our own tools).

Testers provide services to the overall project. A typical service is finding and reporting bugs. Other services depend on your group's mission (see Chapter 1, "The Role of the Tester").

One of the fundamental issues running through the testing literature and the testing subcultures is whether your role is primarily service or control:

• A service provider controls the quality and relevance of the services he provides to the larger effort to develop the end result. We provide excellent services to people who need them.

• A service provider does not control the quality of the end product, does not control the processes used by other service providers ...