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

I’m interested in discovering common misconceptions you’ve noticed among Junior Testers around the concept of testing and quality. Do you remember having any yourself early on in your career? How did you overcome them? How do you think these misconceptions arise?

2 Likes

The idea that there is a universal set of “Best Practices” that can be learned and applied to every test situation comes to mind. It took me a while to realize that what counts as best practice for a highly regulated industry like health care in the US is not in any way related to what counts as best practice for casual games.

What got me out of it was a combination of the needs and pressures of the job I was in at the time, and the discovery of Context-Based testing - which didn’t really say anything I hadn’t figured out by then, but it validated what I was coming to see.

1 Like

For a long time, I thought exploratory testing was just random clicking around, I didn’t have anyone to tell me otherwise - that it could have some structure, and most importantly that all testing is (or should be) exploratory in nature.

4 Likes

“ISQTB is Divine” – You “need” an ISTQB certificate.

They arise by companies asking for the certification but the company has no idea what testing is and we heard ISTQB is cool so let’s ask for that certification.
How to overcome them…? Well I switched sides of the interview. When it was me asking the questions, I never really focused on ISTQB because it wasn’t really relevant to what was required.
So therefor ISTQB became redundant for me <3

There are so many people that get this wrong, even 10y+ experienced people :joy:
And then you can just ask what’s the difference with ‘ad-hoc’ – yea that will be a funny reaction! :smiley:

4 Likes

Testing equals writing test cases, maintaining test cases and executing test cases.

4 Likes

For a long time, I was under the misconception that it was really important that all code changes come with well defined requirements, and any deviation from those requirements was a really important bug that needed fixing.

Over time, I’ve realised that initial requirements themselves need testing, are often flawed, and rarely stand up to battle with implementation. I’ve learned to take a more collaborative and pragmatic approach, and ask questions like “this differs, in this from what we said we were going to do in . Are we happy with this change, and if we are, how can we document it?”.

I raise very few bugs now compared to being a new tester, but I truly believe my impact on product quality is way higher.

4 Likes

Another misconception I had early on was that testing can start only after the developer has finished their work, moved the ticket to the QA column and handed it over to me.

Then I started to realise that talking to people during or even before development makes things generally better. But for quite some time that felt like I’m overstepping my role. That changed only after I’ve listened to a talk on MoT called “Let’s go larvae hunting” (I always forget the author’s name, sorry). It was a huge eye-opener - wow, this is not just me being nosy, this is actually a thing other testers do as part of their job! And now I have the “permission” to make it an integral part of my job too!

3 Likes

Same here. Exploratory was for me I just try it, see if it still works. No plan, no clue, no documentation

2 Likes

That is still the case for some projects I do. Managers want to see test cases. If there are no test cases there is no testing . :triumph:

3 Likes

There was a time when retesting = regression testing for me. This until a QA manager asked by I had so much time booked on regression testing and then explain that to me what I was actually doing and how it is called. Took him about 3 months to discover the “wrong” time booking :smiley:

1 Like

I can tell you a tonne of misconceptions from others… :sweat_smile: When I was a junior/mid level tester I got told I was there to do manual repetitive tasks. Yeah, we had to repeat a particular set of tests on all these servers…but to judge my whole role on that … I got a new job a few weeks later.

3 Likes

Related is the idea that there is a fence. There is no fence. I think this notion came about early on, when the role of testing first became a things, and where ideas like TQM demanded the test organisation to be very separate and independent from development. There is no fence. Just people at the coalface, working together for the same objectives.

5 Likes

Yes! Thank you for bringing this out!
When I’m scrolling through job ads and see that “ISTQB certificate is required” for a QA position, it’s an instant red flag for me.

5 Likes

For me - “QA does all the testing” and “QA is the safety net”.

Oh, how wrong was I and it. Fortunately, now everyone in my company understands that QA does not do all the testing-related activities, it’s a shared responsibility and QA is not there as a safety net for developers, but rather an additional service developers can use to help verify their new features/tasks.

I guess we are still slowly over-coming it. It’s a slow process that takes time but the more we talk about it, watch videos/conferences, read books, the more better it gets.

1 Like

Testing is boring.

I blame this misconception on exposure to bad testing that reduces it to writing a bunch of test cases/protocols, rote execution of said protocols, and documenting the results of said execution.

For which I blame prevalent factory testing mindsets as exhibited in prevalent testing so-called training materials like ISTQB.

4 Likes

The biggest misconception in testing is that it’s easy and doesn’t require hard work and learning. A low-status activity not worthy of respect. Something a dev could do if they weren’t so busy doing the real work.

There are a lot of testers who don’t really know how to test very well, so a development and factory mindset creates a role for testing on their behalf rooted in fear and steeped in explicit test cases, and ISTQB can pretend to be a effective gateway to proving ability despite being almost entirely pointless. Poor testing then advertises to the world the low value of testing, and we attempt to replace those people with a mechanical version of the cases they used to run, and now the AI question, whose specificity to replacing tests and testers is deeply insulting to the complex and difficult nature of good testing, as if testing or making tests is the thing to be replaced, or as if automation tools are anything except a good idea taken too far by people who cannot think about testing properly, and who look identical to good testers who use tools responsibly.

The single biggest and most prevalent misconception in testing is an en-masse lack of understanding of what testing is, what it involves and what it can do, rooted in the archaic nature of the testing industry as it stands, and also its biggest problem and biggest threat.

7 Likes

Oof! Totally agree on this misconception! I always say; You get a new piece of software that nobody has ever seen before. You get to break it down, hack it, nuke down servers and criticize other peoples work… AND get paid for it #DreamJob :stuck_out_tongue:

1 Like

Another misconception (and I don’t know why I didn’t mention this before):

“Testing is just clicking buttons”

1 Like

In the same vein, another misconception is that testing is all about verifying the acceptance criteria (happy path and unhappy path). I don’t know where this came from, it’s more like I was thrown into a project and it seemed to be the expectation.

I had to learn not to accept the acceptance criteria at face value. By learning about heuristics and questioning critically, I realized I could unearth more quality issues. I thank James Bach for his youtube videos, that’s what opened my mind to what testing really means.

4 Likes

Thank you, everyone, for your replies. I’ve collated what you’ve shared and will be running the following task analysis session on advocating quality for the Junior Curriculum today:

If you have the time, I’d for you all to join and share your thoughts further. This is an opportunity to help build the next generation of testing education for juniors.

2 Likes