A lot of good points already mentioned. I think one big problem with new testers is that it’s introduced in quite a complicated and strict way. Testing is actually pretty easy to do, it’s only difficult to get really good at it. It’s also sometimes taught as if it’s supposed to be boring and unengaging, as if testing were about self-micromanagement rather than exploration and learning. Sometimes it’s managed that way, too.
Or sometimes it’s taught as if process or tooling were how we approach problems, rather than process and tooling being things we decide to employ when they help us with our problems. Like buying a melon baller will not make you enjoy more melon balls. You need the desire, will and intention for a melon ball and then choose the melon baller. Foisting agency onto best practice or large tools and hoping it cares about the outcome.
There’s a binary rigidity to how some testers seem to be taught things. White box versus black box. Functional versus non-functional testing. Automation tools versus manual. Static versus dynamic. The idea is that these are all options you can flip back and forth between or do simultaneously, but the application of them in tandem isn’t taught, nor how to make that choice, just the definitions or how to do each one.
The presentation of the leaky abstract as if it were reality - The application of boundary value analysis as if boundary values always exist in ways we can predict by the certainty of the UI, or as if there are no hidden or unexpected problems. The idea that one particular technique or process is complete based on heavy assumptions of correctness in the abstract. Requirements documents are requirements. Bug reports are bugs. The logic diagram is the program. The name of an automated check is what the check is doing. The green “pass” means it’s tested. This makes new testers believe too much in documents and diagrams and practices and templates, stopping them from engaging with reality. I find a lot of testers frustrated to tears in ways they cannot describe, and I think it’s often about the fact that what they are doing does not really connect to a purpose they understand or an outcome they value. When they’re able and permitted to engage with reality and provide solutions they believe in then the problem goes away.
When a tester gets into a company full of people, making software for people, each of which with their own personality, wishes, desires and demands, in an ever-shifting project with its tech stack and its deployment practices, and packed to bursting with tacit understanding about all of these things on top of the industry domain with it’s standards and expectations and competing products, and the influence of culture and language and the general use of technology and platform… suddenly the specifics of one way of doing things makes little sense, other than it’s easier to follow instructions than invent them.
I think that if we taught testers that 1. good news, they can already test and it’s fun, and 2. testing is about finding worthy solutions to problems so make effort to understand the problem before you pull out a solution, then we’d have a happier bunch of testers.