Clearing the Fog Around the Quality Engineering Term

What is Quality Engineering?

I kept reading articles on the subject to find a better definition of Quality Engineering. I hit on a post comparing Quality Assurance (QA) with QE. In that post, the author states the following about Quality Engineering:

• Enhances product quality through a combination of processes, tools, and engineering practices.
• Often integrated within the development team, with engineers taking responsibility for quality throughout the SDLC.
• Developing and maintaining automated testing, continuous integration, and continuous delivery pipelines.
• Broadens its scope to include the entire development process, emphasizing early defect prevention.
• QE activities start from the project’s inception and continue throughout the development lifecycle.
• Constant, real-time feedback is provided to developers to identify and fix issues as they arise.
• Utilizes automation tools, DevOps practices, and CI/CD pipelines for testing and deployment.
• To proactively build quality into the product and minimize defects early on.
• Requires strong technical and automation skills, software development expertise, and a focus on preventive measures.

The so-called expert presents this as clearly different from QA. If you are well versed in QA, you will say, “Are not most of those bullets part of QA?” The answer is yes; they are already in QA. So, what is going on here? Is there something different?

Is there something unique about Quality Engineering?

To be fair and not make too much fun of this “testing expert,” let’s say some things in this list are new and were not part of QA. What are those?

Here are the ones that you might make a case are unique:

• Developing and maintaining automated testing, continuous integration, and continuous delivery pipelines.
• Utilizes automation tools, DevOps practices, and CI/CD pipelines for testing and deployment.

• Requires strong technical and automation skills, software development expertise, and a focus on preventive measures.

Most of these are new because they come from agile software development practices. Still, I worked with many Agile teams using CI/CD pipelines and writing test automation scripts, and we never had someone with the title of Quality Engineer. We did have people with the title of Automation Engineer or QA Engineer covering many of these items. Granted, the Ops guys usually handled the CI/CD pipelines, who now go by the title of DevOps Engineers.

So, who is working with the CI/CD pipelines? The DevOps Engineer? The Quality Engineer? Both? Who knows. These three bullets say that if you want to be a Quality Engineer, you must be able to write code.

Do you need a Quality Engineer?

So, why does the author say QE is so different from QA? The answer starts with a simple truth: the clueless author needs to learn what Quality Assurance means. The author mostly confuses QA with Quality Control (QC).

Let’s start with the definition of Software Quality Assurance (SQA). The following is from Louise Tamres's book, Introducing Software Testing: SQA ensures that we use the right tools, procedures, and techniques for developing products all with the goal of producing high quality software by preventing defects or by detecting and removing them early. Lousie goes further and makes the following statement: Some companies mistakenly equate SQA with software testing. SQA evaluates process quality with primary focus on defect prevention, as opposed to software testing, which evaluates product quality by focusing on error detection.

Most of what this “testing expert” claims is quality engineering (QE) was already part of quality assurance (QA). In fairness to the blog post's author, they probably based their definition of quality assurance on their experience working with QA teams. As I mentioned, many QA team members do not want to do QA; they just want to do QC. They do not want to be in the room early in the product development process. If that is your experience with QA teams, then you might think that is the definition of the QA role.

The sad part is that most Agile thought leaders have spent years trying to eliminate QA as a title and now have renamed it QE. They have realized that while the team must be responsible for quality, someone always cares more about it.

What causes this confusion?

There are many reasons for the poor quality of content in software testing and quality assurance. As mentioned, many QA team members behave just as QC. Another is the need for a solid academic foundation. It is rare to find universities that provide software testing classes and even fewer software testing programs. You will think that computer science will include a specialization in software testing or quality assurance. It does not.

The closer you look at Quality Engineering definitions, the closer you conclude that it is just SQA with coding skills. There is nothing wrong with having someone with those skills or even the title. But please do not sell it like it is something new that did not exist before.

Do you really need a Quality Engineer?

I do not know if you need a quality engineer. You do need someone who cares deeply about quality. At Testaify, we call such people system thinkers. They see the whole system and understand what the users are trying to achieve with it. They also know how to test well and can help everyone think of scenarios no one else thinks about. They can look at the data from the product development process and quickly tell you if a bad release is coming out of the pipeline. They always want to shift left and be present at every step of the development process.

Do they need to be able to code to perform that job? Not really. It would be nice if they could code, but it is not a prerequisite to successfully helping teams deliver a high-quality product. If you want to give that person the title of Quality Engineer, go ahead. It is your choice.