Agile Quality Assurance

Posted by mmoore on October 31st, 2006 in General

Agile development processes grow in popularity both within companies and also within successful open source projects.  Agile places a priority on customer feedback and better accommodates the manner in which engineers naturally work.  But what about quality assurance in an agile world?  A few edicts of agile development have a large impact on the way quality assurance operates:

   1. Agile requires quicker and smaller increment releases that steers away from the long QA cycles required at the end of a waterfall process.
   2. Agile requires instant feedback to the development team about the most recent enhancements or fixes.  Development should not move to other tasks until the quality of the previous task is assured.
   3. Agile emphasizes customer feedback.  Customers should play a large role in the quality process and should see the product at least once per iteration.

The quicker and smaller incremental releases and the need for instant feedback to the development team will present the largest challenge to a traditional QA team.  A traditional QA team would demand full-regression testing every time functionality is changed that could impact the system.  The agile process usually cannot afford a week of testing for every iteration.  Developers need instant feedback, and should not continue on new tasks until testing is complete.  For all but trivial software application this quick testing feedback cycle can only be accomplished with automated testing.

Certainly a project can remain agile without automation; if the project has enough dedicated testers to perform full-regression testing as each developer assignment is finished.  For most projects this impractical: ten QA testers waiting for each engineer to finish will usually not be affordable.

Given that automation is almost a certainty in an agile environment, what is the best approach to automation of testing?  Usually the first line of defense is unit tests created by engineers.  A unit test will force engineers to prove that new code works properly and will also create a development atmosphere where code is better designed in order to allow it to be more testable.  Even with unit tests in place, when all components are placed together, the resulting integration may fail.

Automated functional tests are the next line of defense in assuring quality and providing quick feedback to the developers.  It is my opinion that functional tests should be added as new features are completed, but in most case not added until the customer has approved of the latest features. Once fully automated unit tests and functional tests are in place, full-regression testing becomes turn-key.  If full regression testing cannot be automatic and quick, then the project may not fit into the agile paradigm.

Bookmark: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • del.icio.us
  • digg
  • Reddit
[Trackback URI]

Comments are closed.