Incremental, Agile QA

Incremental QA is highly desirable in Scrum. Scrum does not distinguish between development and QA as in waterfall model. It expects that the product feature you are working on is designed, developed and tested by the end of a sprint - One sprint does it all.

Here are some important characteristics of incremental QA:

1. QA developers are part of the team. Scrum does not distinguish between QA developers and other kinds of developers. They all are part of the same team and are equally responsible for the success of the sprint. The team is cross functional.


2. Builds are given to QA more frequently. Daily builds are recommended. We have even delivered builds twice or thrice a day depending on the issues QA has found. If the issue is simple to fix, fix it and deliver the build immediately. Your build process must be capable of delivering a build to QA in a short time.
   


3. QA develop automated tests while developers are coding user stories. These automated tests will be used in the current sprint as well as in future sprints for regression tests. Tools like Selenium and Fitnesse are used to achieve high degree of automation.


4. Close coordination is required between developers, release engineers and QA. As new features are completed, the changes must be pushed to QA environments as soon as possible so that QA can begin. This means you need to have an efficient process to create QA environments. As soon as a bug is detected, it should be communicated to developers and developers should deliver the fix as soon as possible.


5. Sometimes, partial testing is done. A developer may not be able to complete an entire story at once. He/she may deliver whatever has been completed to QA - may be 70% of the requirements. The developer communicates this to QA and expects QA to test only the portion completed.


6. Developers take up testing tasks, if necessary. They can test their peer's code if there aren't enough QA engineers available to accomplish the testing required for the sprint.

If your team is getting QA done in a way described above, you may pat your back as you have achieved the holy grail of incremental, efficient and agile QA.

How to fit QA in Scrum Sprints

Many scrum teams have a tough time accommodating QA in the same sprint. They end up creating separate QA sprints and staggering it with development sprints. Thus development happens in one sprint and QA in the next. So agile, isn't it? In the true spirit of Scrum, stories should be finished with the necessary testing in the same sprint.

Here is how it happens. Let's say our sprint length is 3 weeks. We have two dedicated QA persons assigned to our project. They are a part of the team. First two weeks developers keep working on their code (and unit tests) and QA persons play ping-pong. In the third week developers start delivering code to QA. Now suddenly our QA has work! As all the tests are manual, one week doesn't suffice. Some stories get demonstrated in the sprint demo without testing! The remaining QA work then gets included in the next sprint. They finish the remnant work in a week and again play ping-pong for one week. Thus the staggered cycle continues.

There is only one way to break this cycle – QA automation. Automating tests with a tool like Selenium saves testing time considerably. It increases test development time, but it reduces testing time considerably. Thus when developers are coding, QA persons can develop automated tests instead of playing ping-pong. Once developers start delivering code to QA, all QA has to do is run the automated tests!

I have been playing with Selenium recently. It's really a great open source tool for QA automation. I found Selenium RC very useful for web based applications as it allows automated tests to run in various browser environments - Firefox, IE etc. Furthermore, Selenium tests can be developed in Ruby, Java, Javascript, Perl, PHP, Python and even .NET! QA can choose the easiest option for them.

Handling QA in Scrum environments requires a paradigm shift. Many companies don't have QA persons with coding skills. In such environments developers need to step up and develop automated tests. Gone are the days when a person went manually through each and every page of your website. Scrum requires much more efficient QA and thankfully Selenium-like tools provide the necessary technology.