Beyond the Checklist: I Spent 10 Years as a QA Firefighter. Here’s How I Became a Quality Architect.

Introduction: The Day the Fires Won

I remember the smell of stale coffee and the low, persistent hum of the server room.

For six weeks, that had been my world.

As the Quality Assurance (QA) Manager for our company’s most ambitious software launch to date, my team and I weren’t just working; we were fighting fires.

Our bug-tracking system, Jira, wasn’t a project management tool anymore; it was a triage ward in a hospital overwhelmed with casualties.

Every morning, our daily stand-up meeting felt less like a collaborative check-in and more like a grim roll call, prioritizing which infernos to tackle first.¹

The cycle was maddeningly predictable.

A developer, already stretched thin, would mark a bug as “fixed.” We’d pull the new build into our test environment and begin the painstaking process of regression testing, checking to see if the fix had broken anything else.

More often than not, it had.

I’d document the new bugs, attach the screenshots, and send the ticket back, only to receive it again 48 hours later with a different set of freshly introduced issues.

It was a demoralizing game of digital whack-a-mole, a “ping-pong effect” that consumed our days and nights.²

My team was heroic.

They were meticulous, dedicated, and running on fumes.

We followed all the industry “best practices.” We had comprehensive test plans, detailed test cases, and we were executing them with relentless precision.

On paper, we were doing our jobs perfectly.

Then came launch day.

The final build passed our last, frantic round of regression tests.

We gave our exhausted sign-off.

The product went live.

And it was a catastrophe.

The market reaction was swift and brutal.

The software was sluggish, unstable, and riddled with usability issues that our siloed testing could never capture.

Customers were furious.

The financial fallout was significant, but the damage to our brand’s reputation was even worse.³

In the all-hands meeting that followed, the data was laid bare, and the unspoken blame hung heavy in the air, aimed squarely at my team.

We were the “quality” department, after all.

I felt a profound sense of failure, not just professionally, but personally.

We had worked harder than ever before, poured everything we had into that launch, and the result was a low-quality product that betrayed our customers’ trust.

The experience shattered my understanding of my own role.

It forced me to confront a terrifying question: If my team could follow all the rules, exert maximum effort, and still fail so spectacularly, was the problem with us, or with the very definition of our job? Was “Quality Assurance” just a fancy title for a team of well-intentioned arson investigators, arriving at the scene only after the building had already been designed to burn?

---

Part I: The World of the Quality Firefighter

To understand how we arrived at that disaster, you first have to understand the world my team and I inhabited—the world of the Quality Firefighter.

It’s a world built on a fundamental, and often tragic, misunderstanding of what quality truly Is.

Defining the Battlefield: QA vs. QC

In the formal lexicon of quality management, there’s a crucial distinction between Quality Assurance (QA) and Quality Control (QC).

According to the American Society for Quality (ASQ), QA is defined as the set of “planned and systematic activities implemented within the quality system that can be demonstrated to provide confidence that a product or service will fulfill requirements for quality.” It is meant to be a proactive, process-oriented discipline focused on preventing defects.

QC, on the other hand, is defined as “the operational techniques and activities used to fulfill requirements for quality.” It is a reactive, product-oriented discipline focused on detecting defects.⁴

The problem is that in the real world of software development, these two concepts are almost always conflated.⁴

My title was “Quality Assurance Manager,” but my daily reality, and that of countless others in the field, was pure Quality Control.

We weren’t assuring quality was built into the process; we were inspecting the finished product to see if quality was there.

We were the final checkpoint, the last line of defense.

We were firefighters, paid to spot smoke, not to design fireproof buildings.

A Day in the Life of a Firefighter

A typical day for my team began not with strategic planning, but with damage assessment.

The first thirty minutes were a frantic scan of emails and bug trackers to see what new emergencies had erupted overnight.¹

The daily scrum meeting was an exercise in crisis management, where we’d triage the bug list and decide which fires were most threatening to the project timeline.¹

The bulk of our day was consumed by two core activities:

1. Testing new features: A developer would hand off a “completed” feature, and we would begin the arduous process of manual and exploratory testing, comparing it against specifications and hunting for deviations.
2. Regression testing: This was the most soul-crushing part of the job. After a bug fix was deployed, we had to re-test not just the fix itself, but all adjacent functionalities to ensure the “solution” hadn’t created a cascade of new problems.¹

The work was characterized by relentless context-switching and the meticulous documentation of failure.⁵

We were judged not by the quality we helped create, but by the number of defects we Found. Our primary output was a Non-Conformance Report (NCR), a detailed chronicle of everything that was wrong.⁵

The Inherent Frustrations of the Role

This model of “quality” is structurally designed for conflict and burnout.

It creates a system rife with frustrations that anyone in a traditional QA role will find painfully familiar.

First, there is the adversarial dynamic.

The very nature of the job sets QA against the development team.

In many organizations, developers are incentivized by the speed and volume of features they ship, while QA is incentivized by the number of bugs they find.

This creates a zero-sum game.

As multiple QA professionals on forums like Reddit have lamented, finding a bug is often perceived not as a collective win for the product, but as a personal attack on the developer who wrote the code.⁶

I lost count of the number of times a developer became defensive or even hostile when I “failed their ticket,” as if I were the one responsible for the flaw, not the one who discovered it.⁶

This dynamic is exacerbated when developers, under pressure, submit half-finished work with “zero error handling” or features that don’t match the design, expecting QA to catch their mistakes for them.⁶

Second, there is the bottleneck problem.

Because QA is positioned as the final gate before release, any delay is immediately attributed to them.

Project managers, focused on deadlines, often view the QA process as an obstacle to be overcome rather than a value-adding activity.⁷

This leads to immense pressure to “test faster” or to sign off on builds that are not ready, making the QA team the scapegoat for systemic scheduling and development problems.⁶

Finally, the entire model is propped up by a host of systemic failures.

The process is often doomed from the start due to weak or nonexistent test planning, the use of unrealistic test data, and a tendency to ignore critical non-functional testing like performance, scalability, and security until it’s too late.⁸

In many environments, especially those without clear, objective standards, QA evaluations can be highly subjective, leading to inconsistent scoring and eroding trust between agents and supervisors.¹⁰

The tragedy of the Quality Firefighter is that they are a necessary component of a deeply flawed system.

They are rewarded for finding failures, which implicitly punishes developers for creating them, and does absolutely nothing to fix the underlying process that guarantees more failures are on the Way. It is a system that optimizes for detection, not prevention, and in doing so, it burns out its best people and produces mediocre products.

---

Part II: The Epiphany: You Can’t Inspect Quality Into a Product

In the aftermath of our failed launch, I was adrift.

I scheduled a meeting with a mentor, a senior executive named Eleanor who had spent the first decade of her career in the automotive industry during the 1980s.

I laid out the whole sorry tale: the heroic effort, the endless bug lists, the adversarial meetings, the catastrophic failure.

I expected sympathy, or perhaps a lecture on better testing methodologies.

Instead, she smiled.

“You’re trying to inspect quality into your software,” she said, her voice gentle but firm.

“It doesn’t work.

We learned that the hard way from a man named Deming.

You can’t test a car at the end of the assembly line and suddenly make it a well-built machine.

The quality is either in it or it isn’t.”

That moment was the single most important epiphany of my professional life.

She had just articulated the core truth articulated by the legendary statistician and management consultant W.

Edwards Deming: “Inspection is too late.

The quality, good or bad, is already in the product”.¹¹

Inspection doesn’t

create quality; it only reveals its absence.¹³

My entire career had been dedicated to becoming the best possible inspector, but I was standing at the wrong end of the process.

Introducing the New Paradigm: Architect vs. Firefighter

Eleanor went on to introduce an analogy that would fundamentally reshape my worldview.

“Right now,” she explained, “you see your role as a Quality Firefighter.

You’re a hero.

You rush into burning buildings after the alarm has sounded.

Your job is to contain the damage and find the cause.

Your tools are bug trackers and regression test suites.

And your success is measured by how many fires you put O.T.”

“But there’s another role,” she continued, “and it’s the one you need to become.

It’s the role of the Quality Architect.

An architect doesn’t wait for the fire alarm.

They design the building from the very beginning to be fire-resistant.

They choose the right materials, design safe electrical systems, and create clear evacuation routes.

Their job is to prevent fires from ever starting.

Their tools are process design, systems thinking, and collaboration.

And their success is measured by the beautiful, safe, functional building—by the absence of fires.”

This was the paradigm shift.

The journey from firefighter to architect was the journey from reactive QC to true, proactive QA.

It was the evolution from being a tester to being a Quality Engineer, and from managing a team to fostering a culture of Total Quality Management.⁴

The Blueprint for Architecture

Eleanor handed me a well-worn copy of Deming’s seminal book, Out of the Crisis.

“This isn’t a software book,” she said, “but everything you need to know is in here.

This is the blueprint for becoming an architect.” The key, she explained, was not a set of tools or a new methodology, but a new way of thinking, which Deming called the “System of Profound Knowledge.”

This shift in mindset from a reactive firefighter to a proactive architect represents a fundamental change in how quality is perceived and pursued within an organization.

The following table crystallizes this transformation, highlighting the differences in focus, timing, and philosophy that define this new, more effective approach to building exceptional products.

Dimension	Firefighter (Reactive QA/QC)	Architect (Proactive QE/TQM)
Core Philosophy	“Quality is the QA team’s job.”	“Quality is everyone’s responsibility.” 17
Focus	Defect Detection 4	Defect Prevention 14
Timing	End of the development cycle 14	Throughout the entire lifecycle 15
Primary Activities	Manual testing, bug reporting, regression checks 1	Process design, automation, collaboration, mentoring 19
Key Metric	Bugs found, tickets closed	Business outcomes, customer satisfaction, process health 20
Team Dynamic	Often adversarial or siloed from development 6	Collaborative and embedded within development teams 20

The most challenging part of this transformation is that an architect’s greatest successes are invisible—they are the crises that never happened, the fires that never started.

This requires educating an entire organization to value the quiet stability of a well-designed system over the noisy heroism of constant firefighting.

It means shifting rewards and recognition away from lagging indicators like “bugs found in production” and toward leading indicators like process health, code quality metrics, and ultimately, customer loyalty and business success.

---

Part III: The Architect’s Blueprint: A System of Profound Knowledge

Armed with Deming’s book and Eleanor’s guidance, I began the slow, deliberate process of rebuilding my understanding of quality from the ground up.

I was no longer just managing a team; I was attempting to re-architect our entire approach to building software.

Deming’s System of Profound Knowledge, with its four interconnected components, became my blueprint.²¹

Pillar 1: Appreciation for a System

The first pillar of Deming’s philosophy is the understanding that an organization is a system—a network of interdependent components working together to accomplish a common A.M.²²

He argued that optimizing one part of the system (like maximizing a development team’s coding speed) at the expense of another (like the quality team’s ability to test thoroughly) will always lead to a sub-optimal result for the system as a whole.²²

This was the root of our dysfunction.

We had a development team optimized for speed, a QA team optimized for bug detection, and a project management team optimized for hitting deadlines.

These components were in constant competition, creating friction, blame, and ultimately, a poor-quality product.

My first act as a budding architect was to apply Deming’s 9th Point: “Break down barriers between departments”.²⁶

I stopped treating my team as a separate inspection unit.

Instead, I began embedding them directly into the development teams.

They were no longer gatekeepers at the end of the process; they became quality advocates and collaborators from the very beginning.

This approach is the philosophical heart of Total Quality Management (TQM), a management philosophy that makes quality the responsibility of every single employee.²⁷

I began to introduce the eight core principles of TQM as the practical application of systems thinking.¹⁶

We shifted our focus from internal metrics to the customer’s needs (

Customer Focus).

We empowered everyone to contribute to quality (Employee Involvement).

And we started mapping and improving our end-to-end development workflow, not just our isolated testing tasks (Process Approach).

We were beginning to manage the entire system, not just its warring parts.

Pillar 2: Knowledge of Variation

The second pillar, Knowledge of Variation, was my key to defusing the toxic, blame-filled culture that had plagued our teams.

Deming taught that there are two types of variation in any process: “common cause” variation, which is inherent to the system and predictable, and “special cause” variation, which comes from a specific, external event and is unpredictable.²¹

Deming argued that one of management’s most destructive mistakes is to treat common cause variation as if it were a special cause—in other words, to blame an individual for a flaw that is actually built into the system.

Every time we asked, “Who wrote this bug?” we were making this fundamental error.

The bug wasn’t the fault of a single “bad” developer; it was the predictable output of a system that had unclear requirements, inconsistent standards, and inadequate review processes.

We changed the question.

Instead of “Who?”, we started asking, “What in our process allowed this type of error to be created and go undetected?” This simple change was transformative.

It shifted the focus from individual blame to collective process improvement.

This was the living embodiment of Deming’s 8th Point: “Drive out fear”.²⁶

When people were no longer afraid of being singled out for mistakes, they became open and honest about the process’s weaknesses.

This allowed us to address the root causes of defects—improving how we write requirements, standardizing our coding practices, and implementing effective peer reviews—rather than just patching the symptoms.

Pillar 3: Theory of Knowledge

Deming’s third pillar, the Theory of Knowledge, posits that learning is not random; it is a structured cycle of theory, prediction, application, and observation.²¹

This is encapsulated in his famous

Plan-Do-Study-Act (PDSA) cycle.²⁵

A team forms a hypothesis for an improvement (Plan), implements the change on a small scale (Do), observes the results (Study), and then decides whether to adopt, adapt, or abandon the change (Act).

This iterative, knowledge-driven approach is the direct philosophical ancestor of modern Agile and DevOps methodologies.

It was here that I realized Deming’s “old” manufacturing ideas provided the perfect framework for the most cutting-edge software development practices.

We began using PDSA cycles to systematically improve our development process.

This led us directly to the concept of “Shift Left” Testing.

“Shifting left” is simply the modern software term for Deming’s mandate to “build quality into the product in the first place”.³⁰

It means moving testing activities from the end of the development lifecycle to the very beginning.³⁰

This required a new kind of quality professional.

We were no longer just testers; we became Quality Engineers (QE).

A QE is not a manual inspector at the end of the line.

They are a true Quality Architect—a software engineer whose specialty is quality.

They are involved from the initial design phase, focusing on building testability into the product, creating robust automation frameworks, and ensuring non-functional requirements like performance and security are considered from day one.¹⁴

We implemented concrete “Shift Left” practices like:

• Test-Driven Development (TDD): Where developers write a failing automated test before they write the code to make it pass. This ensures that every piece of code is born with a corresponding quality check.³³
• Behavior-Driven Development (BDD): Where we write acceptance tests in plain, human-readable language before development begins. This ensures that developers, testers, and business stakeholders all have a shared understanding of what success looks like.³⁴

By doing this, we were no longer inspecting for quality at the end.

We were engineering it into every step of the process.

Pillar 4: Knowledge of Psychology

The final pillar of Deming’s system is perhaps the most profound: Knowledge of Psychology.

Deming understood that systems are run by people, and that leaders must understand what truly motivates them.²⁴

He railed against management practices that rely on extrinsic de-motivators, such as fear, competition between colleagues, and numerical quotas.

He argued that these practices destroy what he called “pride of workmanship”—the intrinsic motivation that comes from doing a good job and being part of a successful team.²⁵

This was the cultural capstone of our transformation.

We made a series of radical changes, all based on Deming’s 14 Points:

• We eliminated numerical quotas (Point 11), such as individual bug counts, as a measure of performance. A tester who found zero bugs because they had helped architect a flawless feature was now seen as more successful than one who found 50 bugs in a broken one.
• We removed barriers that rob people of their right to pride in workmanship (Point 12) by abolishing our traditional annual performance reviews. Instead of a single, high-stakes judgment, managers became coaches, providing continuous feedback and support.
• We focused on instituting a vigorous program of education and self-improvement (Point 13), giving team members time and resources to learn new skills, whether in automation, security, or performance engineering.

By focusing on intrinsic motivation, we unlocked a new level of engagement and ownership.

Team members were no longer just cogs in a machine, but valued artisans who took immense pride in the quality of their collective work.

This directly countered the pervasive feeling in traditional QA of being a “substandard worker” whose only job is to click buttons.³⁵

To make this transformation tangible, we used Deming’s 14 points not as a philosophical treatise, but as a concrete action plan.

The table below shows how we mapped the old “firefighter” reality to the new “architect” actions, guided by Deming’s principles.

Deming’s Point for Management 26	Firefighter’s Reality	Architect’s Action Plan
3. Cease dependence on inspection.	End-of-cycle manual regression testing is the primary quality gate.	Implemented a “Shift Left” strategy with automated testing integrated into the CI/CD pipeline, making quality checks continuous.
8. Drive out fear.	QA is blamed for release delays; developers are blamed for bugs.	Instituted blameless post-mortems focused on process failures, not individual errors. Fostered psychological safety for open communication.
9. Break down barriers between departments.	QA and Development teams operate in separate silos with a formal hand-off process.	Embedded Quality Engineers directly within cross-functional development “pods” or “squads” to foster daily collaboration.
10. Eliminate slogans and targets.	Posters on the wall demand “Zero Defects” without providing the means to achieve it.	Replaced empty slogans with investment in tools, training, and process improvement that actually enabled higher quality.
12. Remove barriers to pride of workmanship.	Testers are judged by bug counts; developers by feature velocity.	Eliminated individual bug metrics; focused on team-based goals tied to customer satisfaction and product stability.

---

Part IV: Building a New Reality: The Results of Architectural Thinking

The true test of our transformation came with the next major product launch, about eighteen months after my epiphany.

The contrast with the previous disaster could not have been more stark.

The war room atmosphere was gone, replaced by a sense of calm, controlled purpose.

The daily stand-ups were quick and collaborative.

Because quality was being built and verified continuously through automated checks in our deployment pipeline, the final “testing phase” was almost a non-event.

The launch was smooth, the product was stable and fast, and the customer feedback was overwhelmingly positive.

Measurable Impact

The anecdotal success was backed by hard data.

By embracing the role of Quality Architects, we achieved results that were once unimaginable:

• We saw a 75% reduction in critical defects discovered in production within the first year.²⁰
• Our release cycle accelerated dramatically. We moved from large, risky quarterly releases to smaller, safer weekly deployments.²⁰
• Team morale soared. We virtually eliminated attrition on the quality team, which was now attracting top engineering talent.
• Our automated test coverage increased from 20% to over 85%, freeing up our QEs to focus on high-value activities like exploratory testing, security analysis, and performance optimization.³⁶

Validation Through Case Studies

My personal journey is not an isolated anecdote.

It is a small-scale reflection of a transformation that has played out in some of the world’s most successful companies for decades, proving the timeless relevance of these principles.

The legacy of Deming’s philosophy is monumental.

It was at the core of Ford’s dramatic turnaround in the 1980s, when they shifted their focus to “Quality is Job 1” and began collaborating with suppliers and empowering employees to fix problems on the assembly line.³⁷

It is the bedrock of the

Toyota Production System, a model of efficiency and quality so profound that it propelled Toyota to become the world’s largest and most successful automotive company.³⁸

Other giants like

Xerox, Lockheed Martin, and Procter & Gamble have all used these principles to drive quality and regain competitive advantage.³⁷

In the modern era, the language has changed, but the principles remain the same.

The “Shift Left” movement and the rise of Quality Engineering are direct descendants of Deming’s thinking.

Tech leaders like Microsoft, Netflix, and Atlassian have built their empires on the ability to deliver high-quality software at incredible speed.

They achieve this not by having massive armies of manual testers, but by building quality into their automated development pipelines, breaking down silos, and empowering their engineers to own quality from the very first line of code.⁴¹

The implementation of these principles is not merely a process improvement; it is the single greatest competitive advantage an organization can build.

When quality is built in, it reduces waste and rework, which is a direct cost saving.

This newfound efficiency, supercharged by automation, allows for faster and more frequent releases, increasing market responsiveness.

But the most powerful impact is what happens next.

When teams are freed from the constant, soul-crushing cycle of firefighting, and when the culture is one of psychological safety and pride, they gain the cognitive surplus and creative freedom to innovate.⁴²

This creates a virtuous cycle: quality enables speed, which in turn fuels innovation.

This is the engine that has driven the most dominant companies of the last half-century.

---

Conclusion: Another Word for Quality

I began this journey with a simple, desperate question born from failure: What is the point of “Quality Assurance” if it assures nothing? This led me to search for a better way, a new approach, and a new understanding.

The journey took me from the chaos of a software war room back to the wisdom of 1950s manufacturing and forward again to the cutting edge of DevOps.

Now, I can return to the query that started this exploration: “another word for quality assurance.”

After this journey, I’ve come to believe that the search for a simple synonym—like “vetting,” “review,” or “cross-check”—is a distraction.⁴³

It keeps us trapped in the firefighter’s mindset, viewing quality as a single action or a final step.

The real answer isn’t a different word; it’s a completely new definition.

Quality is not an activity; it is an emergent property of a well-designed and healthy system.

It is a culture of shared responsibility, where every single person is empowered and expected to contribute to the excellence of the whole.¹⁷

It is a philosophy driven by a deep, profound knowledge of how systems, variation, knowledge, and psychology interact.

It is the result of deliberate, proactive architectural thinking, not reactive, heroic firefighting.

As Deming himself insisted, the transformation to a quality-centric organization is not the job of one department.

“The transformation is everybody’s job”.²⁶

So, what is another word for quality assurance? It is stewardship.

It is pride.

It is collaboration.

It is the sound of a calm, productive workplace.

It is the quiet satisfaction of a happy customer.

It is, quite simply, the way a healthy, thriving, and excellent organization works.

Works cited

1. The Life of a QA Engineer: a Typical Day at Work | Careerist Blog, accessed on August 11, 2025, https://www.careerist.com/insights/the-life-of-a-qa-engineer-a-typical-day-at-work
2. The Red Wall Analogy – MaoMrtnz – Medium, accessed on August 11, 2025, https://maomrtnz.medium.com/the-red-wall-analogy-b25c06b5e702
3. What Is a Quality Assurance Analyst? 2025 Career Guide – Coursera, accessed on August 11, 2025, https://www.coursera.org/articles/quality-assurance-analyst
4. Quality Assurance vs Quality Control: Definitions & Differences | ASQ, accessed on August 11, 2025, https://asq.org/quality-resources/quality-assurance-vs-control
5. A Day in the Life of a Quality Engineer – 180 Engineering, accessed on August 11, 2025, https://180engineering.com/a-day-in-the-life-of-a-quality-engineer/
6. Is it common for devs to hate on QA/testers? : r/softwaretesting – Reddit, accessed on August 11, 2025, https://www.reddit.com/r/softwaretesting/comments/1j8lrws/is_it_common_for_devs_to_hate_on_qatesters/
7. So Much Hate for QA?? : r/softwaretesting – Reddit, accessed on August 11, 2025, https://www.reddit.com/r/softwaretesting/comments/1bsn8kb/so_much_hate_for_qa/
8. Common Quality Assurance Mistakes and How to Avoid Them: A Complete Guide – Medium, accessed on August 11, 2025, https://medium.com/@besocial_27455/common-quality-assurance-mistakes-and-how-to-avoid-them-a-complete-guide-bd528b5f66b6
9. Common QA Team Challenges and Solutions – TestDevLab, accessed on August 11, 2025, https://www.testdevlab.com/blog/qa-team-challenges-and-solutions
10. 12 Common Call Center QA Mistakes and How to Fix Them for Better Customer Satisfaction, accessed on August 11, 2025, https://www.ottoqa.com/otto-blog/call-center-qa-mistakes-and-how-to-fix-them
11. Inspection is too late. The quality, good or bad, is already in the product. – The W. Edwards Deming Institute, accessed on August 11, 2025, https://deming.org/inspection-is-too-late-the-quality-good-or-bad-is-already-in-the-product/
12. You Can’t Inspect Quality Into a Product – DevelopSense, accessed on August 11, 2025, https://developsense.com/blog/2025/04/you-cant-inspect-quality-into-a-product
13. It is better if we build quality into the product instead of trying to test quality in – TestAndAnalysis, accessed on August 11, 2025, https://testandanalysis.home.blog/2024/03/12/it-is-better-if-we-build-quality-into-the-product-instead-of-trying-to-test-quality-in/
14. QA vs. QE: What’s The Difference – Testlio, accessed on August 11, 2025, https://testlio.com/blog/qa-vs-qe-approach/
15. Quality Assurance (QA) vs. Quality Engineering (QE) – TestingXperts, accessed on August 11, 2025, https://www.testingxperts.com/blog/quality-assurance-vs-quality-engineering
16. Mastering the 8 Principles of TQM (Total Quality Management) – SixSigma.us, accessed on August 11, 2025, https://www.6sigma.us/six-sigma-in-focus/principles-of-tqm-total-quality-management/
17. Total Quality Management [Principles + Benefits] | Atlassian, accessed on August 11, 2025, https://www.atlassian.com/work-management/project-management/tqm
18. What is the Difference Between Quality Assurance and Quality Control?, accessed on August 11, 2025, https://themanufacturingacademy.com/what-is-the-difference-between-quality-assurance-and-quality-control-2/
19. Quality Engineering: Going beyond traditional software testing | In The Pocket, accessed on August 11, 2025, https://www.inthepocket.com/blog/quality-engineering-going-beyond-traditional-software-testing
20. QA to QE Transformation: Why Enterprises Focus on Quality Engineering | by Sandra Parker, accessed on August 11, 2025, https://sandra-parker.medium.com/qa-to-qe-transformation-why-enterprises-focus-on-quality-engineering-4a18b88116f1
21. The Lens of Profound Knowledge – PMC, accessed on August 11, 2025, https://pmc.ncbi.nlm.nih.gov/articles/PMC10887482/
22. Deming’s Profound Knowledge for Leadership, accessed on August 11, 2025, https://cha.com/wp-content/uploads/2019/08/Deming-Profound-Knowledge.pdf
23. The Deming System of Profound Knowledge® (SoPK) – The W. Edwards Deming Institute, accessed on August 11, 2025, https://deming.org/explore/sopk/
24. Understanding how work is done — Deming’s theory of profound knowledge | by Tom Connor | 10x Curiosity | Medium, accessed on August 11, 2025, https://medium.com/10x-curiosity/system-of-profound-knowledge-ce8cd368ca62
25. System of Profound Knowledge – Health Innovation West of England, accessed on August 11, 2025, https://www.healthinnowest.net/toolkits-and-resources/quality-improvement-tools-2/demings-system-of-profound-knowledge/
26. Dr. Deming’s 14 Points for Management – The W. Edwards Deming Institute, accessed on August 11, 2025, https://deming.org/explore/fourteen-points/
27. Total Quality Management (TQM): What is TQM? – ASQ, accessed on August 11, 2025, https://asq.org/quality-resources/total-quality-management
28. What are the 8 principles of TQM? – Isolocity, accessed on August 11, 2025, https://isolocity.com/what-are-the-8-principles-of-tqm/
29. Deming’s 14 Points | Lean UTHSC | Business Productivity Solutions | Information Technology Services (ITS), accessed on August 11, 2025, https://www.uthsc.edu/its/business-productivity-solutions/lean-uthsc/deming.php
30. Shift-Left – Testing, Approach, & Strategy – New Relic, accessed on August 11, 2025, https://newrelic.com/blog/best-practices/shift-left-strategy-the-key-to-faster-releases-and-fewer-defects
31. Shift Left Testing Approach and its Benefits | Ultimate Guide, accessed on August 11, 2025, https://www.xenonstack.com/insights/shift-left-testing
32. What is Shift-left Testing? | IBM, accessed on August 11, 2025, https://www.ibm.com/think/topics/shift-left-testing
33. Agile Methodology in Testing: 5 Examples for the Agile Tester – Perforce Software, accessed on August 11, 2025, https://www.perforce.com/blog/alm/what-agile-testing-5-examples
34. Shift-Left Testing and Its Importance in Software Development – TestGrid, accessed on August 11, 2025, https://testgrid.io/blog/what-is-shift-left-testing-and-why-is-it-important/
35. Frustration being QA and need help on how can I not let it control me – Reddit, accessed on August 11, 2025, https://www.reddit.com/r/QualityAssurance/comments/1ditlkv/frustration_being_qa_and_need_help_on_how_can_i/
36. Success Stories in QA Transformation: Effective Practices from the Field | MoldStud, accessed on August 11, 2025, https://moldstud.com/articles/p-inspiring-success-stories-of-qa-transformation-highlighting-effective-practices-from-real-world-experience
37. W. Edwards Deming’s 14 Points Revisited – Anaar, accessed on August 11, 2025, https://anaar.com/blog/w-edwards-demings-14-points-revisited/
38. TQM Case Studies: Lessons from Leading Organizations – isixsigma.com, accessed on August 11, 2025, https://www.isixsigma.com/total-quality-management-tqm/tqm-case-studies-lessons-from-leading-organizations/
39. Companies managing using Dr. Deming’s management ideas. – Curious Cat, accessed on August 11, 2025, https://curiouscat.com/management/deming/deming_based_organizations
40. How Companies Have Applied Deming’s 14 Points in Manufacturing – Worximity, accessed on August 11, 2025, https://www.worximity.com/blog/how-companies-have-applied-demings-14-points-in-manufacturing
41. What is Shift Left Testing? – BuzzClan, accessed on August 11, 2025, https://buzzclan.com/quality-assurance/what-is-shift-left-testing/
42. Proud To Be Labeled A Deming-Inspired Company – The W. Edwards Deming Institute, accessed on August 11, 2025, https://deming.org/deming-today/proud-to-be-labeled-a-deming-inspired-company/
43. 7 Synonyms & Antonyms for QUALITY ASSURANCE | Thesaurus.com, accessed on August 11, 2025, https://www.thesaurus.com/browse/quality-assurance
44. QUALITY ASSURANCE Synonyms: 439 Similar Words & Phrases – Power Thesaurus, accessed on August 11, 2025, https://www.powerthesaurus.org/quality_assurance/synonyms
45. Deming’s 14 Points for Management Explained – YouTube, accessed on August 11, 2025, https://www.youtube.com/watch?v=2zHFYzqaxaE&pp=0gcJCfwAo7VqN5tD