We talk a lot about developers in agile processes but sometimes almost forget about testers. They are usually rather calm and silent people, so they pass through all the project launch meetings and then come to me to ask the important question “Agile is great…But what should I do with my testing activities? What is the role of QA in agile processes?”
As usual, I start my answer with “Folk, it really depends… Let’s see what we might do this time”. So, I will try to describe what we tried and how we failed/succeeded.
We vs they
The starting point to looking at Agile principles from the tester’s point of view is to treat testing as the activity, not the phase of the project (“And then we will be testing all that stuff…”) When we start thinking about testing as the activity we have a chance to see, that testers are not the only people performing it. ALL the team is participating. Agile principles force us to forget about the practice of writing code and pushing it to “Testing department”, forgetting about it until the bugs start appearing in the bugtracker. We used to push the code to testers feeling that “it is their job now, I am done”.
Agile team gathers to produce a quality product and developers work in tandem with the testers. One of the tester goals is to provide the early and fast feedback. Here comes the automated tests and all test cases they create for the user story.
The moment team members stop pushing the problems/tasks from one to another, feeling relief when they get rid of the problem – the real team starts its life. Without that you are just a group of people, where the PM is a clay, that makes it all not to fall apart, moving from one developer to another, pushing, beating and threatening them) If someone in the team does not wont to be with you, as the team – you should let him go. Yes, we are all working in the times, when recruiters can spent several months finding the developer for the position, but the wrong person on the place can bring much more harm then you’ll get from lacking one of the developers. So try to be strong.
Quality product as soon as possible
According to the agile principles team works to produce the quality product as soon as possible – not in the end, when we pass the testing phase, but adding a block by block, ensuring the regression tests are green.
But here we have a mismatch in the between development and testing synchronization. Often user stories come to the testers only in the end of the sprint. Testers have the hard days in the end of the sprint, trying to process all the ready for testing user stories and, as a result PO gets not tested user stories. The team leaves the testing to the next sprint, testers do the job thoroughly and post a lot of bugs, developers start fixing them and take that time off the new user stories they started working on in this sprint. As a result – the new user stories are not finished, as the developers were slowed down by the bugfixing and managed to finish them only before the demo. After several sprints you find out that you need a “bugfixing” sprint.
I used to have these “bugfixing” sprints in my projects, but I can’t stop feeling that it is the sign of “something is wrong” in the project. Sometimes it is a good idea to stop and try to follow the rules, even if it slows you down in the beginning. When you try to catch up all the time – you have no chance to improve your speed. You need to get some “starting point” to make the improvements, counting from that moment. So just try to work on the stories one by one in full development-testing cycles, not creating a mini-waterfall from your sprints. Breaking the user stories in smaller ones can be the option.
Decomposing big user stories
If you often have user stories which take a whole sprint to be implemented, so the developer finishes it 1 day before the demo – it won’t work. Try breaking it in functional subtasks. You can do that on the backlog grooming meetings or during the sprint planning. Involve QAs, so they are aware of the decomposition you make. When the developer finishes the task he will put it to the column “Ready for testing” and tester can pick it. So you will use a kind of “incrementation” for the big user stories.
What QA do when he is not testing user story
The other problem I noticed in some teams – QA is not loaded with the work during the whole sprint – only when there are some user stories to test. For me it is the sign that QA is not really involved in the process. It seems as he is only checking the user stories. But who writes the test cases, for example? 🙂 Or he writes them only when user story is on testing?
In our teams there were always plenty of work for testers. One of the most common issue developers point out during the retrospectives is that the user story is not really ready for the development, when they pull it from the sprint backlog. So, here is the task for PM and QA (if you have to business analyst and User Story Manager 🙂
“Ready for development” user story
We created the special list of requirements, which user story should satisfy to go to the development. We even added the column – “Analysis/Preparation”. The list of requirements was not static – we updated it after almost all the retrospectives.
For example, for our mobile development team it was:
Description contains:
- Obvious cases, UI performance
- Validation: fields, data
- Design: .png+link to location
- Link to the docs (check if it contains all the information)
- Compare the desing to the main application version – if all is present in the new one
Tests:
- Complicated cases
- Different roles
- Update checklist
- Boundary conditions
- SOAP tests (if needed)
You can see from the list items that all these rules were taken from the epic fails we had previously. So don’t think we are the smartest ones and knew it all from the beginning.
Every project has it’s own specific list, but for all of them I had a rule to put this definition of “ready for development” on the project board:
So, what was the QA role? The user story was undergoing the following process during the “Preparation” phase:
- PM wrote the user story description
- PM wrote down the most common Acceptance criteria, discussed the story with QA
- QA analyzed the user story. Sometimes he could find some points which needed to be cleared with the PO – I was not always as remembering the boundary conditions 🙂
- QA added more on the following: Obvious cases, UI performance, validation, design description
- QA created the test cases
- QA moved the story to “Ready for development” column
The pluses we got from this flow:
- QA was 100% sure about how the functionality should work. And when the user story was done and pushed to “Ready for testing” he welcomed it as the good old friend, not as “What is this, man???”.
- QA is a strict person (not so disorganized and frustrating, as PM) – he won’t let the user story which has no design ready go to “Ready for development”. QA obey the rules)
- Specific for our sphere: All the API tests were ready when developer started working on the task – he could use the tests to find more information about the request and be sure the request works.
- Happy developers: they finally started receiving tasks completely described.
@tisquirrel 
Thank you for the article. It was very useful and just in time for me and my team. We have the same problems as described: overloaded QA and lack of early feedback from QA. Now I see that he should work in tandem with PM and developers to have enough info before testing and be more involved in the process. There is one more thing that worries me: he seems to be demotivated and very tired by the end of the day.
One of the common problems is that QA is left aside until the time to test comes. But there is plenty work for him before that. As a bonus it saves him the time on the “testing” phase itself. In my case I did it to share the PMs work with QA, not to move some work off the overloaded QA)) Also it is a great thing to educate the QA – he becomes a bit of the “analyst” too.
squiiirrel (BTW, great name) I completely agree with what you say around the evolving responsibilities of a tester. In an agile team not only testers, but every other member needs to wear many hats and the more we are able to support our team mates the more we become valuable. I have written about this very same topic a couple of weeks ago, have a look at http://mysoftwarequality.wordpress.com/2013/09/15/get-in-shape-to-become-an-agile-tester/ and let me know what you think.
Nice reading, keep it up