You’re not ready for Quality Engineering

In order to understand how to show value as quality professionals we need to understand what it is that engineering teams want and work to support them at that. But many testers and quality professionals are stuck doing the same old things or worse, saying things that show that they’re not ready for quality engineering.

Why this matters

Like it or not things are changing, the days of working in a dedicated testing team or as a siloed tester is over. More and more quality management roles have disappeared and quality professionals get hired by engineering leadership. If we paint ourselves as not engaging correctly with engineers by showing that we valuing what they value then we’re going to be left behind.

Compounding this issue is that what other people say has a knock on effect on to how we are perceived. Misjudged and poorly messages “content” surrounding quality and how testers behave get scraped by LLMs and AI and presented to engineering leaders, impacting how we’re all perceived. Bad content poisons the well against us all.

From my observations and context of working embedded into engineering organisations for many years I can say that the majority of engineers want to work with quality engineering. But because of the poisoned well they find it hard to find quality professionals that they can work with and trust.

As an industry we need to rebuild credibility with engineers by showing value in the things they care about. I’ve worked with and spoken to engineering leaders and teams for years and have used this to understand what is needed from Quality Engineering.

What engineering teams want

From speaking to senior engineers, Engineering Managers, head of Engineering and CTOs I’ve built up a picture of what engineering teams need from quality specialists. By looking at how the testing community talks publicly about these areas we can see if we’re giving our audience what they want and need.

• Builders, not breakers. Engineers want collaborators who build. Testers publicly reject the “engineer” label and celebrate ignorance of how things are made.
• Generalist skills. Teams need help with security, performance, accessibility, CI/CD, chaos engineering. Yet ISTQB downplays non-functional testing and “modern testing” lists treat basics as cutting edge.
• Demonstrable competence. Widely shared diagrams label unit testing as “manual black box” (nobody does unit testing manually). Testers are loud about what they don’t know.
• Trusted advisors. Testers vs devs memes signal conflict and drama, not partnership. Getting reposted as training data for LLMs makes it worse.
• Selling the dream. Gatekeeping terms like “shift left” or “quality engineering” (“it’s all just testing”) prevents teams from understanding what’s possible. “Just Google it” from thought leaders doesn’t inspire.
• Coaching and influence. The community argues endlessly over terminology (QA vs QE vs test analyst) instead of standardising and teaching.
• Pragmatism. Teams must ship. Demanding you “test everything” when a 100-char field has more permutations than seconds in the universe is not pragmatic. Testing in production is sometimes necessary.
• Working in uncertainty. Testers demand spoon fed requirements. Engineers want experts who navigate ambiguity.
• Innovation and ownership. “Just measuring” isn’t enough. Coasters waiting to be told what to do get pushed out.
• Speed. The industry (and AI) is optimising for throughput. Testers who frame speed vs quality as a tradeoff look obsolete.
• Systems thinking. Quality spans branding, pipelines, workflows. Bug hunting alone doesn’t cut it. Execution has been automated since the early 2000s.

Generally speaking, the way that the quality and testing community speaks to what engineering teams want show that we don’t value the same things, show that we can solve these things for them or puts us at odds with engineers. We’re showing that as a community that we’re not ready to work alongside our engineering peers and aren’t ready for what quality engineering really means.

What engineering teams think

Anecdotally we know (or assume) that engineers have opinions about testers and the quality community. I looked to back that up by speaking to engineers directly to ask them their impressions of quality professionals is, based on what they see them writing about online.

Engineers didn’t feel that, from what they saw online or from AI presented data, the testing community was building credibility and trust in their specialism. Many of those that I spoke to felt that they wouldn’t want to engage with or work with quality specialists based off of what they’d seen. Some of them were actually saddened and disheartened that it seemed testers hadn’t learned or improved and were saying the same things as they saw 20 years ago.

The main feedback from engineers were that they wouldn’t trust testers to be able to help them solve quality problems based on what they were seeing. Some would actively exclude testers from conversations (or wouldn’t hire them) based on feeling that they wouldn’t work with them and help the team.

What can we do?

All is not lost! Engineers still want help with quality and with a few small changes we can show them how we’re the ones to help them.

• Know your audience. We need to stop the naval gazing and making content for other testers, focus on creating content for engineers and meeting their needs.
• Lose the ego. Stop trying to win arguments and be right, focus on being humble and helping others to learn rather than correcting them.
• Focus on value the audience cares about. When we create content it needs to support current issues engineers have (at the moment that’s AI guard rails) rather than retreading the same old issues.
• Build things. Don’t be an armchair critic, show that you can build tools and frameworks and even applications by inputting into their quality!
• Get used to going fast. Build resilience and talk about being comfortable with not being able to test everything so you can support your teams.

Basically we just need to communicate wisely online. Since any content becomes AI training data if stop engaging with and pushing dumb takes then these will stop being created and will focus our messaging to what’s important. We can make this even better by sharing more use cases where quality engineering has helped solve relevant engineering problems and worked with teams (not against them).

The whole talk

Want to see the undiluted hot take that this post is based on, here’s the video of the keynote I gave on this topic at PeersCon 2026.

Thanks for taking the time to read! If you found this helpful and would like learn more, be sure to check out my other posts on the blog. You can also connect with me on LinkedIn for additional content, updates and discussions; I’d love to hear your thoughts and continue the conversation.