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.

Meetings v/s Mailing Lists

Some companies have a meeting oriented culture. They summon a meeting to solve each and every problem, however simple the problem may be. A meeting for designing a database table, a meeting for reviewing code, a meeting for clarifying a story, a meeting for getting extra RAM in your computer etc. If you try to measure the amount of time spent by employees in meetings per week, it might surprise you. Meetings are an inefficient way of discussing a topic. I prefer to discuss issues via mailing lists over calling for meetings. I and a friend of mine - Ken Weiner came up with the following advantages of mailing lists:

• Mailing lists are more productive, people don't have to repeat what they said as they get enough time to digest it.

• Email keeps track of the entire conversation. Some wikis such as Confluence also have a way of archiving a mailing list to make it searchable.
  

• Every person gets enough time to read the email and respond to it. In a meeting, one might not get enough time to respond.

• In multi-location environments, mailing lists are the best ways to keep everybody informed about everything. That's how the entire open source development works. Video conference / conference calls may not be feasible every time.

• Attending a meeting consists of higher context switching. You might be in your best productive time and you have to drop everything to attend a meeting. I personally hate to do that.

• In meetings some personalities can overpower others because of their voice, posture or even position etc. Mailing list avoid such overpowering.

• Sometimes uninterested parties attend meetings for the sake of attending. Discussing a topic on mailing list can certainly avoid this. The uninterested person can simply delete the email by looking at the subject.
  

Try to discuss as much as possible on mailing lists instead of calling for a meeting. Mailing lists can serve as an excellent reference for future. Some collaboration tools such as CollabNet can even capture emails sent with an issue number in the subject as a comment to the issue. Tools such as Crucible will help you in doing efficient code reviews. Wikis can help you discussing a topic as well as archiving a mailing list. As soon as you start your Scrum project, you should setup a mailing list for all the stakeholders. You will be pleasantly surprised with the results.