[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 