A Project Manager Described his Recent Agile Project in this Way:
Agile practices helped us know where we were the whole way through the project, but we had a side benefit I hadn't anticipated. The testers drove the project. In every other project I've managed, the testers were downtrodden, always complaining about the time they had left to test. But here, the testers defined the acceptance tests and helped the customer define her requirements. A couple of times the testers even explained risks to the customer. In one case, the testers told the customer that postponing a specific user story was tantamount to not putting the user story in this release.
I wasn't surprised. When I've seen testers fully participate on any project, they shine. Agile projects push testers into leadership roles. Projects that don't require tests before the code exists can easily push the testers into a background role. If you've ever been on a project where the developers didn't quite meet their deadlines but the schedule didn't slip to meet the testers' needs, you were on a project where the testers were pushed into the background. On those projects, it doesn't really matter what the testers provide for information; there isn't enough time in the schedule for anyone to hear or act on the information anyway.
Contrast those projects with agile projects. On an ideal agile project, the project team discusses the user stories to roughly estimate the time it will take to implement each one. The customer ranks the user stories (1,2,3,4, and so on) to determine which user stories the project team will approach in this iteration. (If you don't have access to real users, use a surrogate, such as a product manager.) Then, before a single line of code is written, the testers write acceptance tests with the customer.
The developers can discuss how they might implement the user story, they may even prototype to discover any of the system-level "gotchas" before implementation, but they can't write any production code until the acceptance tests are complete. Testers write system level acceptance tests to drive the product development. The developers implement only enough code to pass the tests.
Some people get stuck here. "What do you mean we write tests before the product exists? How the heck do we do that?" One technique is to think of concrete examples of how the system will work. Say you're testing an elevator for a four-story building. The user story says the elevator comes when the user presses the button. Rather than "elevator response time shall be such-and-so," you think of one or several worst cases for response time (everyone presses a button with the elevator in a particular position).
Then define the response time for that worst case scenario. This scenario leads to questions about other scenarios, and therefore more tests. Those tests are easy to write before the implementation, and they tend to get written in essential terminology, which clarifies the business domain in people's minds. The tests help the developers start on their design, so that they create a product that meets your specifications.
One major side effect of this write-the-test-first doctrine is that the tests are as easy to automate and maintain as the code. The project staff and the customer start discussing the domain model in the code. The testers (with the customer) write the tests in domain terms, the developers write the code, draw mockups as GUI specifications, write the GUI code to the mockups, then test the GUIs manually. (Some people do develop GUIs test-first, though, instead of mockup-GUI-manual.) Because the domain