Quality job titles matter… because they say something to other people
Quality Job titles matter… because they say something to other people
What’s in a name? That which we call a rose by any other name would smell as sweet…
The testing / quality community has, for years, talked about job titles and what we should call ourselves. This primarily (in my opinion) comes from there being a lack of agreed upon standards for terminology across testing but also from a place of wanting to position ourselves as marketable in a changing job market. This can lead to conversations that dismiss certain job titles, either because they’re seen as unmarketable or because they’re at odds to what we’ve seen, how we like to test or even how we’re positioning ourselves. Examples of this can be when people call out Quality Engineer as an unworthy title or marketing stunt, or look to generalise testing job titles to being “Tester”.
Well my current thinking (based on my context*) is that yes it does. Job titles are a form of marketing that we do to help others understand what we do, in a profession where there’s a lot of unknowns we need to do what we can to help others understand how we can help them!
*My context might be different from yours, leading you to make different conclusions and thats Okay!
Branding: Speaking their language
Whilst it’s important to educate the wider industry, that takes time and context to be meaningful to people. I want people to know why they need me on their team or how they can use me to help them, so I want a job title conveys that to them quickly. In my experience that means working with the names and structures makes sense to the teams in questions (by team I mean engineers, product managers, other testers, engineering managers, agile coaches, etc…).
- If that team does quality engineering, that means I’m a quality engineer.
- If that team calls their quality thinking & activity QA, then I’ll call myself a QA.
- If that company wants a coach, then I’ll be a quality coach.
- If that team has a split between manual and automated testing, I’ll be a manual tester.
- If testing fits within engineering, I’ll be an engineer and align myself to their role titles.
My aim here is to see what the company or team might ask for and make it easy for them to know they can ask me to do that. I try not to use too general of a terminology that needs mature quality understanding to be able to decipher things and know what to ask me for.
An important caveat here is to point out that I’m not looking to mislead anyone into what I can or can’t do or try to elevate myself. I look at what the teams call the things I have skills in and can help them with and then call myself that. I wouldn’t call myself an SDET ever because I don’t have the automation skills to back that up.
This [job title] is just branding or marketing and doesn’t mean anything
Some sentiment I see around certain job titles, especially Quality Engineer or Staff+ testing roles, is that these are just marketing stunts trying to sell something to someone. Whilst I’ve seen it used in a dismissive way, this sentiment is actually 100% CORRECT as it’s basically marketing to product engineering teams to sell them the ideas of quality and testing.
Some organisations don’t have testing and quality built into them as a standard. There are many companies and teams out there that haven’t ever worked with a quality professional (a lot of start ups) or haven’t worked with a tester in years after rounds of lay offs. In those situations we need to find ways to engage with and sell testing and quality into the organisation and its product teams. Any branding and marketing that we can do will help with this.
Marketing may also help us to break away from past bad associations of testing. In my experience, some engineers have had poor experiences of working with quality professionals in the past and are resistant to ideas and terminology that looks like those bad experiences. Having a new term and title (like Quality Engineering) makes a clean break away from the past and helps the engineers to more receptive to ideas.
This also helps us in the job market, especially as AI becomes more prevalent and more people are hired by engineering managers than a dedicated quality professional. We need to have job titles that help people quickly see that we are the people that have the skills to fill the quality gaps that they have.
Being understood is better than being right
Some of the sentiment I see online comes down to being technically correct. Technically it’s all testing so why call itself anything else? Technically QA includes full lifecycle quality and not just testing at the end, so we can call it QA.
Whilst this is correct, it’s correct in a vacuum. It might be meaningful in come contexts, like the quality and software testing community, but not in the wider world. Does it help software engineers, companies, CTOs and our wider audience to understand what we can do and what we can bring to the table? Rather than slap each other on the back with how clever and correct we are with our use of terms, can it help to use terms that help bring others on a journey too?
One way we can go about that is to talk about our contexts rather than things in absolutes. Look to the meaning behind a job title and say “Oh at my org we call that thing because of ” to promote understanding. That’ll help people understand where there are synonyms and the main difference is just context, rather than trying to talk about different things completely.
Or at the very least, don’t dismiss a job title because it’s not yours… there might be good reasons why a person uses a certain title. Maybe it’s to sell testing into an organisation, maybe it’s to help promote understanding…
… or maybe it’s just because it’s the title their boss gave them.
