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?
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 
And then you can just ask whatās the difference with āad-hocā ā yea that will be a funny reaction! 
3 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.
3 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 . 
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
1 Like
I can tell you a tonne of misconceptions from othersā¦ 
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 
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