How tools can improve (or harm) relations between QAs and developers

There are numerous forum threads and LinkedIn posts discussing the poor relationships between QAs and developers.

The adversarial relationship between the two often stems from organizational and cultural issues. QA work is frequently conducted at the end of the development process, mainly focusing on testing completed features. This approach, which aligns more with QC than QA, can result in substantial rework if defects and issues are identified late in the cycle. This situation can cause frustration and perceived criticism among developers who have already put in significant effort. It not only increases waste but also exacerbates negative feelings, as developers may interpret the necessary revisions as a critique of their skills or effort.

The tools QA and dev use in their daily work have the potential to improve this relationship — but they can also cause further harm. For example, if QA relies only on Excel to keep track of test cases, the tool doesn't compel them to collaborate with devs during or before development. This means that Excel is not hurting, but it's also not improving QA and dev relations.

However, if the team uses a task-tracking tool like Jira and it is configured to have a pre-development requirements testing stage for each feature, then QAs and devs are able to collaborate early on, and their relationships will improve as a result.

Tools change our behavior

Tools can influence how we behave in both positive and negative ways. Speedometers, for instance, encourage us to drive more cautiously, thereby enhancing road safety. By checking the speedometer, we can easily identify when we're driving too fast and need to slow down.

In the 1920s a tool called a “pedoscope” was invented and patented by Dr. Jacob Lowe. It was a modified medical X-ray machine allowing people to see how shoes fit on their feet.

Needless to say, the tool did change our behavior. Better fitting shoes are more comfortable to wear, though accumulated negative effects of radiation from the pedoscope changed our behavior in a very undesired fashion.=

Tools provide us new capability, we express it by using the tool, and this inevitably changes our behavior.

Tools change our relationships

Tools not only change our behavior, they also change our relationships.

The invention of the telephone is said to have improved relations between relatives who live far away from each other: since the beginning of the 20th century we have been able to communicate more often with the relatives and friends who live quite far away.

However, tools which take communication “further,” like social networks, are well-studied for their diverse effects on relations between people: from positive to negative and extremely negative.

As a quality enthusiast, I’m particularly interested in the ways tools affect relations within companies, as relationships significantly affect quality. In IT, tools are changing our behavior and relationships for good and bad as well.

For example, surveillance software is perceived by people as a sign of distrust from the employer, and distrust reduces the effectiveness of collaboration. When people feel they are not trusted, their behavior changes to be more complacent and they are more likely to avoid innovating.

In my piece on generalists vs specialists I had a thesis that quality depends on the communication efficiency — how much or how little information is lost in communication throughout the company. Information flow largely depends on the relations between the members of the team: if people don’t like each other or simply don’t get along well, the information flow will never be as efficient as it could be.

In many companies, when testers bring feedback to developers, it can feel confrontational. The developers feel that their work is being criticized and they are frustrated by how much rework is required when issues are discovered. Meanwhile, testers are simply reporting their findings. This tension rarely improves relations, but rather increases animosity between dev and QA.

Without decent tools, it’s harder for QAs to show the value of their work to devs, which means devs quite often value QAs work less than they should, which adds to the overall negative relations between two parties.

When used properly, good tools can enhance the relationship between QA and dev

Using the right tools can improve the overall relationship between QA and dev by:

Making it easier for QA to shift left

Shift-left testing is a proactive approach where Quality Assurance (QA) engineers collaborate with developers before development begins. A good example of shift-left is requirements testing. When QA engineers use effective tools to demonstrate the results of requirements testing, developers can immediately appreciate the value of a clear, mutual understanding of the precise requirements. Once developers and QA engineers agree on the development and testing processes, developers will experience less rework, which is highly beneficial.

Allowing QAs to re-test the product for regressions faster

A QA engineer requires time to test a product for regressions before its release. Often, developers are eager to deploy their finished code, which can cause QA to be seen as a bottleneck. Additionally, managers might pressure both QAs and developers to deliver faster, which can hasten testing. This rush can sometimes compromise quality, which is undesirable.

By using a robust tool to manage test plans and cases, QAs can clearly demonstrate to managers and developers what they are testing. For example, developers might find it hard to navigate and understand an Excel spreadsheet with test cases, but navigating a decent TMS with test cases organized into test plans is a no-brainer. When QAs can easily show their work, and guide devs through the usual regression testing test plan, devs will appreciate the necessity of quality control and the value of these checks. The more open and easy-to-understand the work is, the easier it will be to understand the value of it. Also, developers will potentially make some of the checks themselves — why wait for QA to test things which devs can easily test themselves and get faster feedback?

Enabling QAs to help developers justify automation when necessary

Automated tests, which form the famous testing pyramid, carry significant value that can't be underestimated. If there's a valid reason for automating a task, it should be automated.

However, there are instances where developers and managers fail to see the importance of automated test management. Some even subscribe to the belief that "QAs are paid to check, so let them check." This mindset results in a broken relationship.

However, if QAs use tools which help them demonstrate the time spent on manual testing that could be automated, a stronger case can be made for automation. Any decent TMS allows users to track time spent on manual testing:

By demonstrating the value of their work to developers, QAs can help improve these relationships.

Tools can make or break QA and dev relationships

Tools change us. Some have altered our biology, while others impact our behaviors and relationships. In the realm of science, tools have revolutionized scientific exploration.

The effects of some tools are purely positive. For instance, umbrellas are generally considered harmless while providing clear benefits of water protection. However, the potential adverse effects of other tools, such as LLMs, are still a topic of ongoing discussion.

Tools alone cannot solve problems. It is us, the humans, who invent and use these tools, which in turn, have specific effects on us and those around us.

I believe that proper tool usage begins with the why: understanding the problem we are trying to solve. Next comes the how: how the tool helps solve this problem. The final, yet equally important aspect is what is the overall impact: are there any side effects from using the tool? We must ensure that we're not achieving a perfect shoe fit at the expense of excessive radiation exposure.

References: