Software and technology · Mid level · UK and US conventions noted

QA / test engineer: resume example, explained

This fictional example shows a QA engineer with six years' experience applying for a senior test role: the test strategy she owns comes before the tools she runs, defect metrics are given as trends with the change that moved them, and the regression suite is described as a release gate the team trusts. Four decisions are explained, three weak bullets are rewritten from the evidence behind them, and the editable download lets you replace every detail with your own. Nothing here describes a real person, employer or product.

Illustrative example. An illustrative, invented QA engineer with six years across manual and automated testing at two fictional software companies, applying for a senior QA / test engineer role that owns test strategy for a product team. Every employer, defect figure and release is fictional.

Editable version of this example (.docx)

Ewan Mbatha-Sinclair

QA / Test Engineer · Test strategy, automation (Playwright, pytest), accessibility and regression testing

Glasgow (hybrid) · 07700 900 582 · ewan.ms@example.com

Profile

Test engineer with six years in product teams, currently owning the test strategy for a fictional appointment-scheduling product used by around 900 clinics and salons. Built the automated regression suite that gates every release, runs accessibility checks against WCAG 2.2 AA inside that gate and reports defect trends the team acts on. Looking for a senior role defining quality practice across more than one team.

Experience

QA Engineer (test lead for one product team) — Fictional Scheduling Software Ltd

April 2023 – present · Appointment-scheduling software; one product team of seven engineers and two testers; fortnightly releases.

Own the test strategy for a product used by around 900 clinics and salons, deciding what is covered by unit, API, end-to-end and exploratory testing; the risk-based plan is reviewed with the product manager at the start of every fortnightly release.
Built the end-to-end regression suite in Playwright and TypeScript from 0 to 310 tests, running in under 25 minutes in CI as the release gate; it has caught 14 release-blocking defects before deployment since 2024.
Reduced escaped defects from an average of about six per release to under two by adding contract tests on the booking API and a two-hour exploratory session on every risky change.
Added automated accessibility checks and a manual screen-reader pass against WCAG 2.2 AA to the release gate; 38 accessibility defects were fixed in the first two quarters and new ones are now caught before release.
Report escaped defects, mean time to fix and flaky-test rate in a one-page monthly summary; flaky tests fell from about 8% of runs to under 1% after quarantining and rewriting 22 timing-dependent tests.

Test Analyst, then QA Engineer — a fictional payroll software company

August 2020 – April 2023 · Payroll product with monthly statutory releases; team of 12.

Executed and maintained a 600-case manual regression pack for monthly releases, prioritising by risk so the critical path ran in two days rather than four.
Automated the 120 highest-value cases with pytest and an API client, cutting the manual pack by about a fifth and freeing two days a month for exploratory testing.
Logged and triaged around 40 defects a month with reproducible steps, severity and environment details; developers reopened fewer than one in twenty as 'cannot reproduce'.

Education

BSc (Hons) Software Engineering, Fictional University, 2020
Foundation-level software testing certification (industry scheme), 2021

Skills

Test strategy and risk-based test planning · End-to-end automation: Playwright (TypeScript) · API and contract testing: pytest, schema validation · Accessibility testing: WCAG 2.2 AA, screen readers, automated checks · Exploratory testing and session-based test management · Defect management: reproducible reports, severity triage, metrics · CI pipelines, release gates and test data management · SQL for test data and verification

Why it is written this way

Strategy before tools: the resume says what the applicant decides, not only what he runs

A test engineer who wants a senior role is judged on judgement: what to automate, what to explore, what to leave alone. The profile and the first bullet describe the risk-based plan and who reviews it, so the reader meets a QA engineer who shapes quality rather than one who executes a pack. Tools are named in the bullets where they did a job.

Defect metrics are given as trends with a cause

'Reduced bugs' cannot be verified. Escaped defects per release, flaky-test rate and reopen rate are the measures QA teams actually track, so each appears with a before, an after and the change that produced it. The figures are fictional and modest; a real reader will ask how they were measured, so use ones you can explain.

The release gate is described as a decision the team trusts

A regression suite is only worth what it is allowed to block. Run time, test count and release-blocking defects caught show that the suite is fast enough to run every time and trusted enough to stop a deploy. Accessibility checks sit inside the same gate, which tells an employer they are routine testing, not a one-off audit.

Manual testing years are kept and quantified

Test engineers sometimes hide manual work as if it were embarrassing. The payroll role shows a 600-case pack prioritised by risk, 40 defects a month written up well enough that fewer than one in twenty was reopened, and the first automation step. That is the foundation a hiring manager wants under the automation.

Bullet rewrites, and the evidence behind them

Each rewrite was produced by asking an evidence question and using only the (fictional) answer. No number appears in a rewrite that is not in its evidence.

Before
Responsible for automation testing using Playwright.
Evidence question
How big is the suite, how long does it run, and what has it actually prevented?
Evidence (fictional)
Playwright and TypeScript suite built from 0 to 310 end-to-end tests; runs in under 25 minutes in CI as the release gate; has caught 14 release-blocking defects before deployment since 2024.
After
Built the end-to-end regression suite in Playwright and TypeScript from 0 to 310 tests, running in under 25 minutes in CI as the release gate; it has caught 14 release-blocking defects before deployment since 2024.
Before
Improved software quality and reduced bugs.
Evidence question
Which measure of quality moved, by how much, and what did you change to move it?
Evidence (fictional)
Escaped defects found by customers after release fell from an average of about six per release to under two; the changes were contract tests on the booking API and a two-hour exploratory session on every risky change.
After
Reduced escaped defects from an average of about six per release to under two by adding contract tests on the booking API and a two-hour exploratory session on every risky change.
Before
Performed accessibility testing.
Evidence question
Against which standard, how is it run, how many defects came out, and does it keep happening?
Evidence (fictional)
Automated accessibility checks plus a manual screen-reader pass against WCAG 2.2 AA, added to the release gate; 38 accessibility defects fixed in the first two quarters; new ones now caught before release.
After
Added automated accessibility checks and a manual screen-reader pass against WCAG 2.2 AA to the release gate; 38 accessibility defects were fixed in the first two quarters and new ones are now caught before release.

Try it on your own bullets with the bullet workbench, which asks the same questions and never adds a figure you did not supply.

Transferable skills in this example

Risk-based prioritisation
Evidence: Risk-based test plans reviewed every release; a 600-case pack reordered so the critical path ran in two days.
Where it helps: Product management, release management and audit or compliance roles that must decide what to check first.
Writing reproducible, blame-free reports
Evidence: Around 40 defects a month with steps, severity and environment; fewer than one in twenty reopened.
Where it helps: Technical support, incident analysis and any role that hands problems to engineers.
Measuring a process and changing it
Evidence: Monthly defect metrics; flaky-test rate cut from about 8% to under 1% by rewriting 22 tests.
Where it helps: Operations, continuous improvement and engineering management.
Accessibility advocacy backed by evidence
Evidence: WCAG 2.2 AA checks made part of the release gate; 38 defects fixed in two quarters.
Where it helps: UX research, design systems, public-sector digital teams and accessibility specialist roles.

Occupation notes

Hard requirements

Software testing is unregulated, so no licence or registration applies. The hard requirements are the advert's named automation stack (shown in a suite you built, not a course), domain experience where the employer insists on it (payroll, healthcare, finance) and right to work in the country of hire, checked through the verified employer process at the stage required in that country.
A foundation-level testing certification appears in some adverts as desirable; name it generically if held, with the year, and never let it stand in for a suite that caught something.

Vocabulary that belongs on the page

Test strategy, test plan, risk-based testing
Regression suite, release gate, smoke test
End-to-end (E2E), API, contract and unit tests; the test pyramid
Flaky test, quarantine, deterministic test data
Escaped defect, severity / priority, reopen rate, mean time to fix
Exploratory testing, session-based test management, charter
Accessibility: WCAG 2.2 AA, screen reader, automated checks, manual pass
Shift left, definition of done, acceptance criteria

Pitfalls specific to this occupation

Listing automation frameworks with no suite size, run time or defects caught, so the reader cannot tell a proof of concept from a release gate.
Claiming 'zero defects' or 'improved quality by 50%' with no definition of the measure; QA managers know every product ships with defects and will ask how escaped defects were counted.
Hiding manual and exploratory testing as if automation were the only respectable work; test strategy roles need both.
Describing accessibility as 'ensured compliance' without naming the standard, the method or a defect count.

UK and US differences

UK: UK adverts use 'QA engineer', 'test engineer', 'SDET' and 'test analyst' almost interchangeably; mirror the advert's title in the headline and keep the evidence the same.

US: A US resume for six years' experience is usually one page; keep the metrics and drop the coursework. US adverts often grade the role (QA Engineer II, Senior QA Engineer), so map your scope, owning strategy for a team, to the level rather than to years.

Common questions

How should a QA engineer show defect metrics on a resume without inventing numbers?

Use the measures your team already tracks (escaped defects per release, flaky-test rate, reopen rate), give the before and after, and name the change that moved them. If you do not have the number, describe the change and its effect in words instead.

Does manual testing experience still belong on a test engineer resume?

Yes. Strategy roles need judgement about what to automate and what to explore, and a quantified manual regression history with a strong defect-report record is evidence of exactly that.

Published 6 November 2026 · Every person, employer and figure in this example is fictional. Drafted with AI assistance and checked against Luceria’s editorial standards.