I think itās a good name for modern testing.
Current testing trends require quite a bit of engineering work, and āassuranceā in QA was always vague and often misinterpreted.
As a hiring manager and coach of Quality Engineers (QEās) I need to see the candidates understand that within Quality Engineering, testing is about the information, risks and questions you uncover and the quality comes from doing something about it.
I look for knowledge and experience of a proactive, data-driven approach that goes beyond ātraditionalā testing when needed. That they can focus and have experience on building quality into the software development lifecycle (SDLC) from the very beginning. This involves coaching or collaborating closely with developers, product owners, and other stakeholders to understand user needs, define quality attributes, and implement strategies to prevent defects rather than just finding them later. They become strategic partners, using their expertise to guide development decisions, improve processes, and empower the delivery of high-quality software that meets user expectations and business objectives. They know when to work alone and get stuff done or collaborate within or across teams experience dependent.
Yes in 2025+ QEāS can be expected to leverage technologies like AI and machine learning to automate repetitive tasks, analyse vast amounts of data, and predict potential issues (shifting right) But I also need to see they acknowledge that AI/ML is just one tool in our vast tool box and the not the ābig ticketā being looked for as a skill. There is more to our craft than AI.
Something else: not yet!
The software teams where I work arenāt all that used to testers yet. I spend the first year on my team getting them used to and appreciative of testers. Now iām growing my role in the team, working towards a quality engineer role.
My job title is quality lead but it is more a quality coach role. There are no tester roles as the developers do all of the testing. My role is to help teams throughout the SDLC think about quality so that they produce high quality features.
I struggle with āQuality Engineerā as a job title as to me an engineer is a technical person and not all quality engineers are technical. But thatās just my biasās impacting my thinking
Thereās lots of way to be technical without writing code. Sometimes we think of technical skills as limited to the ones we tend to associate with developers, but thereās a whole bunch of testing technical skills we can show. Iāve been happy with the term Quality Engineer, even as someone who doesnāt code, because of the other technical skills I bring to the table
I wonder, is the term so broadly used that anyone who does a bit more than testing or automation considers themselves as a āQuality Engineerā?
Or is testing/automation in testing not required anymore so we reinvent our roles and try to add any type of value we can to a team or product.
Also something to think about is the difference between Quality Engineering and Engineering Quality which might or might not mean the same (GitLab example):
For me, it really depends on my audience. My favorite title is āRisk Assessmentā though this really doesnāt exist in the industry outside of Viktor Slavchevās talk āāWorstā Practices of Software Testingā.
If Iām talking with my mom or someone not in tech, Iāll specifically say that Iām in Quality Assurance because most people would have an idea of what I do, without too much context. Speaking to those in the industry, I say QA Engineer because that is my actual title. But, I really love the simple title āTesterā. I think no matter what title you have there will be misperceptions about it. You canāt avoid that. But, finding a title the makes sense to the people around me is good enough for me.
Iām good with being referred to as software tester instead of quality engineer or quality analyst because that depicts the true nature of my job which is testing the software either through functional or automation or API testing. Obviously, there are many other tasks that I do as a part of my job but something that is primary and will always be the most important thing in my job is testing the s/w.
Earlier I used to mention myself as a quality analyst but as time passed I realized that it would be better with the title āSoftware Testerā, also I came across James Bachās article in which he focused on preferring āSoftware Testerā over āQAāsā so that article also has somewhere impacted my thoughts, especially for the job title.
As I still donāt really get what QE should be, especial its claimed superiority I perceive by others, Iām not sure if I would fall into that category.
Do I wear multiple hats in my job, do stuff which is not directly tied to my role? Yes.
Do I consider myself mainly being a tester? Yes.
I like this brief description, as itās how Iāve seen this as well but didnāt have the words for it.
Iād like to add to this quote: ābuilding quality into the software development lifecycle (SDLC) from the very beginning.ā ā even before the SDLC and after something is already live/in production (PDLC)
One can use logs, analytics, databases, interviews, support tickets, queries/questions of clients, and other similar information to keep trying to find ways to improve the product.