What is a common challenge faced by new testers?

You can be part of the conversation and help people new to testing, share your expertise. Bonus points for ignoring my typo :stuck_out_tongue:

What is a common challenge faced by new testers?

  • Understanding test cases
  • Understanding test cases Communicating with colleagues
  • Learning new tools
  • Other (add a comment explaining what)
0 voters
2 Likes

Something that I struggled was reconciling what I learned about testing with the “real world”.

There were certain good practices, definitions etc. that I was taught. But then certain good practices were explained away because of lack of time (though acknowledging it was still necessary) and for definitions: terms meant different things to different people.

Soon as I started to be a bit more flexible with my expectations in this regard and learned that projects need to adjust because of time limitations etc. then it got a bit easier.

I had to learn to pick my battles and also to learn why things are the way they are done.

8 Likes

I’m not sure whether it’s a common challenge, but one thing I struggled with was assessing my own work (am I doing it “right”?).

I was the first and only tester in my company for a couple of years, so there was no one to give me any guidance or mentorship - I was completely self-taught. I was also very lucky in finding the testing community very early on. I think this helped me get started on the right path of what quality and testing is really about. Being exposed to practical, modern ideas about software testing was very exciting for me, but I didn’t know whether I was applying those ideas “properly”.

What really helped me to get the feedback and confidence I needed was starting my own blog, as well as participating in online discussions with the community. Although I still didn’t have direct feedback on my work from other testers, I at least had feedback on the ideas and principles that I was working based upon. I’m very grateful to the testing community for welcoming and supporting me so much.

5 Likes

Finding the balance between what matters in the work of a tester and what is expected of them.

5 Likes

Being badly paid and managed and by that bad motivated.

3 Likes

Learning the dynamics of the team and learning the system under test are usually my challenges whenever I start a new assignment.

4 Likes

One of the major challenges I faced as a new tester was adapting the testing process of the organization and testing a project that is live in a production environment and is being used by real users.

If someone is assigned to the project from the very first day the project starts then they are aware of all the details of the project, its architecture, requirements, scope, etc. but when the project is fully developed and already live and then someone is assigned as a new tester, it is more of nervousness that in case any bug is missed then the real-time users will be impacted and as a new tester it is also difficult to think of all the cases including edge cases.

Also being a new tester, starting of a couple of months are being spent on probation so any mistake will be noticed by everyone, and that thought also makes the situation a bit tense.

These are the challenges faced by me as a new tester in an organization.

2 Likes

I find learning the dynamics of the team to be particularly useful. Especially in terms of how decisions are made, who do people tend to listen to etc.

2 Likes

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.

1 Like