How to create better developer/tester collaboration for smoother release cycles

Developer and tester collaborating


Suhail Ansari, CTO at Tricentis, a software testing company shares a range of tips from ensuring that developers, testers and business owners are clear on how business requirements align with software developers’ plans and how testers plan to test against them.

The developer / tester dynamic can be tricky to manage. As with any creative endeavour (code included), tensions can run high when it’s time to test and critique a developer’s work of art, especially when set against the backdrop of a time-sensitive software release. You are probably already familiar with the mad dash scenario of a software release: hurried test efforts, incomplete testing, slow feedback cycles, and a fragmented sense of quality ownership.

Suhail Ansari CTO at Tricentis
Suhail Ansari CTO at Tricentis

This often means that collaboration between developers and testers can quickly become stressful and strained. But we know organisations that improve their developer-tester alignment not only accelerate a smoother release cycle but also pave the way for better collaboration in the future. So before the finger pointing begins, let’s understand how we can halt the blame game by offering some top tips from our own experience as testers to improve relations between developers and testers, and ultimately benefit the entire organisation.


Quality is a team sport. It’s everyone’s job, not just the tester’s. The testers must work closely with the developers in helping design a high-quality product from the start. Teams that treat testing as a necessary evil that happens after the “real work” is done ship slower and with more bugs than teams that consider test and development as true partners.

The best way to get this partnership is to create cross-functional teams that include both developers and testers. Testers can do a better job when they understand the customer problem and participate in creating the solution. Developers create better software when they’re thinking about testability early on. They learn to speak each other’s languages. When two groups working closely together break down the “us and them” dynamic that contributes to mistrust, it’s hard to complain about the way “they” did it as you are now a part of them.


There’s a saying that you can’t test quality into a product. Waiting to start testing until the end of your development process results in re-work, buggy releases, and slow cycle times. It’s key to incorporate quality assurance as early on in your processes as possible. Testers should participate in the design process, knowing the customer problem, solution set and why the particular solution was selected. Being a part of the process earlier enables testers to point out future flaws and identify areas that need special care for things like security and usability. Testers are skilled at finding flaws. Let them find flaws in your designs, requirements, and plans, too.

When testers are brought in at the beginning of your process, they can also get a start on writing test cases for the requirements while the team is building from those requirements. And because they’re now close partners with developers, changes in the requirements are instantly reflected in the tests.

Strive for a continuous testing process. You run tests as development is completed, giving developers faster feedback. When QA reports an issue, it will be in a part of the product the developers are still working on, enabling the developers to iterate faster. This reduces costs, makes your developers happier, and speeds up your time to value.

The result? A more cohesive, effective test plan and a release that the wider team, developers, testers and business owners can be proud of. In other words, a release dream!


Automating your testing is critical for high quality, high velocity software delivery. Software complexity is increasing, and teams are moving toward incremental deployments. Manually testing your software creates a testing bottleneck that slows down your velocity. Building automation for your regular test suites can reduce your testing time for each release from weeks to hours. Your testers should only be clicking your application when they’re trying to learn something new. Everything else should be automated.

Remember that automation isn’t just for performing test steps. Other parts of testing can be automated, too. Do you create the same test data set for every test? Automate that. Set up the servers for testing? Automate it. Regularly combine reports from three different test tools? You can automate that, too.

Now that your most time-consuming testing activities are automated, your testers can focus their efforts on improving quality instead of just measuring it. They can help design your applications with automation in mind, making it easier to create and maintain automated tests. Put your tester’s skills on more complex problems like designing test strategies, identifying unexpected application behaviours, and uncovering hidden requirements that need testing. Have them work to understand how your application behaves in production and take that feedback to create more and better test automation.


When your developers and testers are on the same team, they need to act as peers and communicate with each other. Spending just a few minutes chatting can address miscommunications before they become major problems that can delay your release. Have them sit as a team, act as a team, and communicate as a team. Don’t lay your office out by role, but instead organise it by team.

Additionally, create the right incentives and goals for the team. It’s easy to focus on measurements like defects found and defects fixed to demonstrate how productive a tester or developer is. But this encourages unhealthy competition within the team that will reduce transparency. When using a goal-setting framework like OKRs, set shared team goals instead of separate goals for the testers and developers. Use metrics that track overall quality outcomes instead of trying to measure an individual’s inputs to that quality.

Improved communication and transparency will help every step of the way for all those involved and make everyone’s lives so much easier.


As you take steps to improve communication and transparency, documentation will inevitably come up. That’s because proper documentation can help achieve this transparency, as well as hold the entire team accountable for their work and for tracking progress throughout a fast-moving release.

However, as we all know, the manual work of documenting test plans in spreadsheets is labour intensive, introduces scope for error, and can contribute to frustrations among developers and testers who have to go digging for the information they need. Using a test management app though can offer the secret sauce for the recipe to completing alignment between teams.

Test management apps provide both developers and testers with real-time data and built-in test reporting for decision-making and collaboration. Software testers can fully plan, design, track, and analyse testing activity within the same workflows that developers and testers are already using. This removes the need for developers to request status updates or results from testers, while testers can quickly see how tests align to requirements. Testers can then come up with the ideas for additional tests and offer the developer team better context and information to develop around.

And the end result? The entire team can maintain true traceability between requirements and test coverage, which both minimises finger-pointing and ensures that everyone has a clear picture of what’s required before the release is ready to ship.


At the end of the day, even the most respected teams have their poor releases. In these cases, what matters most is how you pick up the pieces, and it’s hard to do that effectively when your developers and testers are busy pointing fingers at each other.

If your team is still playing the poor release blame game, it’s time to take a step back and conduct an open and honest assessment of how mature your development process and teams are. Developers blaming QA and QA blaming developers is a sign of team dysfunction. If your teams are pitting QA and developers against each other, take the reins by following the tips outlined above for improving the relationship between developers and testers. And if you can make that happen, you’ll be well on your way to a more collaborative environment — one that can not only more quickly resolve errors in production, but one that also experiences those errors significantly less often.




As a developer, there are several websites that you may find useful and interesting. Here are a few recommendations.
In this piece, Ed Hoppitt, Director, Apps and Cloud Platform, VMware EMEA, takes a look at how we can challenge these stereotypes, what more needs...