Quality Engineering

Why it matters

When quality is checked only at the end, feedback arrives late: a misunderstanding from week one is found in week four, after more work was built on it. Teams that release often, as in the lessons on DevOps and continuous delivery, cannot wait for a manual test phase each time, and some failures appear only in production, where users find them first if nobody is watching.

For you as a tester, effort moves from re-running scripted checks by hand to risk, test design, testability, automation and production signals. Success is not how many defects you found at the end, but how few escape and how fast the team learns when one does.

Traditional QA and quality engineering

In many organisations "QA" grew up as a separate team that tests a finished build before release; as the lesson on QA and QC explained, most of that work is quality control. Quality engineering keeps that work but changes when it happens and who takes part, and it treats quality as an engineering property that is designed in, like performance or security. Side by side:

• When: after development is "done" (traditional QA), versus from refinement to production (quality engineering).
• Who: a separate test team, versus the whole team, with quality engineers enabling and coaching.
• Main output: bug reports and test execution reports, versus automated pipeline checks, testable designs and production signals, plus bug reports.
• Feedback: days or weeks after the code was written, versus minutes after each change and again from production.
• Guiding question: "Did we find the defects?" versus "How do we make defects hard to introduce and quick to detect?"

Building quality in: testability, automation, observability

Three engineering properties carry most of the work; quality engineering plans all three together, for every feature, before the code is written.

• Testability. ISO/IEC 25010 lists testability under maintainability: how effectively and efficiently test criteria can be set and tests performed against them. Ask whether you can control it (reach an expired session through an API, set the clock), observe it (clear responses, log events, stable test ids) and isolate it (replace a payment provider with a test double).
• Automation. Checks that must hold on every change run in the pipeline, at the lowest level that can catch the defect, so a regression shows up minutes after the change that caused it. Test code is software: without reviews and a flaky-test policy, nobody trusts it.
• Observability. Understanding what a running system does from the signals it emits, usually logs, metrics and traces. For monitoring, watch the four golden signals from the shift-left and shift-right lesson: latency, traffic, errors and saturation. Good signals turn "checkout failed" into "the payment call timed out for this order".

Try it: Mock API Response Generator Try it: API Health Checker

Worked example: delivery slots with quality built in

This is the delivery-slot story from the exercise in the shift-left and shift-right lesson: customers pick a two-hour delivery slot at checkout; a slot can be booked until 3 hours before it starts and takes at most 20 orders. In refinement, the quality engineer, a developer and the product owner go through the three properties:

• Testability: the service reads the time from a clock that tests can set; a test-only endpoint fills a slot with 19 bookings; the slot picker gets stable test ids.
• Automation: unit tests for the cut-off at 3:00:01, 3:00:00 and 2:59:59 before the start (agreed: closed at exactly 3:00:00); API tests for the 20th booking (accepted) and the 21st (rejected with SLOT_FULL); one UI test for the happy path.
• Observability: each rejected booking logs a structured event with its reason; a dashboard shows rejections per reason; an alert fires if bookings drop to zero during opening hours.
• Still manual: exploring two customers taking the last place at the same moment, and slot times in Arabic.
• After release, the dashboard shows SLOT_FULL rejections for slots that still list free places. The log event below carries the slot and order ids, so the tester reproduces the case within the hour: cancelled orders were still counted.

{
  "time": "2026-10-01T18:42:07Z",
  "level": "warn",
  "event": "slot_booking_rejected",
  "reason": "SLOT_FULL",
  "slot_id": "SLOT-7781",
  "booked_count": 20,
  "capacity": 20,
  "order_id": "ORD-58213",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736"
}

Try it: Acceptance Criteria Generator

What a quality engineer does

Titles vary — quality engineer, QA engineer, SDET — but a quality engineer is a tester first: risk analysis, test design and exploratory testing stay at the core. The ISTQB Foundation syllabus describes the whole-team approach, in which anyone with the necessary knowledge and skills can do any task and everyone is responsible for quality; the quality engineer makes that practical.

That does not mean writing all the tests alone, which only moves the bottleneck to one desk. A typical week includes:

• Asking testability, risk and "how will we know?" questions in refinement.
• Planning which checks run at unit, API and UI level, and what is left for exploration.
• Writing and reviewing automated tests, and helping developers write better ones.
• Keeping the pipeline trustworthy: meaningful quality gates, no ignored flaky tests.
• Agreeing with developers and operations which signals to watch after a release.
• Exploratory testing, defect reports with evidence, and learning from escaped defects.

Try it: Risk-Based Test Generator Try it: Regression Scenario Generator

Frequently asked questions

References

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelISO/IEC · 2023The product quality model: functional suitability, performance efficiency, compatibility, interaction capability, reliability, security, maintainability and flexibility.
• Monitoring Distributed Systems — Site Reliability Engineering (Rob Ewaschuk)Google / O'Reilly Media · 2016Google's SRE guidance on monitoring: black-box versus white-box monitoring and the four golden signals — latency, traffic, errors and saturation.