MYTH: Developers don’t like me because I’m a tester!
HARD TRUTH: It’s not because you’re a tester. It might just be you.
Before I started my career as a software quality engineer, I often heard that the relationship between developers and testers was a rocky one, at best, and I braced myself for that reality. To my surprise, that tumultuous relationship never came to fruition, and I have never had anything but positive experiences working alongside developers.
I have, however, witnessed this rocky tester-developer dynamic as a third party, and it almost always boiled down to communication.
That isn’t to say there aren’t difficult developers (or difficult QEs, for that matter). In most work environments, we are exposed to a multitude of personalities, and everyone has their own quirks. However, if you find yourself generally having difficult relationships with developers, it’s likely that it has less to do with you being a tester, and more to do with your approach.
What are some ways we can combat this?
Be curious, not presumptuous: “Your last PR broke this functionality” vs. “I noticed this behavior in the application and wanted to bring it to your attention. Do you know what might be causing it?”
Be constructive, not critical: “Everything was working just fine until you checked in your last change” vs. “Thanks so much for a quick turn around on this feature! Mostly everything looks great, but there is this one area that seems to have been impacted by the change. Can I show you what I’m seeing?”
Lastly, breathe and remember the old adage about flies and honey. Much like death and taxes, defects and delays are something you cannot escape. Remember that they’re equally as frustrating and stressful (if not more so!) to the developers.
When all else fails, it helps to assume people are always trying their hardest and doing their best.
MYTH: I’m going to automate 100% of my tests!
HARD TRUTH: It’s almost 100% certain you won’t.
I have sat in quite a few interviews and have had multiple conversations with development managers where they have expressed the desire to automate 100% of test scenarios.
I love the ambition, and yes, we should shoot to automate as much as we can. The unfortunately reality is that it is currently impossible to automate absolutely all of your testing.
Consider usability testing, for instance. There is a real human component needed in order to understand UX issues in an application that would otherwise not be picked up by automation efforts.
While there are rumblings of AI and machine learning in the test automation space that could cover this in the future, we are not quite there yet.
MYTH: I let a bug get to production. I’m bad at my job.
HARD TRUTH: It happens to the best of us!
There are few things that will make a QE’s stomach drop harder than hearing a feature they tested introduced a bug in production.
You start going through the motions: manually verifying each passing test, tracing your steps back to find where you could have possibly let something slip through.
You fly through all five stages of grief in a surprisingly short period of time.
Finally, you attempt to convince yourself you’re still good at your job, even though there now hangs a cloud of doubt over your head.
Look, we’ve all been there, but feeling guilty about a missed bug is wasted energy. Whether a late addition to the release cut introduced a defect, a change impacted an area you were certain wouldn’t be impacted, or you just straight up missed something glaringly obvious…it happens!
Just like our developer friends who can sometimes make mistakes that introduce a bug, we are equally fallible and can fail to catch it. What matters most isn’t the missed bug, but the steps taken afterwards.
The best quality engineers I’ve known have never let a bug get them down; they own up to their mistake, they make necessarily process improvements, and are vigilant in being proactive against future defects and regressions.
You don’t sweat the bugs, you just learn from them and do better in the future.
Whether as a developer, quality engineer, or manager, what are some hard truths you’ve had to learn?
