I gave a talk at Manchester Tech Nights about the role of QA in Scrum, and I decided to use this opportunity to write a blog post!
Software QA is a bit of a balancing act. Firstly there’s no immediate profit from our role the way there is for devs, designers, etc. Secondly, there’s the fact that there is going to be a contentious relationship between devs and QA. As much as devs will like having QA on their projects, there’s still the fact that no one likes having their work sent back to them with a ‘nope, you did this wrong/missed this. Try again.’ (Pro-tip, do not send notes like that to your dev teammates, they will hate you. Diplomacy, yo).
Which is one of the reasons I love working with Scrum the way we do. Firstly, being present right at the start of the project (instead of getting a site once its mostly built), is wonderful, both in terms of team building and QA.
First, a quick intro to Scrum:
- Work broken down into sprints of 1-4 weeks depending on project size
- Sprint planning meetings to decide what work to do in that sprint
- Daily scrum meetings to give updates
- Each sprint tackles some of the user stories
So, requirements capture happens at the start of the project, this is then broken down into User Stories, with a business case.
As an Audience Member I want to be able to select a date from a datepicker so that I can quickly and accurately choose a specific date.
Scenario: Use a date popup calendar
Given I am an Audience Member
And there is a webform with a date component
And the date component has a popup calendar enabled
When I view the date field
Then I see a calendar icon next to the field
When I select the calendar icon
Then I see a calendar widget
You see how the story is broken down exactly, into a checklist of sorts for exactly what happens, when, and for whom.
The lead dev (in our case) then breaks those down into Acceptance Criteria. Acceptance Criteria provide boundaries and specifics for each User Story, so everyone knows exactly what this User Story encompasses and what the work entails.
Then, the lead dev and QA have to agree on these Acceptance Criteria. This means QA can flex their natural awkwardness to make sure all angles have been considered.
When both the lead dev and QA agree, the Acceptance Criteria goes to the client for approval. This means most of the awkward questions about how and why and ‘what about x?’ happen here, before any work happens. It means we can make better suggestions as we have a clear idea on what the client wants, when its much easier to fix.
After this approval process has been completed, work starts. Changes made after this point have to go through the approval process again.
This procedure means QA have a test case made against which work will be tested. If work meets the Acceptance Criteria, in theory, it’s ready to go (obviously judgement it used here). The tests can also be used for automatic regression testing.
It also provides a much higher quality of work. Devs have more insight and can offer suggestions to how to meet the client’s needs before work starts.
It encourages better buy-in from the client. They have to engage more in order to get the work going, which means they have to think about their needs as well.
Incidentally this also makes onboarding new staff easier – all the stories are already defined pretty narrowly, the process is defined so explaining it is relatively simple.
This method may seem cumbersome, but it doesn’t take up as much time as you’d think, and in the end, you get a collaborative project (both dev team and client), with every team member engaging to provide the best work possible.
It’s hard work, but its worth it.