A story about programmers and QA working in pairs. Learn about the benefits and risks you may also experience after implementing pair programming.
A QUICK SUMMARY – FOR THE BUSY ONES
Facing the challenge of a rapidly growing team and frequent task modifications on the project, we naturally implemented pair testing to address complex software development needs.
Spontaneous interactions between developers and QA professionals led to significant process changes, with both parties collaborating to improve test methods.
To implement pair testing officially, we openly discussed its advantages and our plan with the entire team. We used video calls for real-time remote discussions and paired a QA specialist with a developer for specific tasks, logging their joint effort. Although not suited for all tasks, this approach has enhanced collaboration and productivity in our workflow.
TABLE OF CONTENTS
In the dynamic realm of the Polish IT industry, collaborative excellence takes center stage with the advent of pair testing.
While gaining international popularity, pair testing remains a relatively fresh concept in our local environment. Through its implementation, we have witnessed an array of benefits, yet it also presented unique challenges within our mature software development model for clients.
This article offers an exclusive glimpse into our firsthand experience with pair testing, unraveling its profound impact and transformative influence on software development practices.
Let’s start from the beginning.
From almost the very beginning of the new large-scale project, we encountered an exceptional challenge - a massive scope of work at the start that needed to be comprehensively implemented from the early design stage, with very little room for error.
At the same time, the team was rapidly growing, and as the client was satisfied, they assigned us even more tasks, resulting in the addition of new team members.
In a short period of time since the project's inception, we already had several individuals involved at various levels: experienced full-stack JS specialists, DevOps professionals, business analysts, and, of course, a small QA team. As is often the case, the team consisted of individuals with different experiences from previous companies and projects, each with their own preferences for tools, solutions, and work methodologies.
This situation required us to adopt a sophisticated and experimental approach to project management.
Our clients are highly engaged in the product development process, and we frequently communicate with them, seeking their input and providing advice on better solutions.
On one hand, this is an advantage as they can provide us with valuable feedback quickly and continuously verify their requirements. On the other hand, collaborating with this particular client was leading to frequent modifications of existing tasks, increasing the complexity of the project and the dependencies within it.
Looking back now, I can hardly believe how spontaneous interactions among team members can lead to such significant process changes.
Our team's case is quite an interesting example, one that I believe can occur in most similar projects. It all started innocently with a regular video conference session between a new QA member and an experienced developer - nothing out of the ordinary, or so it seemed.
It could have been just another developer explaining to a QA team member how to test a particular complex backend functionality. However, the interaction became so intense that it evolved into a conversation not only about the functionality itself but also about how to write tests for it, when to do so, and what techniques and tools to use.
It ended up with both of them working in the same branch, where they had a fully implemented and tested functionality with API tests and unit tests.
At that time, we didn't formally call it pair testing, but it set off an intriguing dynamic.
Developers, recognizing the benefits of these collaborative sessions, took the initiative to ask QA how they could improve tests if they could help, and ultimately, if they wanted to literally sit together for a few hours and complete a task from A to Z.
We began to see a mutual need that transcended the boundaries of our traditional roles as stated on our CVs.
Eventually, we started working together regularly on new tests, improving existing ones, maintaining them, and identifying uncovered test scenarios. This was a natural consequence of our increasingly frequent collaboration.
Developers and QA simply began working in pairs.
Since we started working together in pairs on testing, we have observed a multitude of benefits.
First and foremost, we have noticed that we deliver tasks much faster, and they are of higher quality. This is perhaps the greatest and most valuable outcome that can be achieved through pair testing. Combining the unique skills of a tester and a developer enables us to perform tasks more efficiently.
Thanks to this new approach, we now have more tests and test cases. Together, we can identify more potential issues during the coding phase, which ultimately translates into the comprehensiveness of our tests.
We effortlessly handle tests and add new ones at various levels: API tests, end-to-end tests, integration tests, unit tests, and even recently, we found time for visual testing.
Additionally, working in the pair testing model, where QA and developers collaborate on a single branch in our monorepo, has significantly reduced conflicts during merges or pull requests because we are both working on the same thing simultaneously.
Another noticeable advantage is the reduction in the number of reported bugs after releasing a new version of the application. This saves time because instead of desperately patching bugs in production, we can calmly focus on new features and upcoming tasks.
One could say that during collaborative testing or test writing, we even perform some form of early code review. We often catch issues in each other's code during the early stages of coding.
Additionally, our delivery cycle time has noticeably decreased for tasks taken under pair programming. Previously, programming and testing were often separate stages, which lengthened the entire process. Now, with our new approach, these two phases intertwine and occur simultaneously, resulting in shorter implementation times and faster feature delivery.
Pair programming has proven to be an invaluable tool in reducing context switching - a phenomenon that typically reduces work efficiency. By having the programmer and tester work together on a single task, they do not have to constantly shift their focus and switch between different tasks. This eliminates unnecessary downtime, such as setting up environments or database migrations, and allows them to concentrate on one problem. I firmly believe that pair programming is an effective way to minimize the negative impact of context switching.
Of course, like any newly introduced technique, pair testing may initially appear to have drawbacks. It may seem like a waste of resources when two people work on the same task simultaneously.
However, when we consider the outcomes of this method, it becomes clear that it is an investment that brings us far greater benefits in the long run.
Pair testing, in simple terms, is:
The practice of testing in pairs, where two individuals collaborate on a single task to comprehensively create and test it.
Typically, one person is a testing specialist, while the other is a programmer who understands the technical aspects of the application. It's worth noting that this is not a strict rule, as there are cases where more individuals are involved in such work, such as business analysts.
During collaborative testing, the tester has the opportunity to understand the detailed technical aspects of the application, gaining broader perspectives, expanding their domain knowledge, and gaining a better understanding of the system's functionality.
On the other hand, the programmer gets to see the application through the tester's eyes, which helps them better understand the expectations and quality requirements associated with their code.
Additionally, pair testing encourages better communication, knowledge sharing, and understanding among team members, creating a more efficient workflow.
I want to share with you what we changed and how we reached an agreement regarding pair testing. The change wasn't easy, but as with anything, direct communication was the key.
I started by informing all team members, both technical and non-technical, about our plans. We explained what pair testing is, the benefits it can bring, and how we planned to implement it.
As a predominantly remote team, we started organizing video calls during our regular communication on messaging platforms. This allowed us to have real-time conversations - in the era of remote work, this aspect is crucial for exchanging ideas and clarifying any uncertainties on the spot.
We noticed that some tasks were large enough that pairing a QA with a developer for an extended period made sense during sprint planning or backlog review.
We decided that regardless of who was assigned to a specific task, both individuals would log their work time. Why? Because both of us contribute effort and time to it. This way, everything aligns, and no one has missing hours, and our time tracking tool wonderfully shows who did what and when in a task.
Lastly, I want to add that although pair testing has proven to be an effective tool, not every task qualifies for this mode of work. Of course, we still execute most tasks in the normal mode, and we use pair testing as an excellent addition where we can benefit the most from this intensive collaboration.
Pair testing technique has shown us that, in the pursuit of quality, it is worthwhile to sometimes take unconventional steps and decisions, of course in agreement with the entire team and the client.
Therefore, we encourage anyone interested in improving their testing process to experiment with pair testing. It may require some changes in teamwork, but the final results will definitely convince you to adopt this approach.
So, don't be afraid to try, explore, and learn new techniques that are constantly evolving.
Our promise
Every year, Brainhub helps 750,000+ founders, leaders and software engineers make smart tech decisions. We earn that trust by openly sharing our insights based on practical software engineering experience.
Authors
Senior QA Engineer with 11 years of professional experience.
Read next
Popular this month
Get smarter in engineering and leadership in less than 60 seconds.
Join 300+ founders and engineering leaders, and get a weekly newsletter that takes our CEO 5-6 hours to prepare.
previous article in this collection
It's the first one.
