From Handovers to Hands-On Pair-Testing Sessions
How collaboration between QA and developers has changed over time in Scoro.
As someone who has worked as a QA for quite some time now, I know just how crucial it is to collaborate with developers. But even if processes are well-established, there’s always room for improvement. This article gives you a brief overview (and hopefully a little inspiration!) of how we at Scoro have moved from QA testing alone in isolation versus together with developers.
Five years ago, our workflow looked something like this: the developer finished their task and invited the QA over. They talked about what was built and what needed testing. The QA nodded, asked some clarifying questions, and then went off to do their testing solo. It was okay, but to be honest, it created some painful bottlenecks. Waiting for the QA to complete their testing often slowed down the development process and created loops, leading to a never-ending game of hot potato.
Our first big change was pretty simple. Instead of the traditional handover from the developer to the QA, both sides joined forces to brainstorm and identify testing areas right away. The QA actively contributed by suggesting test scenarios while observing the developer’s initial testing. This collaborative approach helped to quickly find the most obvious bugs and the developer could continue their work on the task. Once the jointly identified bugs were resolved, the task was passed to the QA who checked the remaining parts thoroughly.
But the real game-changer? It happened when we decided to completely flip the script. Instead of having the QA watch and suggest what to test while the developer explains the feature, the QA now takes a hands-on approach and dives right into testing while the developer talks about what was done and what might be affected.
Why is this better? This shift allows the QA to take the lead right away. They don’t have to wait until they’re back at their desk before putting themselves into the customer’s shoes. Ever experienced the thrill of randomly clicking through things and stumbling upon a bug? That’s the magic of exploratory testing kicking in, which means we can now spot the issues and fix them as soon as we lay hands on the feature — while the developer is still next to us. Before this change, it was much harder to suggest what to test when we hadn’t even interacted with the product.
Simultaneously, developers now have the opportunity to observe and learn first-hand how QA works. They now see what the QA has been doing all along behind their screens. No more waiting for feedback until the QAs find the time to start testing — we can now go over them together. And on good days (which we have a lot of), we can even merge the features straight away, eliminating the need for the QA to test anything on their own.
Now, here’s the thing — this new way isn’t a silver bullet. There are times when the old way or a mix of both approaches is still the way to go. It’s like choosing the right tool for the job — you pick what works the best for that particular case. I personally just try to figure out the right approach when it’s time for a pair-testing session.
Our journey of evolving pair-testing has taught us one thing: testing isn’t set in stone and it’s okay to mix things up. Remember, collaboration is the secret sauce for quality software, and by improving our approach, we’ve taken a step towards building a better product.
If you would like to be a part of our innovative team, check out our open positions at https://www.scoro.com/careers/
