The Tester s Role in Up-Front Activities

The Tester's Role in Up-Front Activities

The tester's contribution in planning for an XP project (or any software development project) is often overlooked. Consider the following experience of Lisa's:

My team once started a project without me. I was offsite on another contract when a project involving a new external customer began. They figured they could get through the initial Planning Game and first iteration without a tester. After all, they were senior Java developers, with years of experience on a wide variety of projects and several months doing XP. However, things didn't turn out quite the way they expected. Here's the story in the words of the team captains, Natraj Kini and Steve Collins:

"One realization that we came to was the importance of a full-time tester to keep the developers honest. When we didn't have a full-time tester for the first iteration, we got 90% of every story done, which made the client very unhappy during acceptance tests they perceived that everything was broken. When a developer attempted to take over the role of creating acceptance tests, we also found that there was a lot more to the art and science of acceptance testing than we had realized." (Natraj Kini and Steve Collins, "Steering the Car: Lessons Learned from an Outsourced XP Project")

This project team learned that leaving the tester out until later in the project was a painful experience. The programmers were motivated to learn more about testing, so they could do a better job of delivering value to the customer. Lisa learned that as a tester, one of her most important functions is to transfer her testing skills and experience to the rest of the team.

It's true that even if they never put a tester on the project, a team would probably learn how to do a better job with the acceptance tests after a few painful iterations. Whether they learn to do it well enough to satisfy the customer depends on the team. In the case of Lisa's team, the customer was unhappy enough after that first iteration to consider canceling the project. Why risk that if you don't have to?

What kind of thinking could lead to leaving the tester out at the start of a project in the first place? We think it would go something like this:

The tester runs tests, which requires the code, of which hardly any exists until the end of the first iteration, and possibly not a whole lot then. Therefore, the earliest we really need the tester is the end of iteration 1. That's only a day or two before the beginning of iteration 2, so how much trouble can we get into in 24 hours?

Several assumptions here are questionable, and in Exercise 1 we'll ask you to identify them, but they start with the assumption that the tester's main contribution is running tests.

We're not denying that running tests and reporting the results are an important part of the tester role. As Kent Beck writes in Extreme Programming Explained, "An XP tester is not a separate person, dedicated to breaking the system and humiliating the programmers. However, someone has to run all the tests regularly, … broadcast test results, and to make sure that the testing tools run well."

As a tester, you may spend more time running tests and reporting results than performing any other single activity. But just because it absorbs such a chunk of your time and effort doesn't make it the most important thing you do. For instance, driving across the country takes a lot more time and effort than filling up the gas tank beforehand, but try leaving that step out and see how far you get!

Okay, we have half the answer to question 1: Does a tester have a role in release planning? We say, "Yes, and it isn't running tests." So what is it?