Ever been in a meeting where a bug was found, and all eyes turned to QA?
Imagine a new feature goes live, but a critical bug slips through. Customers start complaining, and suddenly, QA is under fire. But when the team looks deeper, they realize the issue came from unclear requirements and a last-minute code change.
QA isn’t the last line of defense—we’re part of the whole development process. If a bug makes it to production, it’s not just a QA failure; it’s a team failure. Instead of pointing fingers, let’s ask: How can we improve collaboration to catch issues early?
Have you been in this situation? Let’s discuss!
1 Like
it’s super easy to pin point because “old skool” IT people think QA needs to find all bugs and only QA.
But whenever somebody even attempts to say that to me; I’ll go like;
- Why was there no unit test?
- Why did the devs not find it in dev?
- Why did I not find it in tst?
- Why did nobody mention it during UAT?
- Why didn’t we see this in the refinement together?
- The PO (probably the person asking the question…) approved it himself?
QA is carried by the whole team and not just the tester.
I think that’s a broad answer and very dependent on your projects context but the easy answer is “shift left”
4 Likes
Could it also be that QA self-assigns the blame, rather than gets it? There is a healthy curiosity in asking if there was something you could do differently, and it starts from admitting that there could be.
I find that most blame I feel comes from within, not from how the others around me express it. Eyes turning to me is not, to me, a sign of blame, but a sign of giving me space to think about it out loud and ask how we could improve collaboration to catch issues early. I tend to have a systemic view to our collaboration as I coach the team on quality practices.
5 Likes
Because testing is invisible and visible test cases nobody looks into it either they will not add huge value, who needs them?
Blame cultures are generally toxic and full of dysfunction, worse that I’ve seen managers do this.
However like one of the other comments I have been in healthy rooms where dev, designers and testers are all saying “balls how did I miss that” or “I know how we missed that” at times alongside what can we learn so we cover it next time.
We remain wonderfully human and judgement calls are a natural part of developing at pace.
“There will be bugs” is something I am comfortable with in a very positive, healthy way but it remains a view that a carries a small risk of complacency or lack of due diligence which for some puts it in a “can’t get my head around that concept” model and blame may then be a fallback response.
1 Like
Since QA is responsible for testing, they are often the first to be questioned when a client reports a bug.
Although we follow the agile model, where testing is a shared responsibility, the long-standing stereotype that QA alone is accountable for defects is likely to exist for some more years.
There is also a common misconception that testing is easy and that anyone can do it. Because of such thoughts, testers become easy targets for blame when defects slip through, as it creates the perception that they failed at an easy task.
However, when a production bug occurs, the focus should be on RCA rather than a blame game. The entire team should work together to identify the cause and implement a fix.
Every defect leakage should be treated as a learning opportunity, and all team members should prioritize understanding the issue to prevent similar occurrences in the future.
1 Like
Because all dissatisfaction from external customers comes to the warranty, no matter whether the product problem is caused by transportation or improper use, they will complain about it first.
I agree with @maaret and @andrewkelly2555, that if I feel I need to take responsibility for missing a bug in production then I’ll hold my hands up and plug the gap. We should have a passion for plugging those gaps.
I said responding to another question, I do feel that we have to sell our capabilities within organisations and teams more than we should have to to be involved earlier in quality decisions. Sometimes the team collaboration starts when others think they’ll need us, so its good to stick your foot in the door when there’s an opportunity to change mindsets and sell our capabilities in ideation and design phases.
Overall, though its very rare for me to work in a finger pointing blame culture…because I’d either work to fix the culture or get out if it was a systemic characteristic of the organisation.
Unfortunately, blame is often the response to a bug. When a bug is found we need to look at the system to find the cause: Don’t ask “Why did the tester miss that bug?”
3 Likes
Maybe because they feel like we are know all about what we test, also they feel like we are last gate or green light. There is no way 100% free bugs, we are still human that can have error or not perfect. Like QA are superman test all with no one bugs left. When bugs found or something wrong always get blame or been pointing out. But never appreciate when test get done or our hard work to test all we can do best.
I recently discovered the work of Chris Argyris and he wrote about how defensiveness prevents learning. I wonder if defensiveness is what causes testers to be blamed and prevents companies from learning from errors? Testers should not be defensive - A review of “Teaching Smart People How to Learn” by Chris Argyris