A QA CV gets read by two very different people. The recruiter scans for the tool names in the job ad, and the test lead who interviews you reads every bullet asking one question: does this person actually find bugs, or do they just run scripts someone else wrote? Most tester CVs answer the first reader and lose the second.
This guide covers the parts that are specific to testing work. If you are moving toward building production features, the Software Engineer CV guide is the better fit, and pipelines and on-call work belong to the DevOps and SRE CV.
Pick your path first: manual, automation, or both
Before you touch a single bullet, decide which role you are applying for. A manual or exploratory tester and an automation engineer are hired against different criteria, and a CV that tries to be both usually reads as neither.
For a manual or functional QA role, the hiring manager wants evidence of judgement. They care about how you decide what to test, how you write a bug report a developer can act on without a follow-up chat, and how well you know the product's users.
For an automation or SDET role, the reader expects code. They want to know which language you write tests in, which framework you built on, whether you maintained the suite or only added to it, and how the tests run in the pipeline.
If you do both, lead with the one the job ad leans on. Your headline line under your name should say it plainly: "QA engineer, manual and API testing, fintech" reads very differently from "Test automation engineer, TypeScript and Playwright".
Name your tools, but put them to work
Testers tend to list everything they have ever installed. The CV Skills Section Examples guide covers the layout of that block in general; for QA, the useful move is to group tools by what they do:
- UI automation: for example Selenium, Cypress or Playwright
- API testing: Postman, or a code-based client inside your test framework
- Unit and integration frameworks: JUnit, pytest or similar, depending on the stack
- Test management: whichever case-management tool your team ran
- Defect tracking: a bug tracker such as Jira
Then make sure each important tool appears again inside an experience bullet, attached to a result. "Cypress" in a list tells the reader you have heard of it. "Rebuilt the checkout regression suite in Cypress, cutting the manual regression pass from two days to an afternoon" tells them what you did with it. The figures in examples like this one are illustrative; use your own, and only ones you can explain in an interview.
Be honest about depth. If you wrote three Selenium tests on a side project, that belongs in a projects section, not in the skills block next to the framework you maintained for four years.
Show how you think: strategy, test design, exploratory work
This is the section most tester CVs skip, and it is the one that separates a senior tester from a script runner. Hiring managers want to see that you can look at a feature and decide where the risk is.
A few ways to make that visible:
- Test strategy. Did you write or shape the test approach for a release, a new product or a migration? Say so, and say what you prioritised. "Defined the risk-based test plan for the move to the new payment provider, focusing on refunds and currency edge cases" is specific and believable.
- Test design. Mention the techniques you actually use, such as boundary values, equivalence partitioning, state transitions or pairwise combinations, but only if you can talk through an example. One technique tied to a real feature beats five named in a row.
- Exploratory testing. If you run time-boxed sessions with a charter and notes, describe it. Exploratory work is often where the interesting bugs come from, and many testers undersell it because it does not produce a neat artefact.
The reader is not asking "how many tests did you run". They are asking "would this person have caught the bug that hurt us last quarter".
Defects, coverage and release metrics without the vanity numbers
Numbers help a QA CV, but the usual ones are weak. "Executed 2,000 test cases" says nothing about value, and "found 400 bugs" can mean the product was badly built or that you logged every typo separately.
Better metrics describe impact on the team or the release:
- the share of a critical flow now covered by automated checks, and what that changed (fewer hotfixes, faster sign-off)
- the time a regression pass takes before and after your work
- flaky tests you stabilised
- a severe defect you caught before release, described in one line with the business risk it carried
Then there is the awkward one: bugs that escaped to production. You do not need to list them, but a short, honest line about how you responded to one is a strong signal. "After a pricing defect reached production, added contract tests between the pricing and basket services; no repeat of that class of issue since" shows ownership.
Keep every figure defensible. If you cannot say how you measured it, leave it out.
CI pipelines, shift-left and the move to SDET
Modern QA work sits inside the delivery pipeline, and your CV should show where you fit in it. If your tests run on every pull request, say so. If you set up the parallel runs, the test reports or the quality gate that blocks a merge, that is real engineering and belongs in a bullet.
Shift-left work is worth naming because it changes the role. Reviewing acceptance criteria before development starts, pairing with developers on unit tests, or adding contract tests between services all move testing earlier, and they show you influence quality rather than just measuring it.
Writing the manual-to-SDET transition
Many testers move from manual work to an SDET or automation role, and the CV is where that shift has to be believable. A few practical moves:
- Retitle nothing you did not hold. Keep your real job title, and let the bullets show the growing automation share.
- Put the code first in each recent role: the framework you started, the language, the pipeline it runs in.
- Add a projects line if your employer gave you little automation work. A small, clean public test suite against a demo app is a reasonable stand-in, as long as you describe it accurately.
- Keep the manual strengths. Testers who understand risk and users write better automation, and saying so is a selling point, not a confession.
Domain knowledge and certifications
Domain experience is often what wins a QA interview. Testing payments means knowing about refunds, chargebacks and currency rounding. Healthcare testing brings audit trails and data-privacy rules. If you have worked in a regulated or specialised domain, name it in your headline and in the role bullets, because a hiring manager in that sector reads it as reduced ramp-up time.
Certifications such as ISTQB Foundation, or an advanced or agile-testing level of a similar scheme, can help, mostly at the screening stage and in some markets more than others. They rarely outweigh experience, so a short line is enough. The Certifications on a CV guide covers where to place them; for a tester, the main rule is not to let a certificate sit higher on the page than the work that proves you can test.
If your LinkedIn profile already lists your projects and tools in detail, a tool like Postulit can turn it into a first CV draft, which you can then cut down to the path you picked in the first section.
Your next step
Open your current CV and take the three bullets from your most recent role. For each one, check that it names a tool or technique, a feature or risk area, and a result you could defend in an interview. Rewrite any bullet that only says what you ran. Then reread the headline under your name and make sure it states the path you are applying for, manual, automation or SDET, in plain words.