Why Your Transition to Quality Engineering May Fail

Why do some teams begin their Quality Engineering journey with enthusiasm - yet struggle to make the transition truly work?

The hidden pitfalls most teams miss

Quality Engineering (QE) has become one of the central themes in the wave of transformation sweeping through the software engineering industry, particularly within the testing and quality landscape.

So far this year, these two topics: Quality Engineering and Transformation have occupied my attention more than anything else, both conceptually and practically. They are areas I’ve become deeply and intrinsically interested in, and what a journey it has been engaging with them.

My preoccupation with these topics has come from different directions, but what has shaped my thinking the most are the conversations I’ve had about them with practitioners and teams. Those discussions have prompted me to deeply reflect on how the transition to QE is playing out in real environments – not just in models, frameworks, or mandates.

I’ve been especially interested in understanding some patterns I’ve seen emerging. Renaming roles without system redesign, automating without alignment, collaborating without a shared vision, measuring without learning, sharing quality ownership without empowerment, and pushing for improvement without prioritisation. These observations have got me to particularly wonder:

Why do some teams succeed in their transition to QE? And why do others struggle?
What enables success? And what does it take to make the transition effective and sustainable?

In this two-part article series, I’ll be sharing my reflections and insights on this topic: transitioning to Quality Engineering. In part 1, I focus on why QE transition tend to fail in some contexts. In part 2, I will explore what practitioners can do to avoid, address, or reverse the failure patterns discussed here.

Quality Engineering is not really a new trend. It is a modern articulation of principles that have guided quality transformations for decades.
Product Quality Insights

Quality engineering isn’t new – but our mistakes might be

Across the software industry, teams are “moving to Quality Engineering” with the hope of delivering value faster, safer, more reliably, and more consistently. Testers are becoming Quality Engineers. Automation efforts are accelerating. Delivery pipelines are growing more sophisticated. AI‑assisted workflows and agents are becoming increasingly popular.

Meanwhile, leaders talk about shifting‑left, continuous testing, shared ownership of quality, and the need for testers and quality professionals to re-invent their skills.

All of this sounds promising – and in many ways, it is.
Yet, despite the energy behind these transitions, many quietly stall long before anyone is willing to acknowledge it. Teams adopt the language of Quality Engineering, but delivery doesn’t noticeably improve. Collaboration remains siloed. Automation becomes a bottleneck or too costly to maintain. Quality Engineers find themselves stretched between old expectations and new ones. Frustration grows, often rooted in unclear responsibilities, even when everyone agrees that QE is “the right direction.” The issue, however, is rarely Quality Engineering itself.

More often, the problem lies in how QE is interpreted, implemented, or approached. Moreover, in the missed opportunity to apply well‑established change management principles when teams begin their transition.

Because here’s the truth: Quality Engineering is not a brand‑new philosophy.
It is an evolution of long‑standing quality movements, such as Total Quality Management (TQM), Lean thinking, Six Sigma, and Systems thinking – adapted for the realities of modern software systems and developments. These frameworks transformed manufacturing and service industries by embedding quality into every part of how value is delivered: systems, culture, leadership, and decision‑making. Their success was driven not only by the strength of the philosophy itself, but by the disciplined application of structured change management principles that enabled organisations to implement them effectively and sustainably.

What often fails in software organisations is not the ambition to improve quality, it is the neglect of the change management principles that make such transformations succeed in the first place. Poor quality frequently emerges from poorly designed or poorly executed processes and strategies. With the right systems and structures in place – the ones that intentionally help build quality into your product – the transition to QE has a far higher chance of succeeding.

In a nutshell, Quality Engineering fails when teams adopt new practices but ignore the systemic, cultural, and leadership foundations that made earlier quality related movements effective.

And that is where our mistakes often begin.

Quality Engineering is built on proven quality thinking

Long before CI/CD pipelines, automated tests, or AI‑assisted workflows, leaders in manufacturing and service industries were solving similar quality challenges at scale. Through various management philosophies, they championed the idea that “everyone in an organisation is responsible for continuously improving customer satisfaction”. Their focus was on planned improvement: a continuous cycle of feedback, refinement, and optimisation to deliver the best possible products and services.

One of the most influential movements in this regard was Total Quality Management (TQM). Originating in Japan and popularised by scholars such as W. Edwards Deming, TQM emphasised that “quality is everyone’s responsibility“, not a single department’s function. It promoted a culture where people actively look for ways to improve both process and product – what many of us today refer to as a “culture of quality“. TQM’s primary focus was on external customer satisfaction, continuous improvement, consistent clarity for internal staff, and visible leadership commitment to quality outcomes.

Although TQM drove extraordinary improvements in product and service quality, it was later complemented, and in some organisations, superseded, by other approaches. For example, Six Sigma institutionalised data‑driven decision‑making and disciplined root cause analysis to reduce defects and variation in products and services. Lean thinking emphasised flow, waste reduction, and optimisation of the entire end‑to‑end system rather than isolated local efficiency. Meanwhile, Systems thinking provided a holistic problem‑solving lens: understanding patterns, structures, and interconnections within complex systems instead of analysing components in isolation.These quality movements allowed organisations to manage end-to-end quality processes, discover root causes, identify failure points, and influence system‑level behaviour more effectively.

Modern Quality Engineering extends these established principles into a software development context by emphasising that:

Automation supports consistency and accelerates feedback.
Continuous Integration enables rapid detection of issues.
Observability improves learning from production environments.
Cross‑functional collaboration reduces handoffs and knowledge gaps.
Shared ownership enhances accountability and better outcomes.

The technologies, terminologies, and contexts in which the earlier referred quality philosophies now operate have changed dramatically, but their core principles remain the same: quality is built through a continuous cycle of improvements and feedback – across disciplines and throughout the entire development process – that provides the best possible products and services to end-users.

Organisations that understand the roots of quality thinking: those that recognise that the transition to QE requires more than a title change or a shift only within the QA or testing team, tend to have the highest chance of success.

Quality Engineering, at its core, is a cultural and delivery transformation. It reshapes how teams collaborate, make decisions, respond to failure, and deliver value to users.

As as a result, the transition to QE must be intentionally planned, clearly communicated, and consistently supported by leadership, just like any other change or transformation program. When organisations implement Quality Engineering merely as a tooling initiative, a trend‑driven move, or a statement of intent, rather than as a systemic transformation, they disconnect it from its foundations and the philosophy that gives it strength. And that is where failure begins.

Where Quality Engineering transitions often fail

Quality Engineering transitions often fail when they are poorly interpreted, weakly communicated, or inconsistently executed. In this section, I’ll outline some of my observations on where QE transitions often fail or breakdown, perhaps, why yours might, too, if not managed intentionally.

Renaming roles without redesigning the system

One of the most common missteps I see in QE transitions is cosmetic transformation.
This is where organisations embrace the idea of Quality Engineering, but fail to put in place the structural building blocks required to make it work.

Testers are renamed “Quality Engineers.”
Teams are told to “start practicing QE.”
Job descriptions get updated.
Expectations expand, to include automation and shift-left.

And yet, the surrounding system remains unchanged.

Developers still write code first and involve testers later, because that’s what they’ve always done.
Product discovery and architectural decisions happen without input from Testers or Quality Engineers.
Delivery pressure still prioritises speed over resilience.
Quality Engineers become automation support specialists rather than system influencers.

Quality talk replaces quality thinking, and testing as a craft or function becomes unfairly demonised – a topic for another day.

The missing ingredient here is: system‑level change.
Quality Engineering cannot succeed if only titles change while incentives, workflows, and accountability stay the same. This brew confusion in teams, and potential disengagement QE as a change programme.

Some early warning signs may include:

Quality Engineers becomes overloaded with automation backlog
Minimal involvement of engineers in design or discovery conversations
Persistent late‑stage defect discovery due to reduced focus on testing

When teams start noticing these signs, it usually indicates that something is misaligned within the structure or system they operate in. If the environment around the QE programme isn’t set up to support it, the transition is already on a path toward failure.

Automating without alignment

Another failure mode is automation enthusiasm without strategic intent and alignment with business goals.

Teams invest heavily in UI test suites.
Coverage metrics increase.
Pipelines get longer.
Maintenance overhead skyrockets.
Builds become brittle.

Instead of accelerating delivery, automation becomes the problem everyone is constantly discussing, fixing, or re-allocating resources to – simply because, no one wants the investment to be wasted. Not because it serves the business goals.

The neglected principle here is: purpose-driven planning. In TQM and Six Sigma, improvement is tied to clear business goals and systemic analysis. Yet, in many QE transitions, automation is pursued because it feels modern – not because it solves a defined problem. An effective Quality Engineering grounded in proven quality thinking would ask:

What risks are we reducing?
Where is feedback most valuable?
Which defects are most costly, and at which test level?

When these questions go unanswered, automation quickly becomes an activity without impact. Stakeholders and teams start to lose faith in the investment, and over time it becomes a perpetual, low‑credibility initiative that shows little evidence of supporting the QE programme. This erosion of trust creates the conditions for a brittle and unsustainable QE transition.

Collaborating without a shared vision

In many organisations, the word quality means different things depending on who you ask:

To Product: speed and feature delivery
To Engineering: clean code and architectural integrity
To Operations: uptime and low incident counts
To Users: reliability, usability, and ease of use

I’ve written before that quality is perception – and without aligning those perceptions, teams optimise in different directions:

Product prioritises time to market
Developers chase velocity
QA and testers seeks coverage
Operations seek stability

All while assuming they’re serving the same organisational and business goals. The missing principle here is: vision. Successful quality transformations begin with a clarity of purpose. A purpose driven QE transition would often begin with a desire to answer questions such as:

What does quality mean for our customers, and how will we measure it?
What does “building quality in” mean for our context?
What principles will guide us?
How might we structure and organise to realise our vision?

Without a shared vision, QE transitions inevitably become fragmented. Each team or stakeholder begins to launch their own mini‑initiatives based on their individual understanding of what QE should be. These efforts may frequently contradict or diverge from one another, leading to a fractured QE environment where collaboration is performed in theory – but delivers little meaningful value in practice.

Measuring without learning

When teams begin transitioning to QE, focus can placed on data gathering, not least because, we now live in a data-driven world. Thus, dashboards multiply for tracking different types of data:

Automation metrics
Test coverage
Pipeline duration
Release incidents counts
Adherence to shift‑left practices etc.

Yet incident patterns repeat. Issues reoccur. And no meaningful action is taken, except in some cases to identify poor performance or who is to blame for an observed issue. The neglected principle here is: learning‑oriented data use. In TQM and Six Sigma, metrics are used to identify systemic weaknesses and eliminate root causes – not to assign blame or create reporting ceremonies. When metrics are applied without context – or used, even unintentionally, to judge individual performance – teams become defensive, issues are concealed, and psychological safety deteriorates. These conditions undermine the very foundations QE relies on.

Quality Engineering can only flourish in environments built on openness and trust. Metrics should serve as tools for learning and improvement, not instruments of fear or punishment.

Sharing quality ownership without empowerment

In many QE transitions, expectations for quality professionals expand – but their authority does not. Quality engineers are expected to engage early and often with stakeholders – but their scope of influence is not clearly defined. They are asked to:

Influence product decisions, yet not invited to design reviews.
Improve reliability, but not given time or access to do so.
Automate more, but not provided the capacity needed.
Reduce defects, but cannot influence release decisions.
Share ownership of outcomes, but cannot influence actions.

The core principle of quality management violated here is: ownership and responsibility must be paired with empowerment. TQM for example, placed significant emphasis on empowering internal customers – the people doing the work – by giving them the authority, resources, and support required to influence quality early and throughout the development process.

When quality professionals are excluded from early decision‑making or left without meaningful leadership support, QE practices remain aspirational rather than operational. And when QE cannot become operational, the transformation loses both momentum and credibility.

Pushing for improvement without prioritisation

Some teams add more QE ceremonies, metrics, checkpoints, and root cause analysis sessions as models for continuous improvement – but change nothing about the prioritisation of identified improvement actions.

Retrospectives highlight repeat issues
Root cause analysis identifies contributing factors
Improvement tickets are logged

And then those items sit in the backlog, indefinitely. Because new feature delivery always “wins.” Or, because it is unclear who should own those outcomes. When identified improvements lacks priority, QE practices becomes a ritual – not a progressive movement that can shape quality outcomes. This can happen, because some teams begin their QE journey without asking the fundamental question: What does good look like? And how will we measure success?

The core principle violated here is: continuous improvement must be deliberate, prioritised, and system focused. Not reactive, ceremonial, or optional. True Quality Engineering inspired by the old-age quality principles, institutionalises learning loops. It helps:

Identify root causes
Implement systemic changes
Verify reduction in recurrence
And encourages continuous improvement as a development practice

Without clear, goal‑driven improvement mechanisms, QE quickly loses credibility. And teams may lose belief in its potential to create meaningful and lasting change.

Final thoughts: Hope isn’t lost …

Quality Engineering does not fail because teams lack capability or commitment. It fails because they attempt the transformation without redesigning the system that produces their current outcomes. Renaming roles, expanding automation, or introducing new metrics cannot compensate for unclear vision, misaligned incentives, weak governance, or superficial improvement habits.

The warning signs are rarely dramatic at first. They show up as friction, fatigue, recurring issues or defects, conversations with no resolutions, and quiet skepticism, even by a portion of those who should lead or are assigned agents of the change.

If these patterns are familiar, the issue is not your ambition to improve quality. It is that meaningful change requires more than new practices or mandates; it requires deliberate structural and cultural change design.

The desire to transition to Quality Engineering is a noble and justified cause. Some teams may face challenges in the transformation, but hope isn’t lost. There are steps we can take to avoid some of the pitfalls of poor QE implementation discussed above. In part 2 of this series, we will explore how to build those foundations and turn Quality Engineering from a fragile initiative into a sustainable system of software product delivery excellence.