When you work in the field of QA testing, you’re inevitably going to encounter folks with negative perceptions of QA. While this can happen frequently, there are ways to work around it. If you can determine when to persist through the noise and when to push back, you’ll be able to accommodate whatever is thrown your way.
Developers
The overall QA and developer relationship should be collaborative. Working with a developer that respects QA can be amazing! However, the most common role that has negative perceptions of QA tends to be engineers. It’s helpful to keep in mind that this isn’t always the engineer’s fault.
Some QA testers can be condescending in their manner of reporting bugs. They might treat it as if it’s a personal critique on the developer’s self-worth. Naturally, if a developer feels that they are being personally criticized, they may react defensively. (Learn more about how to collaborate with developers in our guide to the QA and developer relationship.)
Addressing Bugs
No matter how politely and neutrally a tester reports an issue, some developers react defensively. In some extreme cases, the reaction may even be verbally aggressive. First and foremost, this is uncomfortable on a personal level. But it’s also one of the biggest detriments to the quality of a mobile app or website. Accordingly, it can tank the company’s ultimate success and ability to thrive. Developers in this situation can end up being a roadblock to getting bugs fixed. They can even an obstacle to letting product managers find out about bugs in the first place.
Some developers will close bug tickets themselves, and say “this isn’t a bug” for a number of reasons. Sometimes this could be out of a genuine intention of being helpful. Other times, it’s out of worry that they’ll get in trouble for a bug in their code. In worst case scenarios, it can even be run-of-the-mill power-tripping.
This can be solved from day one. How? By making sure it’s understood that the product manager determines whether a potential issue should be addressed. QA’s job is to report potential bugs, and the role of developers is to fix them. Both QA testers and developers need to understand that the product owner should be the final decision-maker on what gets fixed.
Prioritizing Bugs
In some situations, with the client’s blessing (and even active encouragement), QA will play a bigger role in prioritizing bugs. Developers should often be given a chance to weigh in. For example, they can advise on how long a certain issue might take to fix. They can also note if there are better workarounds. But generally speaking, a developer shouldn’t be responsible for closing tickets related to bugs in their own code. And at the end of the day, QA should never hold back from reporting bugs out of concern of what developers will think. This would be doing a poor job at QA. It could also come back to bite you if/when users complain about the bug down the road.
The Blame Game
Placing blame for bugs is often done by both QA and engineers – and it’s an important cycle to break. In order to deflect any attention on their code being the cause of the bug, sometimes developers will interrogate QA about why they didn’t find a given bug sooner. To be sure, if QA is regularly missing bugs, that’s an issue that should be looked into. But there should never be personal attacks.
If someone’s job performance was so poor that they deserved to be fired over it, then they may need to be let go. But there’s still no reason to bring that tension into the overarching team. Any QA tester can miss a bug once in awhile. Developers also shouldn’t be blamed for having intermittent bugs in their code. After all, if that wasn’t an expectation, QA wouldn’t need to formally exist. (For more on this, see 5 Reasons Developers Shouldn’t Be Blamed For Bugs.)
The issue of placing blame needs to be solved from the top-down. The best way to do this is to have the Engineering manager make it clear that no one is going to be personally attacked. If there are general issues, then the Agile process itself needs to be investigated too. A process problem isn’t automatically an indicator of a QA tester or developer being bad at their job.
Unrealistic Estimates
It’s very common for developers to drastically exceed their initial estimates. As a result, the development work can eat up the majority of the time that QA would have had to test before a firm release date. This is certainly not always the fault of the developer. Estimates are exactly that – estimates! They shouldn’t be assumed to be 100% accurate. No one is psychic, and things can come up that couldn’t have been foreseen. There might have even been changes to the feature, given the way Agile software development works.
Managers who set Sprint items, deadlines, and release dates need to be very conscientious of this. All too often, when a developer goes beyond their estimate, QA is then given 1/3rd or less of the time from the initial QA estimate. Even worse, QA is often blamed for not being able to finish testing in a reduced amount of time that they said from day one wasn’t possible.
Anyone who has worked in QA for a while has likely noticed a dichotomy between the way managers see developer timelines vs. the way they see QA time. Often managers don’t blame developers even if they take four times the amount of their estimate to complete a task. Again, this may be very reasonable given how tough estimating can be. Yet at the same time, many managers will become upset at QA if they can’t finish testing in a fraction of their initial QA estimate.
Release Timelines
The estimates issue can be solved by always building in extra time – every single sprint – and being more flexible with release dates. It’s better to push a release date by a few days and have a high quality, user-pleasing release. The unfortunate alternative is to rush it for arbitrary reasons (which is also the opposite of Agile). Pushing a release before it’s ready can result in thousands of angry users, and the loss of their accompanying dollars.
Company-Level Doubt
Some companies think that they don’t really need QA. Not everyone realizes that even the best developers can have bugs in their code – and said bugs aren’t always easy to find.
Other companies hire QA testers, but treat them like unskilled entry level workers. Many don’t respect or take advantage of the fact that they have people with expertise and innate knowledge on user experience, best practices, process, and more.
Unless you have a strong QA manager, it can be very difficult to affect change at this type of company. If at all possible, it’s best to avoid even working for a company like this. Surprisingly, the paycheck is not always reflective of their disregard for QA. But the daily job experience can be discouraging and demotivating.
It’s not always easy to tell during an interview whether a company has full enthusiasm and appreciation for QA. But one sign that can help is whether the people you speak with during the process sound upbeat at the idea of your role coming onboard.
Product Managers/Owners
A good product manager or product owner will love the idea of having a strong QA team onboard. Finding out about bugs and user experience issues and deciding which to address is an essential part of an active product owner’s job.
However, there are some that reject the idea of QA weighing in on user experience. They may only want to hear about showstopper bugs. While this can make sense in some capacities, generally speaking, it’s a mistake. In fact, it often results in a severely lower quality product. Users don’t just see product quality as a lack of obvious bugs like crashing or freezing. If the user experience itself is poor (for example, having to follow too many steps to get to a profile editing screen), this can alienate large numbers of people.
Customer Service
Sometimes QA will work with Customer Service in the form of hearing about user complaints. This can be extremely helpful, as it can help QA look into previously unknown issues (which may not have been happening in the specific situations or devices that were tested previously).
Other times, though, the communication between Customer Service Representatives and QA testers can be a little more tense. As a result of pressure they’re under (either from managers or snappy customers), sometimes people from Customer Service can be impatient with QA, and not realize the amount of work that might go into tracking down a bug. Other times, they might blame QA for the bug existing in the first place.
The best way to solve this is to have a set process and regular communication. Even a single one-hour meeting that gives each department the chance to show the other how their daily job works can lessen months worth of tension down the road.
Respect for QA
If you work in QA, you’re often going to encounter some form of hostility from other groups. But this doesn’t mean that sensitive people can’t still succeed in QA, or that you can’t advocate for your role and the bugs you find. “Don’t take it personally” is advice that’s easier said than done. But if you’re new to QA, know that it does get easier with time and experience. The best way to get respect for QA? Treat others with respect at all times, and continue to do the best job possible at advocating for quality.