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
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.