Testers have to be the ones to advocate for quality
Testers have to be the ones to Advocate for Quality
I’ve seen a number of conversations of late with testers being frustrated at having to be the ones to fight for quality in teams / organisations. There’s a prevailing commentary that quality professionals not only are the only ones thinking about quality but also need to fight for a seat at the table to discuss these things.
Here’s my hot take; testers need to be the ones advocating for quality because we’re the ONLY ONES WHO CAN.
The state of the industry
As people who live an breathe thinking and talking about quality and testing on a daily basis it’s easy to think that quality is a solved problem. Within the testing & quality bubble on social media, forums and conferences we communicate what we mean by quality and what that looks like a lot. Outside of that though, quality isn’t really a solved problem; it’s not well understood or even considered.
To many in engineering teams, quality begins and ends at “have we built the thing that was asked for?” This can be seen with the types of testing that they do being focused on verification, asserting that requirements or acceptance have been met. We see this manifest as a focus on automated and scripted tests with a pass/fail result or even statements of quality being limited to delivering on what was asked for.
I made a quick Google search of “software quality” and we can see that the prevailing commentary from search results (and AI) is conformance to requirements.
This comes about because that’s what engineers have been taught. CompSci degrees speak of testing the code and asserting correctness and not other forms of testing or quality. Organisations and teams tend to also focus on teaching engineers to assert correctness for the sake of speed. We also see product managers thinking as correctness of requirements because to date, that’s all they’ve ever seen.
Engineering teams (generally) do not know the art of the possible when it comes to quality and testing.
Why should Testers advocate?
In a world of the basic assertive types of testing being solved by automation and AI, testers need to advocate for what quality is to have meaning. In the current and changing industry needs the days of needing specialist test executors is diminishing and so we need to find a new role; Quality Coaches and advocates.
Why we should be the ones to do it
Because we’re the experts! Who else is better placed or has the training to be able to advocate for what quality and good enough for a team / organisation is. Quality is multifaceted and complex, so it takes a specialist to be able to interpret it and to be able to show people the art of the possible.
In teams of doers and executors, most Product, Design and Engineering folks will be focused on the HOW of delivery. We see it all the time, people rushing to the solution of how to solve a customer problem or how to build the thing that’s been asked for; what it does or looks like. Somebody needs to be focused on the WHAT, looking at what is it we actually want… what problems does a customer want to solve and to what level of good does this need to be. if you’re focused on HOW (likely because of time pressures) then WHAT can get forgotten, especially when it’s not something you;re naturally used to thinking about.
So in steps the tester as a Quality Coach and advocate. We think about this stuff ALL THE TIME and it’s second nature to us. Questions about what non-functionals matter… we read an article about that ages ago. Knowing what types of quality attributes will help speed up the team’s delivery velocity… yup we did a workshop on that last week! Because of our specialism, quality is all top of mind for us and so it’s easy for us to push for it, even when we have to go fast!
Why should we have to be the ones do it
Eurgh, why us? Shouldn’t they just know this stuff?
Okay, I get it… it’s annoying to constantly feel like you’re the only ones in the team to be pushing for quality. I’ve seen many posts on social media and in forums what lament the state of affairs where they as a tester seem to be the only one that’s driving for quality.
As I spoke about above, teams don’t know the art of the possible. We have to remember that for a lot of our colleagues that quality isn’t something they’ve learned about or know about. Somebody has to teach them as their teams and previous education won’t have covered quality and testing.
I think that we can assume that engineering teams know about quality (or should just know) but when we pick apart that assumption we can see that there’s a strong need for education and outreach. That falls to the closest experts that our teams have… us!
Why do we have to beg then?
The follow up to a lot of the social media posts is saying that we testers can see a gap (knowledge about quality) and then have to fight or beg for a space at the table to teach others. In my experience, this comes from not knowing the art of the possible but also thinking that testing is a solved problem.
Remember above how I said that engineering teams tend to think that quality just means meeting requirements. If that’s all you think that quality and testing is / can be then you likely will think you’ve solved testing with the pass / fail assertive tests that come with automation and coding. if that’s the case then why would I need to shift left or discuss testing earlier: you can only test when we’ve built things so you don’t need to do anything earlier than that!
Attempts to talk about quality or testing beyond the assumption that teams have, that testing is just assertive and is a solved problem, is going to be a hard sell. It can feel like having to beg because we see the value in what we’re asking for and others cannot, because it’s something that’s brand new to them.
There’s also the problem of a common anti pattern; that testers are there to get one over on engineering teams and prove them wrong (rather than work with them). We’ve all seen the memes everywhere that seem to pit engineers and testers as enemies, or the ones that show testers celebrating when they find a very obscure bug.
Engineering teams have seen them too! So when you come to them with an awesome idea for more quality or helping with testing, the initial reaction can be “they just want to tell we that I’m wrong earlier!” Nobody wants that, so teams then disengage and don’t listen. Or if our testing hasn’t supported the team, finding edge cases and bugs that nobody cares about, the team starts to dismiss testers as having too high of a quality expectation or too high of a bar for quality.
The worst thing is that these attitudes can be carried over from previous experiences and have nothing to do with you!
But you hired me as a tester…
Following on from having to beg is our assumption that since we’re hired as a tester, we should be expected and allowed to test and not be blocked. In response to that I’ll ask,
what is a tester?
A big problem here is that there’s no defined definition of what a tester really is or what the role encompasses. Plus, the more that we argue away from trying to define types of testing (there’s no manual or automation, it’s all just testing) then the harder this becomes to pin down.
So then it falls to potentially the assumptions of your team to define for themselves what a tester means. If they think that all quality and testing is basically asserting that you’ve just met the requirements through scripts then they’ll assume that’s all a tester can / should do.
Engineers and teams don’t know the art of the possible when it comes to testing, so their assumptions of what testers do in their role is limited. That’s why we see so many job specs focused on automation and scripted assertive tests: because that’s all anyone knows about what testing can be!
When you’re hired as a tester, there’ll be an in built assumption of what that means from your manager, organisation, team, the board and investors. We might think that we’ve been brought in to make things better and champion quality, but others might not think that… so then we have to beg to be able to do what we think our job is.
What can we do?
Things need to change and things are changing. We’re seeing many more organisations talking about modern testing; things like Quality Engineering, Coaching and Shifting Left & Right are becoming more commonplace. Even in job specs we’re seeing a move towards more testing advocacy roles. But what else can we be doing now to help move things along in our organisations and in the wide?
Show the art of the possible
People don’t know what they don’t know, we need to be able to show people what quality could look like in a way that’s meaningful to them. Whether thats a gap analysis, quality radar, a model or proof of concepts, you can help your teams to see the gaps in their quality thinking to see a need for bringing a quality specialist in.
- Focus on their context, you’ll get more engagement if things are meaningful to them.
- Be kind, you’re a teacher here and not looking to shame people.
- Engage at their level, bring code, engineering, product and dev ops into the discussion.
- Say this is what’s possible, you;re not expecting them to do all of this immediately.
To be able to show the art of the possible will mean doing some research and work. Look into different types of quality and testing so that you can speak to a holistic view of the gaps in testing.
Build trust
Be a trusted advisor and show engineering teams that we’re here to support rather than just critique. We need to influence people and win them over, so we’re going to have to show that we’re all on the same side together.
- Talking with the team about how good does this need to be? Rather than stating a bar for quality at them.
- Not rushing to raise every single minor issue that nobody would ever care about.
- Being credible by being able to talk about engineering and solving their problems.
- Being flexible to different ways of working and not dogmatic.
- Roll your sleeves up and show people what’s needed, don’t just live in a world of models and hypotheticals.
Do wider outreach
The testing community needs to show what quality is to engineers, CTOs and hiring managers. That means we need to be more involved in their conversations and making sure that when testing is searched for / asked about in ChatGPT that the right things come up.
We need to be asking what our content says about testing and how that’ll impact an engineer’s view on the art of the possible for testing. If all anyone can see about testing confirms the view that they’ve solved the testing problem or that quality just means passing requirements then nobody will learn.
We need to be all swarming on the same outreach; creating enough content that all say the same things about the art of the possible in quality and testing. That way searches and ChatGPT will show engineers and organisations that they have gaps in their quality thinking and look to testers to help them.
Ideally, this could also mean stopping fighting over things in order to be technically correct. By saying “all testing is testing” or refusing to provide clarification over what types of testing activities a type of tester can do, how are we helping others to understand us, understand testing and understand quality?
So yes, like it or not, testers have to be the ones who advocate for quality. Because nobody else can.
