Don’t Skimp on Software QA; It’s Not Agile

There are two major schools of thought around quality assurance (QA) testing. The waterfall crowd appends QA to the development process while the agile crowd integrates QA into the process, sort of.

The waterfall approach has an obvious problem. If defining and writing the code takes longer than planned (very likely) and the schedule is inflexible (also likely), QA will have precious little time to test.

I’ve seen this play out time and time again. Some QA managers fight for the time allocated in the schedule even if it means late delivery. They often lose that battle. Most QA managers have learned that resistance is futile and they do the best they can in the limited time they are given. Poor quality software is the result.

The agile approach is better in that QA takes place during every sprint or iteration. Thus testing takes place throughout the development process not just at the end.

A similar problem manifests itself, however, in that testing is often done at the end of the sprint. Again, if the stories take longer to implement than planned, QA is left with little time to test. At least there is an opportunity to do more testing in the next sprint but that is not the best way to run agile projects.

Why Not Eliminate QA?

What if we eliminated QA as a separate effort? Toss it. What would happen?

The developers would no longer have QA to back them up. They wouldn’t be able to blame QA for missing a bug. They’d have to think more about testing and take more responsibility.

Problem solved? Not really. You see, it is difficult to test the code you designed and wrote. You are too invested in the solution, too familiar with the algorithms. This causes developers to miss defects simply because they ‘never thought of that’.

An independent viewpoint is needed

So what should you do? The answer is partially cultural. Does your company strive for high quality or is good enough sufficient? Does it focus on user needs or is it assumed that managers know best?

If you really care about quality and user needs, here are a few guidelines:

  1. Agile QA must be as tightly integrated into the development process as possible.
  2. Agile code creation and testing must be concurrent.
  3. The smaller the code, the simpler and faster it is to test. Keep stories very small so that they can completed in one day or less. (There will be exceptions but keep them to a minimum.)
  4. Build in time for regression testing and automate it (if you don’t, you’ll never keep up with the testing load on a large project).
  5. As the software gets bigger, regression and integration testing may become huge efforts especially if there are multiple development teams. You may need to establish a parallel testing team to keep up. (They keyword is ‘parallel’ and they must be synchronized with the development team(s).)

Agile software development isn’t a shrink-wrapped process. You need to adapt it to your situation so that the rest of the company will adopt it.

Updated: January 27, 2011 — 10:50 pm

1 Comment

  1. Vin, I absolutely agree with your guidelines, and especially love your last paragraph.

    “Agile software development isn’t a shrink-wrapped process. You need to adapt it to your situation so that the rest of the company will adopt it.”

    A common failure when implementing agile is that people don’t take the rest of the companies process into consideration. So even when agile works really well, sometimes folks worked in this “development bubble” to deliver the code better than ever before but ignore everything else that goes on around shipping a product. I believe it takes some big picture thinking and planning to really institutionalize this methodology into a company culture. That’s when it pays off big for the business.

Comments are closed.