Posted on Aug 7 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.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 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 leads 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. This 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.Templates let you quickly answer FAQs or store snippets for re-use.Thank you for sharing a valuable experience that can only be learned after a long time. It is the first time I have heard of the concept of pair testing by test experts and programmers, and it seems to be an article that gives me new insights. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well Confirm For further actions, you may consider blocking this person and/or reporting abuse Sajeeb Das Shuvo - Aug 1 Lucy Linder - Aug 1 druchan - Aug 1 jiisanda🙆‍♂️ - Jul 21 Hire a high-performing team of software engineers in less than 10 days.Scale your team up and down easily with top 1.36% talent skilled in React, Node.js, .NET, AWS. Once suspended, brainhubeu will not be able to comment or publish posts until their suspension is removed. Once unsuspended, brainhubeu will be able to comment and publish posts again. Once unpublished, all posts by brainhubeu will become hidden and only accessible to themselves. If brainhubeu is not suspended, they can still re-publish their posts from their dashboard. Note: Once unpublished, this post will become invisible to the public and only accessible to Maciej. They can still re-publish the post if they are not suspended. Thanks for keeping DEV Community safe. Here is what you can do to flag brainhubeu: brainhubeu consistently posts content that violates DEV Community's code of conduct because it is harassing, offensive or spammy. Unflagging brainhubeu will restore default visibility to their posts. DEV Community — A constructive and inclusive social network for software developers. With you every step of your journey. Built on Forem — the open source software that powers DEV and other inclusive communities.Made with love and Ruby on Rails. DEV Community © 2016 - 2023. We're a place where coders share, stay up-to-date and grow their careers.