Chapter 2 — The Evolution from QA to Quality Engineering

Metadata

Opening Quote

MSQE principle: A profession evolves when its feedback loops no longer match the speed, complexity, and consequences of the systems it serves.

Opening Story

The following illustrative scenario takes place in a team that has recently moved from releasing a business application every quarter to deploying changes several times each week. Maya, the QA lead, still receives the final request to approve each release. Her team runs the regression suite, reviews open defects, and confirms that the planned user journeys work in the staging environment.

One Friday, every pre-release check passes. Within an hour of deployment, customers report that invoices are missing from the self-service portal. The defect is not in the feature the team tested. A background-job configuration changed with the deployment, and the production queue now processes invoices with a different retention setting. The application is running, the API responds, and the release dashboard is green. The customer outcome is still wrong.

Maya can ask a sensible testing question: which scenario was missing? But the more useful questions are broader:

• Who owned the configuration change and its operational consequences?
• How did the team establish that the deployed system, rather than only the application code, met the customer need?
• Which production signals would have shown delayed invoice publication before customers reported it?
• Why was a single release approval expected to provide confidence in a system assembled from code, configuration, infrastructure, data, and dependencies?

The answer is not that QA failed or that testing no longer matters. The answer is that the system of work changed. Quality practices had to expand so that evidence, ownership, and feedback could keep pace with modern software delivery.

Why This Chapter Matters

Many experienced QA Engineers have already developed the foundations of Quality Engineering: they clarify requirements, model risks, investigate failures, communicate evidence, and advocate for users. The evolution to Quality Engineering does not discard those skills. It applies them earlier, more broadly, and more continuously across the software lifecycle.

This distinction matters because the labels used by organisations are inconsistent. A role called QA Engineer may include exploratory testing, test automation, release governance, quality coaching, and production analysis. A role called Quality Engineer may sometimes be narrowly focused on a test framework. Job titles alone do not tell you how quality is being practised.

This chapter therefore describes the evolution in terms of the problems each practice addressed. Quality Control, Quality Assurance, software testing, and automation remain valuable. Modern Quality Engineering connects their strengths with product design, delivery systems, production operations, and organisational learning.

Learning Objectives

By the end of this chapter, you will be able to:

• Explain the historical evolution of software quality.
• Differentiate Quality Control, Quality Assurance, software testing, and Quality Engineering.
• Describe how Agile, DevOps, and cloud delivery changed the practice of software quality.
• Explain why traditional QA responsibilities expanded into Quality Engineering.
• Identify the competencies required of a modern Quality Engineer.

The Early Days of Software Quality

Software quality did not emerge as a single, linear discipline. It drew on quality-management ideas developed for products and services, then adapted them to a medium whose behaviour is determined by logic, data, configuration, and interactions with other systems. The terms have varied by organisation, industry, and era, so this chapter uses them as practical distinctions rather than universal job descriptions.

In conventional product production, inspection can compare a completed item with an agreed specification. That logic remains useful for software: a reviewer can inspect a change, a test can compare actual and expected behaviour, and a release check can confirm defined acceptance criteria. Software also differs in important ways. A defect may be latent until a rare state, a particular data set, a load condition, or an interaction with another service reveals it. A copy of a program can be reproduced perfectly while still reproducing its design flaw perfectly.

As software systems became more connected and delivery cycles shortened, teams needed more than inspection at the end. They needed ways to prevent avoidable problems, discover uncertain behaviour, repeat checks economically, and learn from production. The practices in the rest of this chapter developed in response to those needs.

ISO 9000:2026 provides a current vocabulary for quality-management fundamentals, while ISO/IEC/IEEE 29119-1:2022 defines general software-testing concepts and presents key concepts for the wider 29119 series.¹² These standards do not prescribe one organisational model for software teams. They provide common language that teams can adapt to their product context and obligations.

The QA to Quality Engineering Evolution diagram maps the expanding feedback, ownership, and evidence scope of these practices without treating them as replacements for one another.

Quality Control

Quality Control (QC) focuses on determining whether a product, service, or work item meets specified requirements. In software delivery, QC is concerned with outputs: a reviewed change, a completed build, a test result, a deployment, or a released capability. Its central question is: does this result conform to the agreed criteria?

QC emerged because customers and organisations need evidence that what they receive is acceptable. It provides a necessary control point when the cost of nonconformance is meaningful. Examples include checking that acceptance criteria have been met, reviewing a configuration change, verifying a migration outcome, or confirming that a release contains the approved version.

QC remains essential, especially where release evidence, auditability, or independent assessment is required. Its limitation is scope: it can only assess the criteria and conditions that are examined. If the requirement is ambiguous, the environment is unrealistic, or a risk has not been considered, a successful QC activity may create confidence without covering the actual failure mode.

The Quality Engineer's task is not to remove useful controls. It is to ensure that controls are connected to relevant risks, clear requirements, and timely feedback. A final check is strongest when it confirms evidence gathered throughout the lifecycle rather than bearing the entire burden of quality.

Quality Assurance

Quality Assurance (QA) focuses on providing confidence that the processes used to create and maintain a product are capable of meeting relevant requirements. Its central question is: are we working in a way that makes the desired result likely and repeatable?

QA emerged because inspection alone discovers problems after effort has already been spent. A team can inspect every release and still repeatedly build the wrong thing, introduce the same category of defect, or rely on an undocumented process that cannot be reproduced. QA adds prevention: clear ways of working, defined responsibilities, quality planning, reviews, audits where appropriate, and improvement based on evidence.

In software, effective QA is not synonymous with paperwork. A lightweight quality plan for a service might establish how important risks are assessed, what evidence is required before deployment, how changes are traced, and how incidents feed back into future work. In a regulated context, QA may include more formal documentation and independent review. The amount of formality should reflect risk, regulation, and consequence—not habit.

ISO 9000 distinguishes quality-management fundamentals and vocabulary from the requirements of a quality-management system. This is useful because it prevents a common confusion: a standard can guide a management system, but it does not itself make a product usable, secure, or reliable.¹

Why QA expanded

Traditional QA responsibilities often grew around planned phases: requirements, design, implementation, test, release, and maintenance. That model can work when changes are relatively infrequent and system boundaries are stable. It becomes strained when small changes move quickly through automated pipelines, when infrastructure and configuration are versioned alongside code, or when production behaviour is the only place a distributed workflow can be fully observed.

QA therefore needed closer connection to engineering decisions and operational feedback. The profession did not move from prevention to testing; it gained a wider prevention surface. Quality can be influenced through design review, test strategy, environment design, deployment controls, observability, incident learning, and the way teams make trade-offs.

The Rise of Software Testing

Software testing is the activity of evaluating a product or component to find defects, provide information about quality, or verify that it satisfies specified requirements under defined conditions. Its central question is: what does the system actually do when we exercise it? ISO/IEC/IEEE 29119-1:2022 defines general concepts for software testing and anchors the wider 29119 testing-standard series.²

Testing became a distinct professional practice because software behaviour cannot be inferred reliably from intent, design documents, or code review alone. Engineers need empirical evidence. A test may expose incorrect calculations, a failed integration, inaccessible interaction, unsafe error handling, or unexpected behaviour with a particular input. Exploratory testing adds another important capability: a skilled tester can investigate a system adaptively, learn from what it observes, and pursue risks that a prewritten check did not anticipate.

Testing changed the conversation from "we believe the feature is complete" to "under these stated conditions, we observed this behaviour." That is a major improvement in engineering discipline. It also has limits:

• A passing test does not show that untested conditions are safe.
• A test environment may differ materially from production.
• A scripted check may confirm an expected path while missing a harmful interaction.
• Tests reveal evidence; they do not resolve ambiguous requirements or compensate for a weak design.

The appropriate response is not to distrust testing. It is to use testing deliberately. A risk-based test strategy selects meaningful conditions, combines automated and exploratory approaches, and makes clear what the available evidence does and does not establish.

Testing as an engineering discipline

Modern testing involves more than executing scripts. It can include testability analysis, test-data design, interface-contract evaluation, model-based reasoning, fault investigation, performance experiments, accessibility assessment, and production verification. These activities need engineering judgment because the cost of exhaustive testing is usually impractical or impossible.

The Quality Engineer retains the tester's critical habits: observe carefully, challenge assumptions, construct useful experiments, report evidence precisely, and keep the user impact visible. The role expands the point at which those habits are applied—from after implementation to throughout discovery, design, delivery, and operation.

Test Automation

Test automation uses software to set up conditions, execute checks, compare results, and report evidence with repeatable speed. Its central question is: which valuable checks should the delivery system perform consistently and economically?

Automation emerged because manual regression checking does not scale indefinitely with change frequency, product scope, supported environments, and dependency combinations. A well-chosen automated check can make feedback available in minutes rather than days, which allows a team to correct problems while the context is still fresh. It also reduces the variation that arises when a routine check is performed differently each time.

Automation is a capability, not a quality outcome. A large automated suite may still provide poor evidence if it is slow, flaky, hard to understand, detached from risks, or concentrated on low-value paths. The useful unit of discussion is not the number of automated tests; it is the decision that the resulting evidence enables.

Automation also expanded the Quality Engineer's technical responsibilities. The role increasingly requires fluency in programming, source control, continuous integration, environment configuration, test data, service interfaces, and diagnostic information. This is not a requirement for every quality specialist to become an expert in every platform. It is a requirement to understand how delivery evidence is produced and where it can fail.

Agile and Continuous Delivery

The Agile Manifesto, published in 2001, expressed a preference for early and continuous delivery of valuable software, close collaboration, and responsiveness to change.³ Agile methods are diverse, but their common effect on quality work was to shorten the distance between an idea, an implementation, feedback, and the next decision.

Shorter iterations exposed the limits of a hand-off model in which developers complete work and testers assess it later. If testing begins only after a batch is "done," the team accumulates uncertainty and delays learning. Agile teams therefore brought quality activities into refinement, acceptance-criteria design, collaborative testing, and frequent demonstration. The familiar phrase shift left describes moving appropriate quality activities earlier, where they can influence understanding and design.

Continuous delivery extended this feedback model. It is the capability to keep a change in a deployable state through automated build, validation, and deployment practices; it does not require every change to be released to every user immediately. The important quality implication is that validation must be designed for flow. Checks that take weeks, environments that cannot be reproduced, and release decisions based only on personal knowledge become constraints on safe change.

What Agile changed—and what it did not

Agile did not make independent assessment, deep exploratory testing, security review, or compliance obligations disappear. It challenged the assumption that these activities should be isolated until the end. The most effective teams decide which work should happen early, which work needs an independent perspective, and which evidence can only be gathered after deployment.

For a QA Engineer, this change is often a transition from receiving a feature to shaping it. Participation in refinement can reveal ambiguity before it becomes implementation. Pairing with engineers can improve testability and diagnostic information. Discussing release signals can make production validation part of the delivery plan rather than an emergency response.

DevOps and Shared Ownership

DevOps is not a toolset or a single team. It is a set of cultural and technical practices that reduces unnecessary separation between the people who build software and the people who operate it. Its quality implication is shared ownership of the service outcome, including deployability, operability, reliability, security, and recoverability.

DevOps emerged because a change that works in a development environment can still fail when deployed into a production system with real dependencies, variable traffic, operational constraints, and user behaviour. Separating development from operations created hand-offs precisely where important evidence was needed. Shared ownership makes those boundaries visible and gives teams a reason to design for them.

This does not mean every engineer must perform every operational task or that specialist roles disappear. It means that responsibility for the outcome cannot be transferred away with a ticket or a release approval. Operations specialists, security specialists, developers, product managers, and Quality Engineers bring different expertise; the service succeeds only when their contributions form a coherent system.

Google's SRE guidance illustrates one production-oriented approach: teams define measurable service objectives, monitor the relevant indicators, and use the resulting evidence to make risk and investment decisions. An error budget is the permitted amount of unreliability within an objective over a defined period; it makes the trade-off between reliability and change explicit.⁴

Cloud changed the unit of quality

Cloud platforms and cloud-native architectures made infrastructure, configuration, managed services, identities, policies, and observability services part of the versioned delivery system. They also made it easier to provision environments and deploy changes frequently. The result is not automatically higher quality. It is a larger and more dynamic surface on which quality can succeed or fail.

For example, a feature may be functionally correct while its identity policy denies a legitimate user, its configuration directs traffic incorrectly, a managed dependency times out, or its telemetry cannot distinguish a healthy response from a business failure. Quality work therefore needs to examine the system in operation, not only the application in isolation.

Observability is the ability to infer a system's internal state from its externally available signals. It supports Quality Engineering by making production behaviour available as evidence. It is an engineering capability that helps teams achieve and evaluate quality; it is not an additional top-level product-quality characteristic in ISO/IEC 25010:2023.⁵

The Emergence of Quality Engineering

Quality Engineering emerged as software systems and delivery methods made a final-test or final-approval model insufficient. It is not a standardised replacement title, and organisations use it differently. In this handbook, Quality Engineering is an engineering discipline that coordinates the practices required to design, evaluate, and improve quality across discovery, development, delivery, operation, and evolution.

This is an original MSQE framing, not an ISO or IEEE definition. Its purpose is to make the scope of the work clear: Quality Engineering includes testing, automation, QA, and QC where those practices are useful, but it also addresses the conditions that make them effective.

Engineering principles for the transition

The following principles help a QA Engineer extend existing strengths into Quality Engineering:

• Start with outcomes and risks. Ask what users need to achieve, what could prevent it, and which failures are unacceptable.
• Design for evidence. Make systems testable, observable, diagnosable, and safe to experiment with.
• Use feedback at the right time. Seek early feedback to influence design and later feedback to learn from actual operation.
• Treat automation as product code. It needs ownership, design, review, maintenance, and useful failure information.
• Make trade-offs visible. Reliability, speed, security, usability, maintainability, and cost must be considered in the relevant context.
• Improve the system of work. A recurring defect is evidence about the product and about the way the team discovers, designs, delivers, and learns.

These principles are compatible with recognised standards, but they are not asserted as a new standard. They are the MSQE teaching perspective used throughout this handbook.

The Modern Quality Engineer

A modern Quality Engineer is a systems thinker and practical collaborator. The role is not defined by owning every test, approving every deployment, or administering a particular tool. It is defined by the ability to improve the team's confidence that a system will meet stakeholder needs in its intended context.

The work commonly spans five competency areas.

The transition is therefore an expansion, not a rejection. An experienced tester who understands how users fail, how systems fail, and how evidence can mislead brings a valuable perspective to design and operational discussions. The next capabilities to develop are often technical fluency, systems thinking, and the confidence to influence decisions before a test environment exists.

A practical growth path

Choose one quality concern in the system you currently support and follow it across the lifecycle. For example, trace an important customer workflow from requirement through design, automated checks, deployment, telemetry, support contacts, and incident response. At each stage, ask:

• What decision is made here?
• What evidence informs it?
• Which risk is not yet addressed?
• Who needs to collaborate for the next improvement?

This exercise makes the change in role tangible. You are not leaving testing behind; you are using testing expertise to make the whole delivery system more capable of producing quality.

Comparison Table

The following comparison is a teaching model, not a maturity ranking. Teams may use all five practices at the same time. The question is whether each practice is applied deliberately and connected to the others.

Common Misconceptions

"Quality Engineering is just a new name for test automation"

Automation is an important Quality Engineering capability, but it is not the discipline's whole scope. A team can automate thousands of checks and still lack clear quality requirements, production insight, or shared ownership for a harmful outcome.

"Agile removed the need for QA"

Agile changed when and how quality work is performed. It did not remove the need for prevention, independent thinking, exploratory investigation, or evidence-based decisions. It made close collaboration and timely feedback more important.

"Shared ownership means nobody is accountable"

Shared ownership means that contributors remain connected to a common outcome. It requires clear responsibilities and decision rights. A Quality Engineer can facilitate the work without becoming the sole owner of quality.

"A green pipeline proves that a release is safe"

A green pipeline proves that its configured checks passed under the conditions in which they ran. It does not prove that all requirements are correct, dependencies are healthy, data is representative, or production behaviour will match expectations.

"Quality Control and Quality Assurance are obsolete"

Both remain useful. QC provides conformance evidence, and QA supports prevention and repeatability. Quality Engineering incorporates their strengths while connecting them to modern delivery and operations.

Industry Perspective

The profession evolved because the delivery environment evolved. Teams now commonly operate systems that are distributed, continuously changed, dependent on managed services, and directly connected to customers. Quality decisions are made in product refinement, code review, infrastructure design, pipeline configuration, deployment, incident response, and operational planning—not only in a dedicated test phase.

Industry research reinforces the need to treat delivery performance as a system concern. DORA's current guidance describes five delivery-performance metrics that cover throughput and instability, and emphasises using them in the context of a particular application or service rather than as universal targets.⁶ These measures are not a Quality Engineering scorecard. They are examples of the operational evidence teams can use to understand how safely and effectively change moves through their system.

The Software Engineering Body of Knowledge also recognises software requirements, software quality, software testing, software maintenance, configuration management, engineering management, and engineering professionalism as connected areas of practice.⁷ This breadth is important. Quality Engineering is not a claim that one person must master every specialty; it is a recognition that quality outcomes depend on how these specialties work together.

For regulated, safety-critical, or high-consequence systems, formal assurance and independent assessment may be indispensable. For a small internal tool, a lighter approach may be sufficient. In both cases, the governing principle is the same: choose controls and evidence that are proportionate to the consequences of failure, and improve them as the system and its risks change.

Engineering Perspective

The evolution from QA toward Quality Engineering is visible in the boundary of feedback that a team can use. A testing-focused role may receive an implemented feature, exercise its behaviour, and report evidence about defects or unmet acceptance criteria. That remains valuable: empirical testing, exploratory investigation, and clear defect communication are essential ways to reveal risk. Quality Engineering widens the point at which those capabilities influence an engineering decision.

In practice, this means bringing risk questions into discovery and requirements; considering testability, interfaces, data, configuration, and failure behaviour during design; and choosing automation that creates timely, diagnosable feedback. It also means treating CI/CD results as evidence with stated limits, rather than as a blanket guarantee. A delivery pipeline can confirm that selected controls passed. It cannot by itself establish that production dependencies, real workloads, customer data, or operational conditions will behave as assumed.

The widened boundary continues after deployment. Production signals, support evidence, incidents, and recovery outcomes can reveal whether a quality claim still holds under real conditions. That information should inform the next requirement, design, verification, or operational decision. The aim is not to assign every activity to a Quality Engineer, or to replace QA, testing, or automation with a new title. It is to ensure that the people who define, build, deliver, and operate a system have relevant risks, evidence, and decision ownership visible while meaningful options remain.

Chapter 4 examines this work across the delivery lifecycle, and Chapter 8 develops the Modern Quality Engineer role in depth. Here, the central point is the professional evolution: established QA strengths gain greater engineering leverage when they are connected to earlier decisions, delivery evidence, production learning, and continuous improvement.

Summary

Software quality practices expanded because software delivery expanded. Quality Control addressed conformance of outputs. Quality Assurance added prevention and confidence in the system of work. Software testing supplied empirical evidence about behaviour. Test automation made selected feedback repeatable at delivery speed. Agile, DevOps, and cloud delivery made it necessary to connect all of these practices to rapid change, production operation, and shared ownership.

Modern Quality Engineering does not replace the earlier practices. It integrates them around the lifecycle of a product and the outcomes that matter to its stakeholders. For QA Engineers, the transition is an opportunity to apply existing strengths in risk analysis, experimentation, evidence, and user advocacy to a broader engineering system.

Key Takeaways

• The evolution from QC to Quality Engineering is an accumulation of practices, not a sequence in which earlier practices become irrelevant.
• QC checks whether an output conforms to defined criteria; QA improves confidence in the way work is performed; testing observes behaviour; automation makes selected checks repeatable.
• Agile shortened feedback cycles, while continuous delivery made validation part of the flow of change.
• DevOps and cloud delivery made operational behaviour, configuration, infrastructure, and production telemetry central to quality work.
• Quality Engineering is an original MSQE framing that integrates quality activities across discovery, delivery, operation, and continuous improvement.
• Experienced QA skills transfer directly to Quality Engineering, especially risk analysis, test design, investigation, communication, and user advocacy.
• The modern Quality Engineer improves the system that produces and sustains quality; the role does not merely approve or reject releases.

Review Questions

1. Why is it misleading to describe the evolution from QC to Quality Engineering as a simple replacement sequence?
2. What problem does Quality Control solve, and what can it not establish on its own?
3. How does Quality Assurance add prevention to a quality approach?
4. Why did software testing become a distinct engineering practice?
5. What makes a test-automation investment valuable beyond the number of automated checks?
6. How did Agile and continuous delivery change the timing of quality feedback?
7. What does shared ownership mean in a DevOps-oriented team?
8. Which of your current QA skills would transfer directly to Quality Engineering, and which new capability would you prioritise developing?

Interview Questions

1. Explain the difference between Quality Control, Quality Assurance, software testing, test automation, and Quality Engineering.
2. How would you help a team move from release approval as a single quality gate to evidence-based delivery decisions?
3. A team has a large automated regression suite but regularly encounters production incidents. What would you investigate first?
4. How would you explain shared ownership of quality without making accountability ambiguous?
5. What quality activities should occur before implementation, during delivery, and after deployment for a high-risk change?
6. Describe how an experienced manual tester can add value in a DevOps or cloud delivery team.
7. Which delivery and operational signals would you use to assess whether a team's quality practices are improving?

Practical Exercise

Choose a recent feature, incident, or release from your own context. Map the evidence that was available at each stage and identify one improvement that would have reduced uncertainty earlier or exposed the risk sooner.

Then answer the following questions:

1. Which existing QC, QA, testing, or automation practice gave the most useful evidence?
2. Where did a hand-off, assumption, or missing signal create unnecessary risk?
3. What single change could move useful feedback earlier or make it more actionable?
4. Who would need to collaborate to make that change sustainable?

The embedded evolution-and-evidence map is intentionally self-contained. For a reusable lifecycle evidence activity, use the Continuous Quality Planning Worksheet.

Practical Resources

• Build from: Chapter 1: What Is Modern Software Quality Engineering? establishes the engineering-first definition used in this chapter.
• Use the QA to QE Personal Transition Plan to translate the evolution into an individual development path.
• Continue: Chapter 3: Understanding Software Quality examines the quality concerns that this evolving profession must address.

Further Reading

• International Organization for Standardization. ISO 9000:2026 — Quality management — Fundamentals and vocabulary.
• International Organization for Standardization. ISO/IEC/IEEE 29119 series — Software testing.
• Agile Alliance. Manifesto for Agile Software Development.
• DORA. Software delivery performance metrics.
• Google. Site Reliability Engineering: Service Level Objectives.
• IEEE Computer Society. Guide to the Software Engineering Body of Knowledge (SWEBOK Guide), Version 4.0.

References

Chapter Checklist

• I can explain why QC, QA, testing, automation, and Quality Engineering coexist rather than replace one another.
• I can describe the problem each practice emerged to solve and its limitation when used alone.
• I can explain how Agile, continuous delivery, DevOps, and cloud delivery expanded the scope of quality work.
• I can identify how my existing QA experience transfers to modern Quality Engineering.
• I can map quality evidence across discovery, delivery, production, and continuous improvement.