Improving the Developer Tester Handoff

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?

Rachel Kibler is a tester at 1-800 Contacts. She can be found on Twitter @racheljoi or on her website at

In This Article:

Sign up for our newsletter

Share this article

Other Blogs

General, Agile, Software Quality

How to Identify, Fix, and Prevent Flaky Tests

In the dynamic world of software testing, flaky tests are like unwelcome ghosts in the machine—appearing and disappearing unpredictably and undermining the reliability of your testing suite.  Flaky tests are inconsistent—passing at times and failin...

Software Quality

Test Planning: A Comprehensive Guide for Success

A comprehensive test plan is the cornerstone of successful software testing, serving as a strategic document guiding the testing team throughout the Software Development Life Cycle (SDLC). A test plan document is a record of the test planning process that d...

Software Quality, Business

Managing Distributed QA Teams

In today’s landscape of work, organizations everywhere are not just accepting remote and hybrid teams—they’re fully embracing them. So what does that mean for your QA team? While QA lends itself well to a distributed work environment, there ar...