Chapter 8 — The Modern Quality Engineer

Metadata

Opening Quote

MSQE principle: A Quality Engineer increases a team's ability to make quality visible, achievable, and sustainable.

Opening Story

The following illustrative scenario contrasts two engineers working on the same account-recovery change. The product allows a customer who has lost access to reset credentials after completing an identity-verification step.

Jordan receives the finished feature in a test environment. Jordan executes the acceptance tests, explores error messages, logs several defects, and reports that the main journey passes after fixes. This is useful work. The investigation finds a confusing recovery screen and a missing validation rule before customers encounter them. But the feature's identity-provider dependency, audit requirements, retry behaviour, production signals, and rollout plan were already chosen. When a provider delay later prevents some valid customers from completing recovery, Jordan is asked why testing did not find it.

Riley joins the work earlier as a Quality Engineer. During refinement, Riley asks what a safe recovery outcome means, which customers may be harmed by false acceptance or false rejection, and what evidence is needed for a release decision. During design, Riley helps the team identify the identity-provider timeout, audit event, fallback policy, test-data need, and customer-outcome signal. During implementation, Riley contributes focused scenarios and helps make the provider interface controllable in tests. Before release, Riley helps the accountable release owner review the evidence and rollback options. After release, Riley helps interpret the recovery-completion signal and incorporates an observed edge case into the next design discussion.

Riley did not replace the product manager, architect, developer, security specialist, or operations team. Riley did not perform every test. The difference is influence: Riley helped the team make quality decisions earlier, connect evidence across the delivery system, and learn from operation. That is the distinctive contribution of the Modern Quality Engineer.

Why This Chapter Matters

The transition from traditional QA to Quality Engineering can seem like a demand to abandon valuable testing skills and become a different kind of engineer overnight. It is neither. Quality Engineering builds on the ability to understand user behaviour, design useful scenarios, investigate defects, communicate risk, and challenge assumptions. It expands where and how those skills are applied.

Chapters 1–7 establish the foundations: quality as a system property, the evolution from QA to QE, quality models, lifecycle activity, feedback timing, systems reasoning, and collaborative culture. This chapter synthesizes those foundations into a professional identity. It explains what a Modern Quality Engineer contributes, the competencies they develop, the relationships they build, and how an experienced QA Engineer can plan a practical transition.

Chapter 4 remains the detailed authority for quality work across lifecycle phases. Chapter 5 owns Shift Left, Shift Right, and Shift Everywhere; Chapter 6 owns systems thinking; and Chapter 7 owns culture and DevOps mindset. This chapter does not repeat them. It focuses on the person and practice that connects them: the Modern Quality Engineer's responsibilities, technical breadth, influence, and career development.

Learning Objectives

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

• describe the role and value of the Modern Quality Engineer;
• distinguish Quality Engineering from traditional QA without dismissing testing or assurance;
• identify the technical and professional competencies the role requires;
• explain where QE contributes throughout software delivery;
• make evidence-based decisions about quality risk, test strategy, and release confidence;
• describe how Quality Engineers collaborate with other engineering roles; and
• create a realistic personal roadmap from QA to QE.

The Evolution of the Quality Engineer

Job titles are inconsistent. A tester in one organisation may perform exploratory work and deep automation; a Quality Engineer in another may mainly coordinate release checks. Responsibilities and evidence are more informative than a title.

The sequence is not a universal ladder. Teams may use SDET, QE, test architect, software engineer in test, or platform-quality engineer for overlapping work. Nor does a Quality Engineer stop testing. Testing remains a central method for obtaining evidence; it is simply not the whole definition of quality work.

The important shift is from a question such as “Does the completed feature work?” to a broader set of questions: “What outcome matters? What can make it fail? Which design and delivery decisions control that risk? What evidence is sufficient for the next decision? What will production teach us?” A Quality Engineer helps the team answer these questions before a failure becomes expensive.

Defining the Modern Quality Engineer

For this handbook, a Modern Quality Engineer is an engineer who collaborates across product, development, delivery, and operation to make quality requirements, risks, evidence, and learning explicit, so that software systems can be changed and operated safely.

This is an original MSQE working definition, not an ISO, IEEE, or industry-standard role definition. It deliberately focuses on contribution rather than job title. It does not imply that one person owns all quality or that every organisation needs a separate QE function.

Four aspects distinguish the role:

1. Engineering orientation. The Quality Engineer influences requirements, architecture, implementation, automation, deployment, and operation rather than receiving finished work only for inspection.
2. Evidence orientation. They help the team turn confidence into observable criteria, checks, signals, and decision records.
3. System orientation. They reason about interactions among people, software, data, infrastructure, dependencies, and operational processes.
4. Enabling orientation. They improve team capability through coaching, tools, examples, and feedback rather than becoming a permanent gate.

ISO/IEC 25010:2023 provides a product-quality model that can support the specification, measurement, and evaluation of quality throughout a lifecycle.¹ It does not define a Quality Engineer role. MSQE uses standards as a vocabulary and source of discipline, then applies them through context-specific engineering responsibilities.

Core Responsibilities

Responsibilities vary by product risk, team topology, and level of maturity. A Quality Engineer is not expected to perform every activity personally. The role is to ensure that important quality work has an appropriate owner, evidence, and feedback path. Observability is the ability to infer a system's internal state from the signals it exposes. CI/CD refers to continuous integration and continuous delivery: frequently integrating and verifying changes while keeping software in a deployable state through a controlled release process.

Observability is an engineering capability that supports the evaluation of product quality; it is not an additional top-level ISO/IEC 25010 characteristic. CI/CD is a means of obtaining and acting on evidence, not a quality guarantee.

Core Competencies

A Modern Quality Engineer needs technical breadth because quality risks cross many disciplines. They also need enough depth in one or more areas to make credible engineering contributions. Breadth does not mean superficial familiarity with every tool; it means being able to ask sound questions, understand evidence, and collaborate effectively with specialists.

Technical competencies

Artificial intelligence literacy does not require every Quality Engineer to build machine-learning models. It means understanding where AI-assisted or model-based behaviour introduces new uncertainty: training and evaluation data, non-deterministic outputs, prompts, safety controls, privacy, monitoring, and human oversight.

Professional competencies

The competencies reinforce one another. Programming without risk judgement can produce a large but low-value test suite. Communication without technical evidence can become generic advocacy. Quality Engineering becomes credible when technical contribution and professional influence are connected.

The Quality Engineer Competency Model

The Quality Engineer Competency Model is an original MSQE educational framework. It is not a job-standard, certification syllabus, or universal sequence. It helps readers organise development without assuming that every competency has equal depth at every career stage.

The model is a map, not a checklist. A QE might build early depth in API automation and later add cloud operations, or begin as a data tester and deepen software engineering. The aim is an increasingly connected capability, not uniform expertise.

The Quality Engineer Competency Model diagram shows the seven competency categories and their connected development paths.

The Quality Engineer Across the Delivery Lifecycle

Chapter 4 explains lifecycle activities in detail. The concise view below shows how the Modern Quality Engineer participates without owning every task.

This is contribution, not hierarchy. Product managers decide priorities; architects make structural decisions; developers implement; operations and SRE teams operate specialised capabilities; security experts guide security controls. A Quality Engineer helps connect these decisions to quality evidence and customer risk.

Relationships with Other Engineering Roles

Modern Quality Engineering is collaborative by design. The Quality Engineer does not become a substitute project manager, architect, or specialist. The role makes the quality implications of shared work more visible.

Role labels vary. The durable principle is collaboration around a customer outcome and a clear decision. Microsoft guidance on DevOps culture makes the same distinction: teams share responsibility for workload operation while retaining clear roles and decision authority.²

Technical Breadth vs Technical Depth

Technical breadth lets a Quality Engineer recognise that a production defect may involve an API contract, data migration, configuration, workload, access rule, deployment, or operational process. It prevents the role from being confined to a user interface or a test-management tool.

Technical depth makes the contribution concrete. A Quality Engineer with depth in automation can build a trustworthy contract-testing capability. One with depth in performance can define workloads and diagnose bottlenecks. One with security depth can contribute more effectively to threat modelling. One with data depth can identify integrity and reconciliation risks. Over time, many senior practitioners develop a T-shaped profile: broad enough to collaborate across engineering concerns, with one or more areas deep enough to lead improvement.

Depth should match the team's needs and the engineer's interests. It is more useful to become genuinely capable in a focused area than to collect superficial exposure to many tools. Breadth grows through collaboration: read code, join incident reviews, inspect dashboards, contribute to design, and learn the constraints faced by adjacent roles.

Decision Making

Quality Engineers make evidence-based decisions by connecting a decision to its risk, the available evidence, its limitations, and an accountable owner. Evidence is not only automated test output. It can include requirements examples, architecture decisions, code review, threat analysis, exploratory findings, contract checks, deployment verification, service indicators, customer feedback, and incident records.

Working through quality disagreements

Release and quality disagreements are normal when people hold different evidence, incentives, or risk tolerance. A Quality Engineer should not try to win by asserting that “quality says no.” Instead, make the disagreement testable. State the decision that is being requested, the customer or business outcome at risk, the evidence that supports each view, the uncertainty that remains, and the options available: reduce scope, add evidence, change exposure, accept the risk with an accountable owner, or defer the change.

For example, a product manager may need a campaign feature on a fixed date while an engineer is concerned about a new payment dependency. The Quality Engineer can help identify the smallest valuable scope, the relevant failure condition, a controlled-release option, and signals that would require a pause. The release owner still decides within the organisation's governance model. The QE contribution is to replace an argument based on confidence or hierarchy with an evidence-based decision whose consequences are understood.

Evidence has limits. A green pipeline shows that selected checks passed in a particular context; it does not prove that every relevant failure is impossible. A Quality Engineer should state both what the evidence supports and what it does not. ISO/IEC/IEEE 29119-1:2022 provides common concepts for software testing, while MSQE uses those concepts within a broader system of engineering evidence.³

Decision making also requires proportion. A low-impact, reversible documentation change does not need the same analysis as a payment migration or an AI-assisted eligibility decision. The role is not to create maximum process; it is to make a risk-appropriate decision possible.

The Quality Engineer as an Enabler

Quality Engineers create leverage when they improve the team's ability to build and evaluate quality independently. Enablement is the removal of recurring friction or uncertainty through practices, tooling, knowledge, and collaboration.

Examples include:

• a reusable approach for creating safe test data;
• a small library that makes service contracts easier to check;
• review prompts that expose failure and recovery behaviour;
• dashboards and alerts that connect technical signals to customer outcomes;
• pairing that helps developers design more testable interfaces; and
• a risk workshop that gives product and engineering a shared vocabulary for a difficult decision.

Enablement has a measurable result: less dependence on one gatekeeper, faster access to credible evidence, fewer repeated misunderstandings, and better recovery when conditions change. It does not mean that QE only coaches and never tests, codes, investigates, or challenges. It means those activities are selected for their ability to improve the wider engineering system.

The Quality Engineer should be alert to a common trap: creating a central quality framework that only its authors can operate. Reusable tooling needs documentation, support boundaries, ownership, and feedback from its users. Otherwise, a well-intended platform becomes a new bottleneck.

Career Development

Career paths differ by organisation, product, and geography. The following path is a useful example, not a required sequence:

QA Engineer
      ↓
Senior QA Engineer
      ↓
Quality Engineer
      ↓
Senior Quality Engineer
      ↓
Principal Quality Engineer

At early stages, the focus is often on reliable investigation, test design, domain knowledge, communication, and basic automation. A senior QA Engineer usually takes on broader risk assessment, mentoring, strategy contribution, and technical ownership. A Quality Engineer adds lifecycle, systems, delivery, and operational influence. Senior and Principal Quality Engineers tend to create organisation-wide leverage through quality strategy, platforms, standards, coaching, and cross-team technical leadership.

Alternative paths are equally valid. An engineer may deepen into SDET or test architecture; move into platform engineering, DevOps, SRE, security, performance, data quality, or AI Quality Engineering; or move toward engineering management. The right path follows the kinds of problems the engineer wants to solve and the capability the organisation needs.

Promotions should be based on sustained scope and impact, not on abandoning hands-on work. A practitioner who improves a critical testability or observability capability for several teams may demonstrate more Quality Engineering impact than one who merely coordinates more meetings.

Skills Assessment

A self-assessment should reveal a development direction, not rank a person. Use evidence from real work: code reviewed, automation maintained, risks surfaced, incidents investigated, colleagues enabled, and outcomes improved.

Rate each area as emerging, practising, or enabling:

“Emerging” means you understand the concepts and need guided practice. “Practising” means you can apply them independently to a meaningful change. “Enabling” means you can improve the capability of others through standards, tools, coaching, or strategy. No engineer is enabling in every category. The assessment should identify the next meaningful stretch, not create a false skills score.

Building a Personal Learning Roadmap

A useful QA-to-QE roadmap spans 12–24 months and is tied to real engineering work. Certifications can provide structure, but they do not substitute for evidence that you can reason about risk, collaborate on design, build or improve technical capabilities, and learn from production outcomes.

First six months: strengthen foundations

• Choose one programming language used by your team and use it to improve a check, diagnostic script, or test-data utility.
• Learn the service interfaces and data flows behind a critical user journey.
• Participate in requirement refinement and ask for examples, failure conditions, and observable outcomes.
• Read pipeline results, logs, and dashboards with developers or operations colleagues.
• Complete one small improvement that reduces recurring test or diagnostic friction.

Six to twelve months: broaden delivery and systems contribution

• Lead a risk-based test strategy for a change with dependencies or operational consequences.
• Contribute to a design or architecture review using questions about quality attributes, testability, observability, and recovery.
• Improve an automated-check suite, contract, test-data process, or deployment verification signal.
• Join an incident or post-incident review and trace one finding back to a requirement, design, or test decision.
• Pair with a specialist in security, performance, cloud, data, or SRE work.

Twelve to twenty-four months: create leverage

• Coach colleagues on a quality practice and gather feedback on whether it improved their work.
• Build or evolve a shared capability with clear ownership, documentation, and adoption measures.
• Facilitate a cross-functional risk or quality-attribute discussion for a high-consequence change.
• Connect a production signal or recurring support pattern to a measurable product or delivery improvement.
• Develop deeper expertise in one technical area while maintaining broad systems awareness.

Keep a small portfolio of evidence: a before-and-after view of feedback time, a design decision you influenced, a capability you created, an incident finding that changed practice, or a colleague's adoption of a tool. This is more useful for career conversations than a list of courses alone.

Common Misconceptions

“QE Replaces QA”

Quality Engineering builds on QA and testing. Assurance, independent challenge, process controls, exploratory testing, and release evidence remain valuable. QE expands the responsibility from a phase or function to the engineering system that creates and sustains quality.

“QE Means Writing More Automation”

Automation is an important competency, but more checks do not necessarily provide better evidence. QE chooses automation where it improves repeatability, speed, confidence, or learning, and combines it with design, exploratory, operational, and human evidence.

“A QE Must Become a Software Engineer”

Quality Engineers need meaningful software-engineering capability, especially to collaborate, automate, and understand design trade-offs. They do not need to follow an identical career path to a product software engineer or become expert in every implementation area.

“QE Owns All Quality”

Quality is shared across the people who make, release, operate, and improve a system. QE owns its own commitments and may lead quality strategy or enablement, but it cannot accept every risk, make every decision, or replace specialist accountability.

“QE No Longer Performs Testing”

Testing remains a valuable source of evidence. Quality Engineers may perform exploratory, integration, resilience, or acceptance evaluation, particularly where investigation and risk judgement add value. The distinction is that testing is one contribution within a wider practice.

“QE Is Just a New Job Title”

Some organisations relabel roles without changing how work happens. The meaningful change is visible in responsibilities: earlier risk influence, technical contribution, shared evidence, operational learning, and team enablement.

Engineering Perspective

Consider the account-recovery scenario. A Quality Engineer can make a concrete difference without taking ownership of every technical decision.

The Quality Engineer is not the approval authority merely because they assembled the evidence. Their value is that the team has better evidence, clearer limitations, and a safer decision because they helped connect the work.

Industry Perspective

Public sources describe many of the capabilities that Quality Engineers need without prescribing one universal job description. ISO/IEC 25010:2023 supports product-quality requirements, evaluation, and measures for several lifecycle stakeholders.¹ ISO/IEC/IEEE 29119-1:2022 provides common concepts for software testing.³ Together, they support clear quality language but do not define a single organisational role.

DORA's current research describes a core model of capabilities, metrics, and outcomes grounded in its ongoing research programme, and highlights the value of continuous improvement in practitioner contexts.⁴ Google SRE describes monitoring as an engineering activity involving collection, processing, aggregation, and display of real-time system data, and stresses signals that support action.⁵ Microsoft DevOps guidance connects shared workload responsibility with clear roles, decision authority, and continuous learning.²

These sources support an engineering-first conclusion: the Quality Engineer's value is not tool ownership or final inspection. It is the ability to help a team create and use evidence across quality requirements, testing, delivery, operation, and improvement.

Practical Exercise

Quality Engineer Career Assessment

Use the Competency Model to assess your current position. For each area, write one strength, one capability gap, and one piece of evidence from your current work. Be specific: “I can read API logs and explain a failure path” is more useful than “I understand observability.”

Then choose no more than three goals for the next six months:

1. one technical foundation or depth goal;
2. one delivery, systems, or operational-learning goal; and
3. one influence or enablement goal.

For each goal, identify a real team change through which you can practise it, a collaborator who can provide feedback, a constraint you may face, and an observable sign of progress. Review the plan after three months. Adapt it if the work has not created useful evidence or if the team's needs have changed.

Use the Quality Engineer Competency Self-Assessment to record evidence, capability gaps, target levels, next actions, and mentor or manager feedback.

Summary

The Modern Quality Engineer is not defined by a universal title or by the volume of tests they write. They are defined by their ability to connect quality requirements, risk, technical decisions, evidence, and learning across the people and systems that deliver software.

Quality Engineering builds on traditional QA, testing, and automation. It retains the value of investigation and independent challenge while expanding influence into requirements, design, delivery, operation, and improvement. The role needs broad engineering understanding, one or more areas of real technical depth, and professional skills that make evidence useful in a collaborative team.

The Quality Engineer Competency Model is an original MSQE educational framework for organising that development. It supports a practical transition: assess current evidence, choose a small number of meaningful capabilities, practise them in real work, and build leverage for the wider team.

Key Takeaways

• Quality Engineering builds on QA and testing; it does not dismiss their skills or evidence.
• Job titles vary, so responsibilities, decisions, and outcomes are better indicators of a Modern Quality Engineer role.
• A Modern Quality Engineer makes quality requirements, risks, evidence, and learning explicit across delivery and operation.
• Technical breadth enables credible collaboration; technical depth enables concrete engineering contribution and leverage.
• Quality Engineers contribute throughout delivery without replacing product managers, architects, developers, SREs, security specialists, or accountable decision-makers.
• Evidence-based decisions state the risk, evidence, limitations, unknowns, owner, and consequence of acceptance or delay.
• Enablement reduces dependence on a gatekeeper by improving team practices, tools, and feedback paths.
• Career growth is practical and non-linear: build foundations, broaden real delivery contribution, then create reusable leverage.
• The Quality Engineer Competency Model is an original MSQE educational framework, not a standard or universal certification syllabus.

Review Questions

1. Why are responsibilities more informative than job titles when defining a Quality Engineer role?
2. How does Quality Engineering build on traditional QA rather than replace it?
3. What are the four orientations in the MSQE definition of a Modern Quality Engineer?
4. Why does a Quality Engineer need both technical breadth and technical depth?
5. Give three examples of QE contribution that improve a team's capability rather than create a gate.
6. How should a QE participate in a release decision without becoming the sole approver?
7. What limits should a Quality Engineer state when presenting test or pipeline evidence?
8. How can a Quality Engineer collaborate with SRE and security specialists without duplicating their roles?
9. What makes a skills assessment useful for career development?
10. Why is practical evidence of capability more valuable than certification alone?

Interview Questions

1. How would you create a quality strategy for a new customer-critical service?
2. Describe how you influence an architecture decision when you are not the architect.
3. A team has extensive automation but frequent production incidents. What would you investigate first?
4. How would you decide whether an automated check is worth building or retaining?
5. What evidence would you expect before a high-risk release, and how would you communicate its limitations?
6. How do you influence developers and product managers without becoming a project manager or a release bottleneck?
7. Describe how you would turn an escaped defect into a quality-improvement opportunity.
8. How would you balance technical debt, feature delivery, and quality risk in a planning discussion?
9. What technical area would you develop deeply as a Quality Engineer, and how would it create leverage for a team?
10. How would you assess and coach a QA Engineer who wants to transition into Quality Engineering?

Practical Resources

• Build from: Chapter 7: Engineering Culture and DevOps Mindset, where collaborative quality behaviours become visible.
• Use the Quality Engineer Competency Self-Assessment and Case Study 3: From Senior QA Engineer to Quality Engineer to identify an evidence-based development path.
• Continue: Chapter 9: The Modern Software Quality Engineering Framework places individual capability in the larger engineering system.

Further Reading

• International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 25010:2023 — Product quality model.
• International Organization for Standardization, International Electrotechnical Commission, and IEEE. ISO/IEC/IEEE 29119-1:2022 — Software testing: General concepts.
• DORA. Research and reports.
• Google. Monitoring Distributed Systems. In Site Reliability Engineering.
• Microsoft. Architecture strategies for fostering DevOps culture.
• IEEE Computer Society. SWEBOK Guide.
• Forsgren, N., Humble, J., and Kim, G. Accelerate: The Science of Lean Software and DevOps. IT Revolution, 2018.

References

Chapter Checklist

Before moving on, confirm that you can:

• Explain how Quality Engineering builds on QA, testing, and automation.
• Describe the Modern Quality Engineer in terms of responsibilities and contribution rather than title alone.
• Identify your next technical-depth and technical-breadth development goals.
• Explain how QE contributes across delivery without duplicating other engineering roles.
• Apply evidence-based decision-making to a quality risk or release discussion.
• Describe how a Quality Engineer enables teams rather than becoming a bottleneck.
• Use the Quality Engineer Competency Model to create a practical development plan.
• Connect career development to real engineering evidence and team impact.