"But Steven, you're telling devs they should consider a QA career!"
Yeah, yeah, you caught me. I'm trying to communicate a nuanced point here.
Devs can be great QA, but they shouldn't try to be both for the same task. It's a perfect recipe for disaster. I should know.
Story time...
I Tried to Do Both
While I was a Frontend Apprentice, I worked on what seemed to me a very simple task. When I sent it to QA, I was confident in my work and considered QA Review a formality, because as a QA myself, I figured I would have caught whatever bugs there were.
It took the QA a few minutes to find something I hadn't thought of.
Even as a QA by trade, because I was doing development work, my mindset was different. I was focusing on making the thing work, not breaking it. In order to catch what the QA had found, I would have had to context-switch to think like a QA and take another look at it. They're 2 different hats to wear, and you can't wear both at the same time.
The mindset is different. Dev wants the "happy path" to work as intended. QA is only concerned about breaking the application. This is easier for them because:
They aren't responsible for fixing what they find
They are rewarded for every bug they find
Meanwhile, devs are rewarded for:
Shipping features fast
Bug-free code
This is why you should NEVER have developers test their own work. It's a conflict of interest.
Practical Reasons
Bard's answer:
My Thoughts:
It's absolutely true that a developer's time is better spent on high-leverage Dev tasks, which does not include testing if there is a QA Engineer on the team. They need to satisfy code coverage requirements with their unit tests, but after that, it's more valuable to the team if they start fixing a bug or coding the next feature.
When you take their limited time for testing activities with their lack of testing experience and emotional investment in their work, it's a big ask to expect a developer to find more bugs than a QA. After all, if you're measured by how much you deliver, why would you want to slow yourself down? What if you only find low-priority bugs? The incentive just isn't there for a developer to do high-impact QA activities.
And that's fine. That's why QA is so awesome! We take that pressure off of devs so they can focus on what they do best: making stuff work.
Psychology-Based Reasons
Bard's answer:
My Thoughts:
In addition to this, RAS (reticular activating system) is going to be a factor. Because Dev & QA mindsets have polar opposite goals, if you're thinking like a QA, you can't be thinking like a Dev, and vice versa. You have to do a mental context-switch in order to have both perspectives.
I asked Bard to give me an example of how this might play out in a real world scenario with a QA & Dev working on a feature together.
The feature is an image uploader:
The dev will probably miss things that aren't working as intended because their focus is to get the thing to work according to the requirements the team has come up with. The QA, because they're learning how the feature works, will probably use it in ways the developer didn't anticipate.
It's like giving a child an apple who has never seen an apple before. We'd expect them to eat it, because that's what we would do, but this child has just seen their first apple. They don't know what it's for yet. They might throw it, squeeze it, examine it upside-down, and in the process, they might find something we didn't see, like a brown spot or a missing stem.
It's the QA's curiosity and attention to detail that enable them to:
Learn quickly how the feature is supposed to work
Identify ways the feature could break
Notice the tiniest imperfections in a feature as they use it
The QA doesn't own the code for the feature, and they don't even know what it looks like. They have the benefit of being a new user who has no prior familiarity with the feature. This eliminates the problems of ownership bias or confirmation bias, per Bard's response.
At the end of the day, sometimes the best value a QA can provide is being a 2nd set of eyes. Not being the developer means you can be more objective than the developer.
Conclusion
Devs, if you're interested in becoming a QA, you're well-equipped to understand features in a way the average QA won't. As someone who's been under the hood, you can bring your diagnostic skills to the QA world and help describe bugs in a way that most QA can't.
But if you're trying to do QA's job and yours, you might want to leave testing to the dedicated QA Engineer. They're going to find things you'll miss, and that's not a reflection on you as an engineer, it's the way it is. Our brains aren't wired to do opposite things at the same time.
If you do your job right, QA will have plenty of work to test, and you'll get to do more of what you love: making stuff work.