Testers Shine on Agile Projects

[article]
Summary:
Agile projects draw testers out of the background and into the spotlight. Testers play a distinctive role and drive product development by creating acceptance tests before any code is even written. Johanna Rothman sets the stage and explains the benefits of giving testers their chance to shine.

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

About the author

Johanna Rothman's picture Johanna Rothman

Johanna Rothman, known as the “Pragmatic Manager,” helps organizational leaders see problems and risks in their product development. She helps them recognize potential “gotchas,” seize opportunities, and remove impediments. Johanna was the Agile 2009 conference chair. She is the technical editor for Agile Connection and the author of these books:

  • Manage Your Job Search
  • Hiring Geeks That Fit
  • Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects
  • The 2008 Jolt Productivity award-winning Manage It! Your Guide to Modern, Pragmatic Project Management
  • Behind Closed Doors: Secrets of Great Management
  • Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People

Johanna is working on a book about agile program management. She writes columns for Stickyminds.com and projectmanagementcom and blogs on her website, jrothman.com, as well on createadaptablelife.com.

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Sep 22
Oct 12
Nov 09
Nov 09