Quality Assurance

How to Manage Ping-Pong between Dev and QA Teams

Posted By: Hiba Sulaiman
Posted On: March 11, 2021

Despite all your efforts, the release made it to market with some significant delay in time, and your company has had to run damage control. Now you are getting questioned by the senior executives about what went wrong and before you even know it, the blame game for the unexpected delay is in full force - with developers and testers pointing fingers at one another. Developers claim that they wrote code soon enough but it was stuck in the QA process. Whereas QA reciprocates with ‘what can we do, there were too many bugs and we got the code too late for testing’. So what happened? Whose fault caused a delay in the project? And what can be done to perform better next time? The truth of the matter is, at a time when the stakes for quality software development are higher than ever, the blame game isn’t going to stop. No matter if you are operating in a waterfall or a true DevOps environment, the finger-pointing should never happen in the first place. In the end, a product owner or project manager faces the consequences as he fails to meet release deadlines and the final software product is buggy.

How we got here: Where the Blame Game Originated from?

Before diving into the solution to the blame game problem, it is necessary to understand its origins. A few years ago, most teams followed a waterfall approach that segregated the developers and testers. In this environment, each group worked in silos, drawing lines when it came to who was responsible for what. In this waterfall setup in which development and testing operated separately that the blame game began.

The Real Scenario

We add milestones to our projects by adding new features to applications, and developers put in all efforts to achieve them. However, when a project manager checks, they are unable to do so. The problem is that when new features are added, bugs arise and they consume a lot of their time. Since you forget to cater to this factor while planning the milestones, everything starts malfunctioning resulting in unexpected delays. It is important to acknowledge that time is required to fix bugs that appear when new features are introduced in an app. Typically, 25% of the production time is dedicated to QA but it is a rudimentary approach. Whether or not your organization is working in a complete DevOps environment, there is something that you can benefit from. The only viable solution in such situations can be a test management tool that provides QA metrics. Embracing a good tool will ensure a tight alignment between developers and tests with quality placed at the center of all their processes. They should measure how many bugs appeared in the test cases and in how many interactions they were able to resolve those bugs. With a good test management tool in place, QA and developers should make a module for a certain feature and assume these many bugs are expected to appear in this area of the application.

Solution: How to Avoid Ping-Pong between Dev and QA

Measure the Time Spent

Firstly,

-tools/">test management tools allow developers, testers, and all other stakeholders traceability into a project. A project manager can assess how much time was spent on each stage of the software development project and what areas need improvement.

Involve QA in Early Stage of Development

Secondly, QA should be engaged earlier. Senior managers (QA lead/QA manager) should be a part of the team and engaged in the early stages of the development lifecycle. The main requirement or user stories contain bugs, so the managers should discuss it with the developers and other team members, thus beginning everyone on the same page. This helps them keep a check and balance on what team members are doing a certain module of developing an application.

Accountability

Thirdly, it is also pivotal to measure how many bugs each team member comes across during various stages of the software development lifecycle. It gives a manager accountability which means if dev engineers were able to run the cycle and resolve the bugs. A test management tool also provides visibility into why the delay was caused in a testing cycle, and this relevant data helps in resolving these issues. It also helps cover the gaps between the developers and testers.

DevOps

Since we do not live in an ideal world, and DevOps is still gaining its momentum in the software industry, organizations need time to adapt as it does not happen overnight. Since the traditional approach is no longer the choice for most organizations, the responsibility now falls to the agile that focuses on aligning software development and the continuous delivery model. Unlike the waterfall environment where teams were organized around functional disciplines, DevOps brings all teams to work together to ensure faster release to the market. In an ideal DevOps environment, we have cross-functional teams, where team members share certain responsibilities around quality assurance and delivering release cycles. At this point, I would say that when the blame game continues, it is a sign that your team may not be as aligned as you thought. With that in mind, everyone should feel they carry part of the blame for releasing subpar quality products. In fact, the whole point of a test management tool is to have the entire team aligned around a shared objective of releasing high-quality products out the door as quickly as possible, which means no pointing fingers.

Conclusion

At the end of the day, even the most reputable teams face delays in quality software releases. In such cases, what matters the most is how you pick up the pieces and it is hard to state that when developers and testers are busy pointing fingers at each other for unexpected delays. If your team is playing the release blame game, it is time to take a step back and find a viable solution to the problem. A good test management tool will ensure that your developers and testers are on the same page and they are equally responsible for ensuring quality software products to the market.