QA & Scrum

Becoming an agile development team brings many challenges. A common one is how to integrate QA into the process. Scrum, with its focus on rapid delivery, does not sit comfortably with a traditional QA last approach.

What is wrong with doing QA last?

At first glance, it can be difficult to see what is wrong with doing QA after the sprint has ended. After all, this is shippable software so we should test it before releasing to production. However, let’s consider for a moment what happens when we find an issue after the sprint has ended.

A defect raised after the sprint will go into the team’s backlog as a bug. This bug will then need to be triaged and fixed in a future iteration. When this happens, the velocity calculation will be wrong. We will, in effect, be carrying points forward to later sprints.

A further downside to this approach is that by the time the developers get around to fixing the bug they have moved on to other stories, so the code is not fresh in their mind. It is even possible that the system has already changed meaning that the problem might not exist anymore!

All of this leads to trouble in planning and slows our team down, which is the exact opposite of what we want from Scrum.

How do we fix this?

Automation is the first step in integrating test and development in Scrum. If you do not already have a set of automated tests that you can run reliably and complete in few hours or less, then this should be your first goal.

Once you have your automated testing in place the next step is for your testers to begin working closely with the developers to test features as soon as coding is complete. I highly recommend co-locating developers and testers to encourage closer teamwork.

It is vital that both developers and testers understand that testing a story is a joint responsibility and developers should not move onto a new feature until the tests are complete.

The role of the tester

In Scrum, the role of the tester becomes more technical than traditional QA, and you will need to plan for this.

There may be training that is required; not all testers will have the vocabulary to communicate efficiently with the developers. Some of the existing QA team may not know how to create and maintain the automated tests.

A final point to be aware of is that not everyone will welcome this change. QA managers may feel that they are losing control of their departments and individual testers may not want to change the way that they work.

Such resistance is unfortunate but often occurs during an organisational change and will need careful management if the implementation of Scrum is to succeed.

The outcome

Although the transition may not be smooth, it will be worth it. Fostering a culture of “one team” and shortening the test cycle will lead to better engagement of employees and a rapid turnaround of shippable software.