Agile Development is an ever-changing world, and it is just as important to keep up with it as with any other area. I found myself working in a way that was efficient on the surface. Tasks were divided, deadlines were clear, and each person was responsible for their own part. But in practice, it often felt fragmented, and misunderstanding crept in. Progress stalled when one piece didn't align with another, and the sense of working “together” was more inspirational than real.
That experience made me realise there is one key part that often gets reduced to a buzzword when, in fact, it is a core value of not only agile development but also effective teams. Collaboration.
Collaboration
Powerful collaboration actually sits within the Quality Assurance (QA) team itself, and it's the work between an Analyst and an Engineer that can deliver the most value. Collaboration across the entire team is vital, but at its core is the relationship between the analyst and the engineer, which we explore in this article. Collaborations like this are referred to as pairing or pair testing.
We will explore why this combination is so powerful and how effective it can be, using some real-life examples along the way. It will highlight benefits, show the challenges, but at the same time, share tips on how to make such a dynamic duo work.
Why does it matter
QA is one of the main foundations for delivering quality and reliable software to our clients, customers or whoever your end users may be. In many scenarios, the Analysts and Engineers may sit in separate silo’s focusing on what will be their own targets and end goals, when in fact these are often the same (or at least should be). However, if we do actually pair these together as a team, we can unlock so much potential at early periods, for example:
- Uncover gaps in test coverage
- Speed up Test Cycles
- Catch defects earlier
- Bridge the gap between business knowledge and technical validation of the software
- Uncover flaky tests early
A good and solid QA collaboration does not necessarily need to mean “cleaner code”. It is about the ripple effect that this will cause across the whole process, from the start of sprint planning to the end, when we plan to push to production.
The roles (depending on each person's views)
Before delving into the whole article on how and why this is such a powerful combination, it would be good to briefly cover each role at a high level.
QA Analysts A.K.A The business besties
With QA Analysts, we find that they are more aligned with the business side, the processes, and how we want a product to work for end-users. At a high-level view, they:
- Interpret requirements and ensure that what we have is actually testable
- Design the test cases on the back of this using their business logic and how the requirement should work
- Work closely with the developers to ensure it is working as expected
- Investigate and raise defects during the testing phase
- Think like the end users
- Collaborate with Product Owners/Project Managers to refine the acceptance criteria
QA Engineers A.K.A The automation angels
Working with a different primary focus than the Analysts, the Engineers are more technically focused and think more about how a product is working and how the building blocks of the software hold together. Beyond their technical specialities, they also act as a crucial link between business objectives and the technical execution of tests. By understanding both perspectives, they can translate business needs into testable solutions and effectively communicate any technical risks identified.
At a high-level view, they: Build and maintain automation frameworks
- Interpret how API’s hang together and build appropriate tests
- Write UI automation tests
- Work closely with developers to uncover coding issues and CI/CD pipeline builds
- Investigate complex environment failure issues
This range of responsibilities demonstrates the value that QA Engineers bring when working as part of a close-knit team. They aren't just confirming if a product works. They are helping shape how it is delivered and ensuring that the product not only meets business requirements but also technical ones, whilst also helping deliver the product faster through appropriate and intelligent use of automation.
What are the real-world benefits of collaboration between Analysts and Engineers?
There are plenty of real-world benefits to why and how this is such an influential pairing, and below are just some of the benefits of this partnership.
Improved test coverage
When an Analyst and an Engineer start from the beginning of a sprint together, the functional testing and automation work are aligned from the get-go. This means that each knows what's going on, what they need to do, and how best to approach it. An example of this is the Analyst identifying edge cases from the start, meaning they can be prioritised, and the Engineer can address them from day one, rather than months or years down the line.
A real-world example of this is a recent team restructure we completed, where we shifted to this model and encouraged a tighter collaboration between our Analysts, Engineers, and Developers. The goal of this approach was to align our test coverage more directly with the business priorities, modernise our automation frameworks, but also speed up the delivery process.
As part of the transition, one of our senior Engineers began rewriting some of our legacy frameworks that had, over time, grown outdated and extremely difficult to maintain. During this process, they had discovered a few obstacles that we potentially needed to resolve. The key one being that within one of the scenarios, a set of API responses behaved inconsistently when certain data was passed through the system. This had previously gone unnoticed because, when Engineers (who had left by this point) had run it previously, they had manipulated the tests to achieve their desired outcome. Therefore, it was not fully captured earlier on in our automated tests.
The Analysts then played a key role in unblocking our progress here. By tracing the workflows behind the data combinations, they were able to clarify which outcomes were expected versus which ones represented gaps in functionality. This collaboration not only resolved the ambiguity but also led to the identification of an additional edge case we were able to put into the regression pack. When a response contains incomplete data or discrepancies (i.e., mismatched fields or unexpected values), it triggers a different workflow designed to handle those situations. With that understanding, the Engineer was then able to extend the framework, increasing coverage and successfully automating the new edge case, using the new framework we have been putting in place.
This example is just one scenario that highlights how the restructure emphasises collaboration and has directly improved the depth and accuracy of our test coverage, which in itself ensures a more aligned approach to the business requirements and technical validation.
Faster feedback loops
Closely linked to the above, faster feedback loops are created during the collaboration. By working together, QA’s can define and automate tests in parallel during development. At the start of a sprint, while the Analysts are working on test cases, the Engineers can begin creating the frameworks and stubs for all the scripts. This not only reduces the need for handovers but also opens up the world of continuous testing.
A more balanced workload for each role
In teams, we often see that Engineers become weighed down with the ongoing task of maintaining and improving automation packs and keeping pipelines running. At the same time, Analysts are left carrying the majority of the functional and exploratory testing, which in itself can result in them juggling a wide scope of validations with little technical support. This is how we were previously working, and although this separation of responsibilities may seem efficient, we found that this created silos of knowledge and an uneven distribution of workload. When we spent time investigating this, it became apparent that our Engineers felt stuck in a cycle of maintenance with little product knowledge. Whilst our Analysts struggled under the weight of endless test demands, tight deadlines and no career progression. Both roles and the entire team were stretched thin, experiencing feelings of burnout.
We took a step back and tried to use this to everyone's advantage, so in getting the Analysts and Engineers to work closer, we have found the balance has evened out, as much as we can, with high workloads coming in. Instead of each role carrying separate burdens, the workload is now more equally balanced. Engineers can now contribute to both functional and exploratory testing, while analysts can participate in learning and shaping automation, providing an opportunity for career progression. Knowledge is now flowing in both directions, preventing bottlenecks and ensuring that nobody is overloaded. This new approach not only improves coverage and efficiency but also enhances them. It has created a tighter team bond, leading to a healthier and more sustainable way of working, where the risk of burnout is significantly reduced.
Stronger communications with developers
When a QA works alongside someone with a deeper technical perspective, it enhances the feedback we can provide to developers. This means it is more likely that we can find a quicker resolution to the issue, thanks to the additional information provided in the bug reports. An example would be if a problem arises with a test during regression. We can raise the issue with more context, including what the error message is, where it is coming from, and how it was generated.
This pairing adds value by highlighting technical issues, enabling developers to quickly understand the scope and potential impact. The Analysts and Engineers are able to explore the problem together more thoroughly, providing actionable insights that make the resolution process faster and smoother. Developers appreciate this approach as it reduces back-and-forth conversations and ensures that identified problems are clear and well-explained.
More upskilling opportunities for colleagues
This is a personal favourite of mine. This pairing isn't just focused on the task element. There are massive knowledge gaps we can identify and resolve together. Analysts can gain more technical knowledge around how we write code and build our frameworks. On the other hand, Engineers can learn more about the product, testing techniques and deepen their understanding of business processes. This not only provides all individuals with growth and experience within the company, but it also builds an invaluable, resilient, and versatile QA team.
Common challenges and potential solutions
Challenge 1: “We don’t have enough people to pair with QA’s”
It's how you plan it. Not every team has the luxury of a 1:1 ratio of Analysts to Engineers, but that is okay. There are other things we can do. Periodic pairing sessions can be very useful, and we have recently implemented this approach, which is proving to be extremely effective. Scheduling either weekly or monthly sessions, co-reviewing test case sessions, or even opening up and reviewing regression suites. Encouraging collaboration on these is another extremely useful option for those with tight personnel allocations.
A top tip could be to create a testing plan for the wider team and business on how to introduce this pairing, which could help lay the groundwork for building your dynamic duo.
Challenge 2: “Our work doesn’t overlap”
Work doesn’t need to overlap directly for a pairing like this to be effective. In many teams, Engineers and Analysts often feel like they are on separate tracks because their day-to-day responsibilities can seem very different.
An agile environment helps bridge these gaps. By involving both roles in sprint planning, stand-ups and retros, the teams naturally create points of interaction where perspectives interlink. This natural overlap not only improves collaboration between the roles but also benefits the wider team by reducing misunderstandings, preventing bottlenecks and ensuring that testing efforts are aligned with both technical and business goals.
A top tip for this is that embedding both Engineers and Analysts into the SDLC (Software Development Lifecycle) encourages co-ownership of QA tasks. At my current company, this means they are actively involved from the start in planning the requirements and sprints, and even refining the requirements themselves. This shared involvement helps catch gaps sooner and makes QA a continuous responsibility across the team.
Challenge 3: “We aren't sure what the other person does?”
When each role is misunderstood, it can feel like pairing is being forced upon us. However, it is essential to foster a culture of curiosity within the team, as it keeps everyone engaged and motivates them to pursue their own personal goals. Encouraging shadowing of each other's roles and understanding documentation responsibilities through pairing is beneficial, as it should not be limited to just tasks but also serve as learning opportunities too.
A top tip for this challenge would be to encourage role reversals by having Analysts review automation frameworks and Engineers run through test cases, as well as conducting exploratory testing.
Making it work: The practical steps
Before delving into the specific actions, it is vital to establish some context around this section. Deciding to implement the model that has been explained always starts with recognising that traditional testing silos are limiting for both efficiency and quality outcomes. In our experience, this decision emerged during a QA team-wide review of our testing processes, led by me (QA Lead) and was supported by the wider business. The early discussions focused on identifying pain points. Duplicated efforts, bottlenecks and knowledge gaps. Then, exploring how pairing could address these points. Gaining buy-in from both Analysts and Engineers involved clearly communicating the expected benefits of shared knowledge, faster feedback loops and a more cohesive QA approach. Things that not only benefit the business but also benefit them as individuals.
Once the team was aligned on the vision, we were able to move forward with the practical steps outlined below.
- Define clear goals for pairing: Make it clear to everyone what the goal of this is, whether it be to improve automation coverage, improve test script quality or even encourage learning and development. Make this the mission of pairing.
- Start small and focused: Select one team and one project to use as a base, and allow the team to review the specification, create scripts, and outline frameworks. Monitor the progress and make any necessary adjustments based on the feedback.
- Create a shared workspace: Make use of the tools you have, whether that’s a test management tool or even a space like Confluence to store conversations and best practices. Ensure everyone has equal access.
- Celebrate the wins together: If it's a defect caught early or quicker creation of automation scripts, these are the wins to celebrate as a joint effort, not just a solo win. These can be simple conversations with the team or highlighted in retrospectives.
- Shout about your success: Similar to the above, Leads and Managers should share this practice and the wins up the chain. Show examples of how well this is working to not only acknowledge the team but also encourage this to be a wider strategy.
To sum up
The main thing to remember is that pairing isn't just a process change. It’s a culture shift. It turns QA into a shared responsibility and embeds it across the team rather than isolating individuals.
We have seen firsthand within our team restructure how pairing elevates outcomes. It builds empathy, accelerates feedback and results in software that isn't just functional but is also user-aligned.
By leaning into the strengths of each role and fostering mutual respect, we can build Agile teams that are smarter and more cohesive in the approach to Quality Assurance.
