Lessons Learned in Software Testing: A Context-Driven Approach

Chapter 1. The Role of the Tester

What are testers supposed to do for a project? That's the question we address in this chapter. Like many things about testing, the answer may seem obvious or trivial at first glance, but it's not.

A role is a relationship. That means you don't control your role, but you can negotiate it. People expect things from you that might not be reasonable. When you find yourself blamed for a low-quality product (and that will happen), whoever is blaming you probably suffers from role confusion. Maybe they think your job is to beat the product with the Magic Mallet of Quality before it ships, and they think you didn't hit it hard enough.

When you're clear about your role—when you have negotiated it—you have a foundation for setting expectations in any situation that may arise. However, even a clear and appropriate testing role is a demanding one.

Lesson 1: You are the headlights of the project.

A project is like a road trip. Some projects are simple and routine, like driving to the store in broad daylight. But most projects worth doing are more like driving a truck off-road, in the mountains, at night. Those projects need headlights. As the tester, you light the way. You illuminate the road ahead so the programmers and managers, however they bicker over the map, can at least see where they are, what they're about to run over, and how close they are to the cliff. The detailed mission of the testing group varies from company to company. Behind those details, though, ...