[We continue to explore ideas around Quality Engineering for our upcoming event for The Testing Planet]
Quality Engineering is an evolution of the software testing role
Bonus points for any community commentary
There were engineers doing the quality related work before testers took some of it over.
Testing hasn’t even evolved yet into a mature professional domain of it’s own.
Great testing is very hard, very few testers can do it.
Some places require just testers and not quality engineers.
Others require quality engineers and don’t really need dedicated specialized testing.
Coding of automation in testing was at some point and might still be today seen as an evolution of testing. Similarly I see this trend coming with quality engineering. They are completely different roles or professional domains where some things might be common.
Quality engineering as a responsibility/role for some testers came I believe mainly because there’s so much poor testing being done and testers are so poor to explain the good testing, that the managers tried to find ways where more visible/meaningful impact can be made. Similarly some testers end up doing also things like: BA, coding, automation, tech support, etc…
I believe quality engineering was always a part of software testing, it is just we have realized now that.
Since quality is not the same as testing but depends on software testing we can say that it is something that has existed since starting but as we are now focused on agile projects so quality is now the primary goal instead of testing and it is now everyone’s responsibility in the team.
Earlier when it was waterfall models followed in SDLC there would be the dedicated testing team that would focus on testing the software but now with the agile process, it is a developer who has to prioritize unit testing, and the PM responsibility to gather and analyze requirements and verify that the product functionality match with requirements, then obviously the testing team.
So now as quality is prioritized, quality engineering has also come into the picture because quality engineering drives the quality through continuous testing and new testing practices.
Here’s how I’ve explained it previously (but I’ve since began to rethink it)
QAs test from the client point of view. Starting from the UI and work their way down the tech stack.
QEs test from the developer point of view and work up the tech stack starting from the code.
Each are both a part of testing but look for different things in different ways. I think that can help with figuring out how each role works with each other. By going this approach we can collaborate on what can be automated and what needs a human touch. Having that approach really helped me and my teams understand the domain and specialties.
But now my perspective is changing with how we’ve built up our teams and culture inside my org.
Now I’m thinking that QAs could to be more Analyst than “go click these buttons and report back”. We want to get QAs more involved with planning and strategy. Driving the what needs automation and helping with Code Reviews (specifically from the lens of testing) And Quality Engineers become those who do the building the frameworks that dev teams can use and help drive the technical capabilities of testing.
but what I’ve learned is that I have a lot to learn and need to think about the dynamic more.
Quality Engineering is absolutely the evolution of the software testing role, but it’s more than just a title change. In my experience, true Quality Engineering starts when you’re involved from the very beginning, whether it’s reviewing PRs, sitting in on user experience testing/calls, or contributing to product strategy discussions.
Quality isn’t just a phase in the development cycle; it’s a mindset. It’s about embedding quality into every step of the process, from ideation to delivery. That’s what I teach my teams to bake quality into the process itself, not treat it as an afterthought.
But let’s be real: while quality is everyone’s responsibility, we in Quality are still the ones keeping an eye on the big picture. We’re like the Guardians of the Galaxy of the software world, protecting users from poor experiences and ensuring products live up to their potential. It’s a collaborative, evolving role, but at its core, it’s about being that trusted safeguard of both the process and the end result.
(Good) Testing is testing, no matter what and whatever QE will be. It’s a tough, demanding job and not replaceable by computers.
When you go from testing to e.g. development you don’t evolve, you transit.
And I guess developers will be able to do QE as well. It’s not exclusive to testers.
While there is plenty of value in software testers I do feel the quality engineering role is an evolutionary step. There are plenty of software testers (role) who are doing the work of quality engineers without the job title or I suspect the salary. The job title is an evolution of recognition and reward as much as skill range and development in my opinion.
I think that’s a fair statement. A lot of quality engineering encompasses, or originates from, the testing role. Whether you call it an evolution, an extension, or something else, I definitely see a relationship.
That being said, the testing role without the quality engineering part is still very important, and this shouldn’t be taken to mean otherwise. Also, I don’t think we should be restricted by job titles or descriptions. If one wants to go above and beyond their official testing role, into quality engineering, I say go for it. Equally, if someone has the official title of developer or business analyst, there’s no reason why they can’t also take part in quality engineering.
Great to see how your thinking has changed. Thanks for sharing, @sharmon.
As I voted “Something else, please comment” here’s my comment:
The phrase “an evolution of the software testing role” doesn’t quite sit right with me. Mostly because of the word evolution. In biological terms I’d see Quality Engineering more as a hybridization combining aspects of Software Testing and a few other rolls (some more analytical, some more technical) than as an evolution.
Still there is an expect of evolution in there. New jobs/roles tend to have more of these ‘non-traditional’ aspects in them than Software Testing roles used to. Arguably our ‘ecological niche’ in the world of jobs & roles is shifting or expanding in that direction.
As a result of which I found myself without an ‘I agree’ or ‘I disagree’ option and writing this comment 
It seems more like a rebranding exercise to me. One reason for this is probably to change the perception of testers and the testing field, especially in the eyes of Software engineers. Look ! Its (quality) Engineering just like your field and not testing/QA etc. Look ! We are QEs and not button clicking + script generating QAs or Testers whose value is often questioned by Engineering managers and Software engineers.
I have seen a similar thing with the (mostly) manual tester role. Few companies call it manual tester and more call it “Quality Analyst”. Such roles are either fully manual (even though the job ad and hiring manager promise that you might be allowed to do automation) or a stepping stone to some automation work.
Unfortunately you highlight some of the issues here with this statement “Such roles are either fully manual (even though the job ad and hiring manager promise that you might be allowed to do automation) or a stepping stone to some automation work.”
A hands on tester is all about active real time critical thinking and analysis during risk detection design and investigation. Yet this statement has somehow managed to present that as lessor in some way than doing automation?
That misunderstanding is one of the exact reasons for rebranding as you suggest, yet we propagate that exact same misunderstanding to try and elevate the view of a new title, this is a never ending loop unless the understandings are improved.
The testing role where its the discovery, learning and investigation of risk in many cases should never have needed the rebranding, in fact the rebranding really harmed the testing brand on this front.
QE is a different role form both an automation engineer and a discovery focused tester. The risk with the ongoing evolution is that the understanding of testing value also diminishes further.