What misconceptions are junior testers taught early on around testing and quality?

🙋 Questions
, , , ,
21

What about automation being part of testing? It is, of course, in the sense that a person with the job title of tester can also do automation. But so can a librarian, a nurse or a pilot. The skillsets are so different that things make much more sense if you see them as different roles at least. And considering that the fields of testing and automation are both vast, it makes more sense to (quickly) assess which of the two you will probably like most and focus on that. Dividing your attention over both will mean learning less of either than you could have. In my eyes, anyway. How do others see this?

1 Like
22

A few things I’ve noticed, I don’t these are taught per se but they happen over and over again:

  • A lot of testers assume certain things are “too technical” for them to understand, and so they don’t try. By asking questions and trying to understand complex, technical changes at their core, you can become a far better tester. You don’t need to be able to write the code to be able to understand it.
  • Not testing outside of Acceptance Criteria. The AC do not necessarily cover everything, some things are implicit, some things are unthought of. And neither are they always correct. If it doesn’t look right, question it.
  • The assumption that developers are smarter than testers and shouldn’t be questioned/challenged. I think this comes hand in hand with imposter syndrome (rife amongst testers in my experience). How could I, a lowly tester, be right about this, and the super smart builder of things be wrong? Ask “stupid” questions, sometimes they can change a whole team’s view on things.
2 Likes
23

How do others see this?

That tools in testing must serve a wider test strategy. Every automation engineer is also a good tester or how do they know that what they’re doing is valuable? If automation doesn’t serve testing then what’s the point of it? If they can’t explore efficiently and understand the cost/benefit of test repetition how do they decide on what’s to be put into the tool? People who do automation without consideration of the craft of testing must believe that testing can be automated - they’d have to believe in the abstraction from intent to code. People who think Gherkin really describes what the computer is doing right down to the assumed implicature. People who don’t understand the significant difference between coded checks and humans attempting to perform the same checks. So I’d say feel free to concentrate on building and maintaining a code base of checks and become a tool expert, but you need to be a tester, or directly supporting a tester, for it to serve testing and avoid the traps of comforting superstition.

24

There is another misconception that my manager asked me in an interview: Does every development team need a tester?

3 Likes
25

There is another misconception that my manager asked me in an interview: Does every development team need a tester?

That’s not a misconception, that’s a question :grin:

But some common answers to this question might be misconceptions. E. g.:

  • yes, because developers are fundamentally unable to learn how to test
  • no, because testing slows development down
  • no, because testers need to be independent of development teams so that their testing is not biased
4 Likes