January 11, 2011

What Software Managers Should Know About Testing in Agile Projects (Part 1)

Test Management
We’ve all read the horrifying statistics around IT project failure—they fail often and sometimes spectacularly! Yet enterprises must continue to build, deliver, and support applications to meet business opportunities. As an alternative to curling up in the fetal position when faced with this dilemma, Agile methodologies and iterative delivery have evolved to address this very problem. Rapidly delivering a few features at a time makes it possible to break a big project down in to smaller and more manageable pieces. It also enables users to validate the software at each iteration, and allows for mid-course corrections to be easily made in response to changing business needs.

Tester’s Dilemma

Testing has always been a weak link in Agile. Traditionally, testers analyze requirements and determine what and how to test while developers are coding the requirements. With Agile, there are no formal requirements and there is no period of down-time while testers wait for testable functionality. In an Agile environment, testers have learn to work from user stories—brief descriptions of how users envision working with the software—and they need to figure out what and how to test pretty quickly. Burning Computer Case Of course, quality remains important no matter how you develop the application, and testers are now faced with a dilemma. How to adapt to these shortened release cycles without compromising on their duty in ensuring the quality of every release? I’d like to say something on this topic, here and in a couple of follow-up posts later this month. I’ll also be expanding on each of these topics as well as providing more insight on Agile testing practices in the A Software Manager’s Guide Defining Testing for an Agile Age webinar on January 19. It’s clear to me that testers have to reinvent their craft in this age of Agile, and here are three general guidelines that should help software managers ensure that testers get involved in Agile projects, and continue to make a real difference in software quality.
  1. Get your testers involved early.
  2. Make your testers first class participants in the project.
  3. Automate testing processes and activities.

Get Testers Involved Early

This one seems like a no-brainer. However, we consistently see organizations where the testing team retains their location at the end of the release cycle, even after the move to Agile. This doesn’t work on long Waterfall projects and it’s not going to work for your 3-week iterations either. Testers need to be part of the up-front dialogue when the product owner is prioritizing backlog, and as the team starts their release planning sessions. In particular, testers have to work extensively with the product owner and get an in-depth understanding of the user stories. Often these stories, which are short and to the point, have unstated assumptions and objectives that need to be teased out through greater interaction with the product owner and user community. Only by fully understanding the user stories can testers prioritize testing and ensure that the user needs are met. To learn more, and ask questions on this topic, register to attend my A Software Manager’s Guide Defining Testing for an Agile Age webinar on January 19.