Extreme Programming Quality Assurance

Extreme / agile programming practices change how QualityAssurance (QA) is done.

Overview of the Agile / Extreme Development Process With QA

ExtremeProgramming moves QA from the back end of the project to the front. QA helps customers specify the system behavior in terms of automated AcceptanceTest scripts that can be run at any time, by anyone on the team, including the customers.

More specifically, customers are responsible for articulating what they want and providing feedback on a) the results of the AcceptanceTests and b) the early-version releases they see. Early versions are complete, reliable, products that have gone through QA and thus can be released; they are early only in that they lack all the features to make them fully useful.

QA helps the customers articulate their needs, and QA then helps automate those needs in AcceptanceTests. QA can also use their tech knowledge to come up with additional tests, especially of how the software reacts to unexpected input or behavior.

Then the programmers develop to those tests.

QA thus becomes pro-active rather than reactive.

Anecdotal evidence says that most teams like this approach once they use it: QA folks are less stressed, and developers get more frequent releases to customers.

In summary:

Customers: What's needed, what's the business value, when do we need it, which features have highest priority?
Developers: What's needed, how can I build this, how can I test my code, how long will each feature take?
QA: What's needed by the customers, how can I test whether developers have done it?

QA closes the loop, assuring everyone that what was asked for was what we got.

Do we still need a QA person?

Yes. QA help customers automate the AcceptanceTests. They also think outside of the box of how to develop tests that no-one else would think of.

Testimony: "I don't know if it is because I work on larger projects - but on all of the projects I've worked on developer tests were just not enough. QA folks have a way of breaking anything we build :c)"

How XP can address some common complaints about QA

Problem: Developers fail to write requirements or fail to involve QA in writing them.

How XP Alleviates: XP de-emphasizes traditional requirements documents -� only a loose overall plan needs to be written up. Instead, for each 3-week iteration, specific UserStories are coded on cards, and QA helps users create AcceptanceTests for each UserStory. We know the requirements have been met when the acceptance tests pass. QA becomes part of the development effort. The effort, StoryPoints, required to complete a UserStory includes the effort needed to create and execute the acceptance test. With XP, requirements are much more changeable, it's okay for the UserStory to change in a future iteration.

Problem: Some apps are released without QA because they are urgent.

How XP Alleviates: In XP, releases are more frequent (ReleaseOften), and the highest-priority functionality is released first. Smaller chunks of code are easier to test, and because testing is automated, it is quick to test them. In short, users get the most important functionality more quickly, even with QA.

Problem: Programs are often difficult to install, configure, & test. Developers forget which libraries and settings their program depended on.

How XP Alleviates: XP advocates frequent builds on a build machine, ideally DailyBuild and ContinuousIntegration. Frequent builds on a clean machine force developers to be more aware of the installation process. On the very day that their app requires an extra component that they forgot to script in the install, the build breaks. Because the feedback is immediate, the developer can more easily isolate which component they added.

Problem: Testing is boring.

How XP Alleviates: In XP, tests are automated and easy to run; more importantly, they are written early on as a guide to design. Read "Test Infected" (http://junit.sourceforge.net/doc/testinfected/testing.htm) about how programmers can learn to love writing UnitTests. Customers are motivated to design acceptance tests with QA because these tests give them constant feedback on the status of the project. Tests are only boring when a) they are done after the interesting design work is done, as a laborious add-on, and b) they must all be done by hand, so testers just feel like "monkeys banging on keyboards."

Or, if you prefer a good book without the marketing fluff, read TestingExtremeProgramming.

For a wiki-based AcceptanceTesting framework, see http://fit.c2.com

Hmm. QualityAssurance is not the same as Testing. QA is concerned with processes, Testing (or Verification and Validation) is concerned with products. In other words, Testing examines the Widgets as they fall of the assembly-line, whereas QA examines the steps taken to produce those Widgets.

This page talks about Testing (SystemTesting as opposed to UnitTesting). I'd be very interested to hear how QA is affected by XP.

And before you ask, yes I know that most people in practice don't make the distinction between Testing and QA.

Oh, I've just found a page on it: QualityAssuranceIsNotQualityControl. Although I find QC a bit too easy to mistake for QA.

Perhaps this rant should be taken to QualityAssuranceIsNotQualityControl.

NicolaiCzempin

CategoryTesting