Challenge misconceptions of software testing by providing a rationale alternative

Over a lot of my career I’ve had individuals who have had misconceptions about what I do. I’ve come to the stage, where I might have heard it all — from testers only get involved in the build stage, we only write test cases, Testers are not technical so I don’t need to be in a meeting or what I’m there to do is repeat boring manual tasks.

Are you a software tester that has experienced a similar thing? Are you going through it currently? I’m here to say you’re not alone!

There are many people out there, including myself that have experienced this or continue to. I’m here to say, even when people have all these misconceptions, fight the good fight, and don’t stand for it. Call out and correct them.

I am involved in all stages of the life cycle. I DO NOT just write test cases. I most definitely do not repeat boring manual tasks. I am VERY MUCH technical.

These are some things that I do:

• Raise risks and issues in a way that stakeholders will understand.
• Always be my authentic self — especially when things feel a bit socially awkward.
• Ask for what I need e.g. I need to be in this meeting or I need to understand this because of x reason.
• Be open, transparent and honest. Sometimes when calling out things I have admitted that it feels a bit awkward to call it out. I am human and it’s fine to feel awkward. I feel this is a strength to be human and myself, always.

The real question here though, is how do you remove someone’s misconceptions about what you do? My two tips would be:

1. Show your value by doing ^ points written above
2. Explain what your reasoning is if you challenge someone on a misconception.

Only involved in the Build Stage — If I’m only involved in the build stage, then I’m potentially going to slow the project down with having to take time to get up to speed. It would be better for the project if I understand the project from early stages, so I can clarify anything early.

Not technical — I need to understand the technical detail in order to assess what the potential risks are and where I need to focus my efforts.

Write test cases — Test cases are not the only way test evidence can be provided. We can use all sorts of evidence, such as mind maps, detailed testing notes, tables and so on. Writing test cases in a step by step fashion is a waste of time and does not provide any value.

Overall though, I’m writing this to get it off my chest and to also explain there are tactical ways you can remove these misconceptions with sound thinking and evidence. Never leave a misconception unaddressed and keep doing what you do best.