Test automation CVs often lead with the number of tests written, which is the one metric nobody in the industry trusts. Two thousand flaky tests are a liability; three hundred reliable ones that block a bad release are an asset. Reviewers know this, and read past the count looking for signs you know it too.
What they want instead is the shape of your test strategy: what you automate at which level, how long the suite takes, how often it fails for reasons unrelated to the code, and what got through to production anyway. The last of those - escaped defects - is the honest measure of the job.
This example is written for a QA engineer with five years of experience who has moved a team from manual regression to a maintained automated suite.
QA automation engineer with five years across fintech and e-commerce. Replaced a two-day manual regression pass with an 11-minute Playwright suite running on every pull request, and brought flake rate below 1%. Comfortable owning release sign-off and coaching developers to write their own tests.
•Replaced a two-day manual regression pass with 140 Playwright journeys running in 11 minutes on every pull request, moving releases from fortnightly to twice a week.
•Brought suite flake rate from 12% to under 1% by removing fixed waits, isolating test data per worker and quarantining the four worst offenders while they were rewritten.
•Introduced Pact contract tests between the web client and three services, catching two breaking schema changes before they reached the shared environment.
•Set up k6 load profiles for the payment endpoint and identified a connection-pool limit that would have failed at three times current peak traffic.
•Run exploratory testing charters before each release and coach two developers a quarter through writing their own integration tests.
•Owned functional and regression testing for the checkout and returns journeys across web and Android.
•Built the first automated smoke suite in Cypress, which cut post-deployment verification from 90 minutes to 7.
•Reduced escaped defects on the checkout journey from an average of five a quarter to one by introducing risk-based test planning with the product owner.
Cypress · JavaScript · Postman · Jira
Quality Initiatives
Test data service
Lead
•Internal service that provisions isolated, realistic test accounts on demand, replacing a shared fixture database that caused most cross-test interference.
•Cut environment-related test failures by around 80%.
Education
B.E. Computer EngineeringAugust 2015 – May 2019
Savitribai Phule Pune University · Pune, India
First Class
QA / Automation Engineer example on the Technical layout. All details are fictional and shown for demonstration only.
What recruiters expect
Before writing anything, it helps to know what the person reading is checking for. In this field that is usually a short, specific list:
Suite runtime and flake rate, because both determine whether developers trust the tests.
A stated testing pyramid or trophy, and where you draw the line between unit, integration and end-to-end.
API and contract testing, not just browser automation.
Integration into CI with a blocking gate, rather than a suite that runs nightly and is ignored.
Manual and exploratory testing skill, which remains valuable and is often quietly the differentiator.
Recommended CV structure
This is the running order the example uses. It is a starting point rather than a rule, but the order reflects what tends to be read first in this profession.
Profile — Three or four lines positioning you for the role.
Technical Skills — Grouped skills, for example "Languages" and "Tooling".
Professional Experience — Paid roles, in reverse chronological order.
Quality Initiatives — Work you built, with outcomes and the stack used.
Certifications — Completed certifications with the issuing body.
Education — Degrees, diplomas and school-leaving qualifications.
Languages — Spoken languages with CEFR levels.
Sections worth adding
Training — ISTQB module training is worth listing where the full certificate is pending.
Skills worth including
Grouped rather than listed in one block. Grouping makes a long list readable and shows that you can tell the difference between the things you use daily and the things you have touched.
GitHub Actions · Jenkins · Test data management · Risk-based testing · Exploratory charters
Beyond the technical list: Bug reporting that developers can act on, Facilitating three amigos sessions, Release sign-off, Coaching developers to write tests. These belong inside your experience bullets, demonstrated, rather than in a list of adjectives.
Example professional summary
Three or four lines, positioned for the role rather than describing your personality. Two versions you can adapt:
QA automation engineer with five years across fintech and e-commerce. Replaced a two-day manual regression pass with an 11-minute Playwright suite running on every pull request, and brought flake rate below 1%. Comfortable owning release sign-off and coaching developers to write their own tests.
Quality engineer focused on making tests worth trusting. Experience with Playwright, Pact contract testing and k6 load testing, and a preference for pushing checks as low down the stack as they will go.
Writing your experience
The difference between a CV that gets a call and one that does not is almost always in the bullet points. Each pair below shows a real rewrite of the kind of line that appears on most CVs in this field.
Weak
Automated regression tests using Playwright.
Stronger
Replaced a two-day manual regression pass with 140 Playwright journeys running in 11 minutes on every pull request, which moved release cadence from fortnightly to twice a week.
Contrasts the old process with the new one and names the business outcome.
Weak
Reduced flaky tests.
Stronger
Brought suite flake rate from 12% to under 1% by removing fixed waits, isolating test data per worker and quarantining the four worst offenders while they were rewritten.
Gives the metric that determines whether anyone trusts the suite, plus three specific techniques.
Weak
Tested APIs.
Stronger
Introduced Pact contract tests between the web client and three services, which caught two breaking schema changes before they reached the shared environment.
Shows a level of testing above browser automation and the defects it actually prevented.
Taken from the example
The sample CV for this profession is fully written. A few sections from it, so you can see the level of specificity that works:
Experience
Senior QA Automation Engineer, Bluestone Payments
Replaced a two-day manual regression pass with 140 Playwright journeys running in 11 minutes on every pull request, moving releases from fortnightly to twice a week.
Brought suite flake rate from 12% to under 1% by removing fixed waits, isolating test data per worker and quarantining the four worst offenders while they were rewritten.
Introduced Pact contract tests between the web client and three services, catching two breaking schema changes before they reached the shared environment.
Set up k6 load profiles for the payment endpoint and identified a connection-pool limit that would have failed at three times current peak traffic.
Projects
Test data service — Internal service that provisions isolated, realistic test accounts on demand, replacing a shared fixture database that caused most cross-test interference.
Education
B.E. Computer Engineering, Savitribai Phule Pune University — First Class
Certifications and registration
ISTQB Certified Tester Foundation Level — ISTQB
Common mistakes
Counting tests
"Wrote 1,200 automated tests" invites the question of how many are still passing. Give runtime and reliability instead.
End-to-end everything
A CV that only mentions browser automation suggests an inverted pyramid. Show that you push checks down to the API and unit level.
Hiding manual testing
Exploratory testing finds the defects automation was never written for. Presenting yourself as automation-only narrows your options unnecessarily.
No link to release outcomes
The point of the role is fewer bad releases. If your CV never mentions defects reaching production, it never mentions the job.
ATS considerations
Applicant tracking systems behave differently by sector, and generic advice is often wrong for a given field. These points are specific to qa / automation engineer applications:
Include "test automation" and "QA" as separate phrases; adverts split between the two vocabularies.
Name the automation framework precisely. "Playwright" and "Cypress" are not interchangeable to a filter.
Spell out ISTQB in full once: "ISTQB Certified Tester Foundation Level".
Mention "manual testing" or "exploratory testing" explicitly if you do it - many roles still require both.
The Minimal ATS layout is built for this, and the ATS guide covers what parsers do to a file in more detail.
Guides that go deeper
This page applies general CV advice to one field. The full treatment of each part is here:
How to Write a Software Developer CV — What technical reviewers look for, why the stack list is not enough, and how to write about work you cannot show.
How to Describe Work Experience — The difference between listing duties and demonstrating impact, and a repeatable way to rewrite any weak bullet point.
How to List Skills on a CV — Group them, be specific, and cut anything you would not want to be interviewed on for ten minutes.
Questions about qa / automation engineer CVs
Is ISTQB certification worth it?
It is widely asked for in agencies, consultancies and larger enterprises, and rarely asked for in product companies. Foundation Level is inexpensive and removes a filter; higher levels matter less than demonstrated automation work.
Should I list manual testing?
Yes. A large share of QA roles are still hybrid, and exploratory skill is genuinely hard to replace. Present it as a discipline, not as what you did before automation.
How do I show impact when the metric is bugs that did not happen?
Use escaped defects, hotfix count, release frequency or time spent on regression. All four are measurable and all four improve when the job is done well.
Do I need to be able to code?
For automation roles, yes - at the level of writing maintainable test code and reading application code. TypeScript or Python are the most common expectations.