Are you here to produce better software?

Pete Deemer, the scrum coach and trainer was holding a question hour for one of the scrum teams in our company. One of the developer expressed resistance to testing code instead of a qa member testing the code.

Previously, the scrum master had repeatedly suggested to this team that developers should do some testing that normally QA does as they have smaller QA capacity. Developers were reluctant to do that.

The team member who brought up this point during the question hour strongly felt that scrum master is pressurizing them to do QA. The team member thought that he does not have the necessary skills (automation etc.) and in spite of that Scrum master is pressurizing the team.

Clearly it was a revolt against developers doing QA. Pete listened to him attentively while he was venting off his strong resistance for testing. After he was done with expressing his anger over the developers being asked to do QA, Pete asked a simple question: "Are you here to only produce code or to produce better software?". Pete further added, "if you think you are here for producing better software, then you should do everything that is needed to produce better software. That includes testing, setting up machines, merging branches etc!"

I think this question is a very important tool to scrum masters. Developers need to think again and evaluate why they are here. If the answer is - they are in the team to produce better software then they should be willing to do all the other stuff that developers generally don't like.

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.