What makes a good tester can make for a hot topic.
So we decided to dip into (but not engage in) the debate in Ministry of Testing’s Slack channel to gauge what the general opinion was among our fellow testing and QA folks.
Some would argue that attention to detail, being proactive, being a good communicator, working well in teams and across all disciplines were key criteria.
But doesn’t that apply to every profession?
So we wanted to dig a bit deeper. Here, we summarize what we found along with our own take on the matter.
Let’s take a look.
In our deep dive, we encountered three criteria you wouldn’t normally hear people pull up in an interview when trying to land a job. But in the world of QA and testing, it’s a different story.
Assuming the worst is a great thing when it comes to testing. You shouldn’t necessarily walk around and assume programmers are shipping code that sucks, but you should assume there will be ways to break it. Because that’s your job. If it can be built, it can break.
If you’re applying Murphy’s Law to any case and any scenario (and testing those scenarios) then you’re probably great at your job.
As Kent Beck once noted, “Optimism is an occupational hazard of programming; feedback is the treatment.”
As testers, our job isn’t to get the code ready to ship as quickly as possible. It’s to make sure we ship a great user experience (as quickly as possible). In order to do that, we need to break things. So even if that sprint deadline is approaching at a roaring speed, no one should be sitting in the retrospect meeting the following week pointing to shortcuts they took just to ship something.
If you approach testing with an attitude that says, “I wonder what will break if I try this?“ Well, then you’re probably a good tester.
“Bad programmers have all the answers.
Good testers have all the questions.”– Gil Zilberfeld
A set of user personas is a great asset. But one should ever assume that the way users actually use the product falls within the premise of those. That’s why looking at how different types of people (beyond your user personas) interact with the product and how the systems react is important.
So if you’re a tester that – dare we say it – ignores the guidelines, then you’re probably a keeper.
What makes a good tester often depends on the testing mission. But as a general rule, you’re probably a great tester if you know how to break things. Of course, you don’t have to come at every case like a wrecking ball, but rather each case should be assessed uniquely.
And on a parting note, always remember that blame doesn’t fix bugs.