This is a guest post by Rachel Kibler.
I’m sure I’m not the only one who gets frustrated when I get a story to test with only a few notes about implementation or expected behavior.
For a while, I was supporting five developers, they paired rarely, and we were all writing stories quickly (and fairly haphazardly). I would get a story, not know what it was supposed to do, not know how they planned to do it, and not know what they considered in their testing of it themselves. I can read code a bit, but understanding how it’s supposed to all fit together is not always clear.
I sometimes felt like I was testing blindly, which is not a good place for a tester to be, particularly in context-driven testing.
I interviewed other testers and developers on other teams at my company. Though their problems were slightly different, the common theme was that things came to testers too often without a clear message, which led to an unclear understanding of what was going on.
We came up with experiments for different teams to try. Some teams asked their developers to write testing notes. Some teams did walkthroughs of the code when the developer was done (or thought they were done). I, for one, make a good rubber duck.
These experiments lasted a little while, but it’s hard to change habits. I’ve had to remind my developers what I like and want repeatedly. One of my developers writes great notes on his user stories, and I’ve taken to praising him publicly (and often) for his notes. When my other developers write notes, I make sure to affirm them, too. Praise is effective.
One of the main things to improve the story handoff from developer to tester is to get testers involved earlier in the process. We do this during our formal meetings, but the haphazard way we were writing stories prevented some of this. I have started scanning stories every day to see what is coming up, and now I ask questions immediately of the product owner and the developer who wrote the story so that I have a better understanding of what should happen before any code gets written.
The downside of this is that it’s just me thinking off the top of my head, and I only ask questions if I don’t think I understand something. If I do think I understand it, I can sometimes go off in the wrong direction when the story comes to me, and I have to be reined in. It’s a balance between annoying people too much about things that appear straightforward and making sure we don’t have too much rework to do.
It’s helpful to organize your thoughts around testing so that you can see exactly what needs to be done, and how important some testing activities are versus other things that could be done instead. Using TestRail for example, it’s possible to create a repository of testing ideas (a Test Suite, with Test Cases in it). Once that’s done, you can use TestRail’s custom fields to sort those ideas in different ways, such as by component or functional area, by priority, or by story coverage.
Using TestRail to plan and prioritize testing coverage helps to identify potential gaps and ensures that pitfalls are avoided.
Since we’ve worked on improving the handoff, our quality has gone up. Testing feels like it has more direction, we’re more confident in the code we send out, and we’re finding fewer bugs in production.
What are your methods for ensuring a smooth handoff from developers to testers?
