Your Agile Source
 

For Project Managers

    Our Blog
    Read Online
    Read Offline
    Tools
    Events
    Resources
    Have Questions?

For Developers

    Our Blog
    Read Online
    Read Offline
    Tools
    Events
    Resources
    Have Questions?

For QA Professionals

    Our Blog
    Read Online
    Read Offline
    Tools
    Events
    Resources
    Have Questions?

    Agile PM/Development/QA

Saturday Jul 31, 2010

Quality Assurance in Scrum

At my recent presentation on Scrum, several QA professionals questioned quality of the software developed in sprints.  They cited two reasons for their concern:

1. How can there be few or no bugs if there is no big QA effort at the end of the sprint, right before the release is completed?

2. Since the emphasis is on the working software, and not on documentation (i.e. test scripts), how can QA make sure that everything is tested?

Here's the reality:

1. In a sprint, testing goes on all the time.  I cannot stress it enough.  As features are volatile throughout the sprint, any piece of functionality can be easily tested several times over.  And if any bugs are found, it will trigger re-testing once they are fixed or the feature will not be considered completed.  Add to that the fact that co-dependent features end up triggering additional testing on each other, and you end up with significantly better coverage than in a traditional approach where a typical feature will only be tested once (that's if testing wasn't cut short due to scheduling pressures).  The reason there is no big testing in the end, is because it's no longer needed, given all the testing that goes on throughout the sprint.

2. The emphasis is on working software - that's true.  However, it doesn't mean that there can not be any documentation.  The key here is knowing when test scripts add value and when they don't.  This is different from many traditional approaches, where test scripts are required whether it makes sense to have them or not.  Scrum is very specific on doing things that add value to the process, so if there are complex scenarios that are better communicated through a test script - go ahead and produce it.  What's even more important is that in Scrum, QA is involved all throughout the process - they participate in the same meetings as developers and they work with developers on daily basis.  Therefore, their understanding of features to be tested is greatly enhanced.  That's what makes it much less likely that test scripts will be needed.


 
Copyright © 2010 SmartEdge LLC. All Rights Reserved.