In my experience, there are a few major factors that negatively impact the DEV/QA relationship:
In social psychology, there’s a phenomenon known as in-group favoritism / outgroup prejudice [1], which describes the tendency of individuals to favor and respond more positively to members of their own group over those from other groups.
The reason for this, as studies [2] say, is that our ancestors lived in small social groups that were frequently in conflict with other groups, and it was evolutionarily functional for them to view members of other groups as different and potentially dangerous.
This bias can and will emerge in environments where QAs and devs are separated into departments, fostering a sense of “us versus them”.
Such division undermines the potential for collaborative synergy that could be achieved if both teams were integrated into the same cross-functional unit. The separation exacerbates communication barriers and diminishes mutual understanding and respect, essential for a harmonious working relationship.
The confusion between Quality Assurance (QA) and Quality Control (QC) [3] roles further complicates the relationship. Quality Assurance is about embedding quality into the development process from the outset, assisting developers in adopting practices that prevent defects. Quality Control focuses on identifying defects in finished products.
The misinterpretation of QA roles as purely QC undermines the value QA can add beyond mere defect identification. This misunderstanding leads to frustrations among developers, who might perceive QA feedback as criticism of their work rather than constructive guidance aimed at improving the development process. The psychological impact of this dynamic is profound; developers, like anyone, tie their self-worth to their work. Feedback implying the need for significant revisions can be perceived as personal criticism, especially after investing considerable effort, a concept illustrated by the sunk cost fallacy [4]. Integrating QAs into development teams and emphasizing their role in quality assurance could mitigate these issues by fostering a perception of QA as a supportive function rather than a critical one.
The use of Key Performance Indicators (KPIs) that incentivize finding bugs will always exacerbate tensions between Dev and QA teams. Such KPIs encourage a fault-finding mindset among QAs at the expense of constructive collaboration.
This approach not only undermines the spirit of teamwork but also can lead to a counterproductive work environment where the emphasis shifts from collective success to individual performance metrics.
The dysfunctional nature of KPIs and MBOs is well-documented [5], [6]. To summarize, the issues include:
1️⃣ Distorting the system: The establishment of KPIs often leads to conflict within the system. Quality Assurance (QA) teams may focus on identifying a higher number of bugs, despite their primary role being to assist in the production of high-quality software with fewer bugs.
2️⃣ Short-term thinking: The pursuit of short-term objectives is appealing and straightforward. However, intangible factors such as collaboration, willingness to assist, and trust do not receive attention. These aspects are inherently unmeasurable, yet individual KPIs can undermine them [7].
3️⃣ Fudging the figures: There is a natural tendency for individuals to manipulate the system, both logically and illogically. This phenomenon is encapsulated by Goodhart’s Law [8].
4️⃣ Neglecting unmeasured aspects: Elements not quantified by KPIs, such as customer requests or general cooperation with partners, are often overlooked.
The adage “If you can’t measure it, you can’t manage it” is frequently cited by some managers, which is, of course, a flawed notion and simply a misquote of Dr. Deming [9].
References: