I kind of understand how we ended up in a world where people might think Quality Assurance Engineers hate Developers. It’s even understandable how this idea can be amusing to someone new to Quality. What I don’t understand is why certain corners of the Software Engineering community seem to cling to that idea. Times have changed. Ways of working have too. And divide and conquer has never been a good way to build quality software. Everyone working in software development, whether they are engineering leaders, product owners, software or quality engineer. Everyone should want to work in streamlined harmonious teams with an holistic approach to quality. Unfortunately, it seems not everyone has got the memo.
Don’t embrace poor quality culture!
Probably the worst example I’ve seen of a company publicly embracing the idea of building walls between Quality and Developers was this job advert.
Yes, that is a real job advert I saw on LinkedIn! I was horrified that a business thought this was an acceptable way to advertise for a role. Let’s ignore for a moment the issues with the imagery itself. To be advertising a role, you are going out in public and saying “Hi! Come work for us!”. Should a company really be doing that with a message of “we have a terrible culture with a huge rift between disciplines”? Because that is a pretty terrible message!
Breaking down barriers
Rather than dwell on that ill conceived advert further, I thought I’d put together a quick list of some of these most often repeated dividers and address them head on!
Testing breaks code
Testing does not change the code under test, so it can’t break it. All testing will ever do is uncover the scenario in which the code doesn’t work as intended. Teams can then make informed decisions around what to do with that information – Fix it, or accept the identified issue and its associated risk.
QA hates developers
I’ll never understand people who promote a culture of division between disciplines. We are a team! The Quality professional expert in a team should be a champion for good quality practices and processes to ensure the whole team considers quality throughout the software development lifecycle. That means building relationships, not putting up walls!
Testing is slow / Testing is holding up a release etc
I get that in many companies there is a testing bottle neck because quality processes and practices mean that testing is siloed to a small number of individuals. This doesn’t mean that quality is slow, it means your quality practices need reviewing so that more testing happens earlier in your processes.
Why didn’t QA catch this?
Oh boy, this is a loaded one. People have dedicated entire blog posts to dive into the intricacies of this question. In short, I think it’s a valid question. However, only when its asked along side a whole host more like.
- Was this risk flagged before release?
- Could we have prevented this?
- What was missing in our planning/refinement/shaping session that would have helped identify this risk?
- Did we have all the information needed before the bug was found to identify the risk?
- Are we missing automated test coverage that would have detected this issue?
- Did we create adequate automated test coverage, at the right levels of the test pyramid, during development?
- How can we prevent regressions like this reaching production in the future?
If you want to read more on this point I recommend these blog posts
- Why Didn’t QA Catch This? by Mallory Mooney
- Quality Assurance is a Process by EvilTester
- When Management Asks “Why Didn’t You Find That Bug?” – by Michael Bolton
Summary
So in short, stop repeating these outdated tropes! Instead, start working with your teams to build relationships and improve the quality of your practices and processes. Your customers will thank you for it.
Subscribe to The Quality Duck
Did you know you can now subscribe to The Quality Duck? Never miss a post but getting them delivered direct to your mailbox whenever I create a new post. Don’t worry, you won’t get flooded with emails, I post at most once a week.
July 20, 2023 at 6:35 pm
I agree with the thrust of your post: that testers do not hate developers; that it is not the job of testers to discipline developers; that prospective employers should avoid portraying development that are cartoonish and/or wrong; that testing doesn’t break the code. These are all worthy and important to note.
Alas, I stumble over this:
“The Quality professional in a team should be a champion for good quality practices and processes to ensure the whole team considers quality throughout the software development lifecycle.”
I agree. And that means that everyone on the team—everyone —should be a Quality professional.
I worry when testers insist on being called “Quality professionals”, because that runs the risk of setting up silos. That is, there’s a subtle insinuation that people other than testers are NOT Quality professionals. Everyone on the project can legitimately claim to be a Quality professional, or Quality Assurance Engineer, can’t they?
On the other hand, there’s got to be something that’s different about testing.
That difference, to me, is in our work empirically investigating the product; searching actively for trouble; looking for problems that threaten value. Other people on the project might do that, occasionally, as a secondary aspect of their main work of building the product. For testers, looking to find out the truth about how the product really works, or doesn’t is our primary focus.
https://www.developsense.com/blog/2010/05/testers-get-out-of-the-quality-assurance-business/
July 20, 2023 at 7:12 pm
Thank you for taking the time to share such a detailed reply. Although I am ashamed to admit that this is likely just a clumsy choice of words on my behalf, and maybe “Quality expert” would have been better? In the same way that I would consider a Front End Engineer, or Back End Engineer, Product Owner etc as the teams expert in their respective areas of specialism.