blogpost-img14

One of the biggest surprises in an agile environment is that you can have completed code at the end of your two-week sprint and still not cross the finish line. What’s the problem? Testing. You know you’re supposed to test at the end of each sprint, but with goals to meet, it’s tempting to rush past QA. The problem is you’re not reaching your goals if you’re not testing, and bypassing QA comes with extra costs. Here’s what you need to know.

Developers have a short memory.
In order to finish your sprints on time, you may find yourself putting off testing until later. “Later” becomes a month or two, and suddenly QA is reporting issues, but your developers can’t remember what they wrote all those weeks ago. They also didn’t do the necessary documentation, so fixing the bugs slows down the project and costs additional labor. As one person said, “We say we’re doing agile but what we’re really doing is waterfall without documentation.”

QA will never be less understaffed than they are now.
You’ve got fifteen developers and, while you should have seven or eight QA people, you only have two. You keep putting off testing until QA has more bandwidth, but that day never arrives. Now it’s the end of the project, QA is more overloaded than ever before, and it’s time to release. You do the minimal amount of testing and cross your fingers that everything else works as it should.

Rework costs more than you anticipate.
Now that you’ve rushed through testing, your software is on the market and bugs are being reported on a daily basis. You’re looking at months of rework, costing you unexpected time, labor and money. You aren’t alone: The NIST (National Institute of Standards and Technology) has estimated that software defects cost the U.S. economy nearly $60 billion a year*. And of course, correcting a bug after release costs exponentially more** than fixing it during QA, which is still more expensive than catching the bug during coding.

In agile, testing isn’t a “nice to have” to be done after the goal is met; it’s an essential part of meeting the goal. To be successful you have to change what you’re working towards.

Aim for completed functionality, not completed code.
In true agile, the only way to achieve your goal is with completed functionality—i.e., potentially releasable code that does what the business owner requested. Completed code doesn’t require testing, but completed functionality does. By making testing part of the criteria for reaching your goal, you ensure that your progress in each sprint is real.

Don’t be afraid to move the finish line.
If you can’t reach completed functionality during the typical two-week sprint (whether because of a lack of resources or a particularly challenging project), reset your expectations and find the level at which agile can be successful. Extend sprints to four weeks or reduce your goal from 20 to 10 points per sprint. But be consistent and remember: Only completed functionality earns points, not completed code.

Committing to the agile process and working towards functionality requires discipline, but in the long run you’ll find your efforts rewarded—with lower costs, greater efficiency and a much stronger end product.

Sources:

  • Computerworld
  • Codeguru

For more QA best practices, download our free ebook: Breaking Agile’s QA Bottlenecks

 

By Randall McCroskey July 30, 2014
Tags: EnterpriseIndependent Software VendorIndustriesMobileQuality Assurance