Shifting from Quality Assurance to Quality Engineering
Shifting from Quality Assurance to Quality Engineering
There’s a reason that I write about Quality Engineering here at QUALITY BOSS. While I often refer to software testing, I rarely use the term Quality Assurance—this is intentional. If you’ve been wondering why, it’s because my experiences have shown that the language we use shapes how we work and perceive our roles.
In my last job, there was an ongoing debate about terminology—outside our team, we were often referred to as QA, while we preferred to be known as QE. Why? Because we recognized that our value came from enabling quality throughout the process, not just assuring it at the end. Let me explain why this shift in terminology—and mindset—matters.
Let’s start with some definitions.
Software Testing is straightforward: it includes any activity aimed at validating whether software or a specific feature works as intended. This could involve manual, automated, exploratory, or ad hoc testing, UAT, etc. Testing isn’t limited to testers; developers (through TDD, unit tests, etc.), product managers, project managers, and even CEOs can participate. In some cases, users are considered testers, particularly when they’re the first to navigate a particular pathway in the code.
Quality Assurance comes from a manufacturing background and is often interchangeable with Quality Control. Over time, QA has come to represent Software Testing and its associated roles. The key difference between the two is that QA usually refers to a specific role or phase, whereas testing refers to an activity anyone can do.
As a role, QA is typically a distinct and separate role from developer roles, often on a different team.
It might also refer to an individual stage in the SDLC, such as
development→QA→release.In this situation, QA is done at the end of a release cycle and can be seen as a gatekeeper or bottleneck activity.
A slight reframe on Quality Assurance brings us to Quality Assistance. This involves shifting testing left, enabling more collaboration between testers and developers and a more holistic view of quality and testing.
Quality Engineering serves as an umbrella term, encompassing the entire company’s culture and attitude toward quality and testing, including processes, best practices, metrics, and KPIs. QE is about enabling quality from start to finish rather than assuring quality at the end.
Why Terminology Matters
The terms we use define roles, shape perceptions, and influence how work is structured and executed. Let’s examine a few critical ways terminology can impact a company’s approach to quality.
1. Limiting Quality Activities and Scope
Quality activities can become siloed when an organization is structured with QA as a separate team. This setup might unintentionally limit the scope of quality efforts by suggesting that quality is the responsibility of a specific team rather than a shared responsibility across the entire organization. This separation can also create bottlenecks, as the QA team becomes the gatekeeper rather than an enabler of quality.
2. Influencing Company Culture
Terminology directly influences company culture. When we talk about Quality Assurance, it can imply a reactive approach—ensuring quality only after the fact. On the other hand, Quality Engineering suggests a more proactive stance, where quality is built into every stage of the development process. Shifting from QA to QE encourages a culture where everyone—developers, testers, product managers—is responsible for quality. This shift fosters collaboration, continuous improvement, and a more holistic approach to product development.
3. Where Do Unit Tests, Linters, and Other Practices Fall?
Practices like unit tests and static code analysis often fall outside the traditional scope of QA. These are seen as the developer’s responsibility and can create yet another silo. However, under a Quality Engineering framework, these practices are integral to ensuring quality from the ground up. They represent the shift left in testing, where quality checks are embedded throughout the development cycle, from writing the first line of code to deploying the final product.
By shifting terminology—and mindset—from QA to QE, we aren’t just playing with words; we’re redefining what it means to build quality software. This shift reflects a deeper commitment to excellence, where quality isn’t an afterthought but an integral part of the entire development process. It’s about moving from gatekeepers to enablers of quality, fostering a culture where everyone is responsible for delivering the best possible product. This evolution in terminology not only improves product quality but also aligns the entire organization around a shared vision of excellence—a vision that starts with how we define our roles and ends with the software we deliver.
Like this article? Click the ♥️ button or leave a comment 💬.
xo,
Brie
PS. If you’d like to support my writing and my work on QUALITY BOSS, you can show appreciation by leaving me a tip through Ko-fi.
Coaching/Mentoring: Interested in working with me? Book a call here to get started.
My areas of expertise and interest are leadership development, conquering impostor syndrome, values exploration, goal setting, and creating habits & systems. And, of course, Quality Engineering. 🐞
