Don’t Treat Agile Like Mini-Waterfalls

Attended a meetup recently where the gentleman seated to my left complained about the futility of following the Agile methodology. Turns out, he was Director of QA at a company in the healthcare space, where he and his team had been struggling with a newly introduced (forced?) Agile process mandated by the CIO. Apparently, the issue was that his team always got the short end of the stick with not enough time to complete their testing, causing half the items in an iteration to slip. I asked him to describe the process his company was following.

“Well, we start the sprint with a planning meeting. The development manager and I work out the estimates for the user stories provided by the product manager. We have 4-week sprints where the developers write code for the first two weeks. Next, my team tests it for a week and a half and then performs regression and load test for the remaining days. After that we do a demo followed by a retrospective and then start the next sprint. Oh yes, we also have daily stand-ups during the sprint.”

I was stunned. There isn’t anything even remotely Agile about the process he was describing. It was a classic Waterfall model couched in terminology straight from an Agile cookbook.

  • The managers do the planning. Where is the team that will actually do the work? Do they have any insight into the requirements or input into the estimates? If not, it is not Agile.
  • The product manager provides the user stories. Do the user stories translate into defined implementation units? If not, it is not Agile.
  • The developers write code for the first two weeks. In this period, are the testers simply writing test cases and waiting for developers to throw the code over the wall? If so, it is not Agile.
  • The QA team performs testing for the remaining two weeks. In this period, are the developers sitting and twiddling their thumbs waiting for the testers to break their code? If so, it is not Agile.
  • If the QA team is slipping behind on testing, are they reporting it during the daily stand-ups? What is being done about it?

Waterfall + Stand-ups ≠ Agile

Simply breaking a project into 4-week sprints and following the mechanics of the process does not make it Agile. Neither does using all the right sounding labels. There are too many software groups out there trying to gain from the ability for adaptation and flexibility with Agile but without changing the top-down management culture and upgrading skill-sets on the team.

In an Agile environment, the focus for a QA team needs to change from breaking the code to collaborating with the developers and preventing breakage. The testers need to be involved upfront in the planning and gain a solid understanding of the user stories. Once the sprint starts, they need to start developing acceptance tests in parallel with the coding for each user story. When a developer finishes coding, running the acceptance test should provide rapid validation of the user story. There should be no walls between developers and testers and no one should throwing anything over them.

Several tools are available to support acceptance testing, many of them based on the Framework for Integrated Testing (Fit). Apart from this, it is also very helpful to integrate with a build automation tool such as Maven so you can setup a periodic (usually nightly) build process and run an automated acceptance test suite on it.

For more information on improving your QA capabilities in an Agile environment, read this great post by Liz Hendrickson on Agile-Friendly Test Automation Tools/Frameworks.

This entry was posted in Agile. Bookmark the permalink.

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s