Back to Blog
On this page2 sections

// career

The QA CV mistakes I see again and again

qa.codesqa.codes · 13 June 2026 · 7 min read
BeginnerJob seekersManual QA
careercvresumejob-search

Most QA CVs fail the same way: a list of tools and a list of duties, with no evidence the person is actually good at testing. Here are the mistakes I see over and over, and what to write instead.

Having read a lot of QA CVs, the pattern is depressingly consistent: they all look the same, they all list the same tools, and almost none of them give a reason to believe this particular tester is any good. A CV's only job is to get you the interview, and it does that by being evidence, not a job description. Here are the recurring mistakes and the fixes — most of which take a rewrite, not a new skill.

The mistakes

A tool list masquerading as skills. "Selenium, Cypress, Postman, JIRA, Jenkins, TestRail." Everyone writes this, so it differentiates no one and proves nothing — listing a tool isn't evidence you used it well. Tools belong on a CV, but as context for what you did with them, not as the headline.

Duties instead of achievements. "Responsible for testing the web application. Wrote test cases. Logged bugs." This describes the role, not your performance in it — it reads identically whether you were excellent or barely adequate. Replace duties with outcomes: what changed because you were there?

No numbers, no impact. "Improved test coverage" is a claim; "raised critical-path automation coverage so release regression dropped from two days to four hours" is evidence. Where you can quantify — bugs caught pre-release, flake reduced, time saved, escapes prevented — do, the way a real case study reads.

Automation-only or manual-only framing in a blur. Either hiding that you do manual work as if it's embarrassing, or claiming heavy automation with nothing to back it. Be honest and specific about the mix and your actual depth — interviewers find the gap fast.

Generic everything. The same CV fired at every role, matching none. A QA role heavy on API testing and one heavy on mobile want different evidence surfaced; one document optimised for neither loses to one tailored for either.

QA CV fixes

  • Lead with achievements and outcomes, not duties — what changed because you were there
  • Quantify impact: bugs caught pre-release, flake reduced, regression time cut, escapes prevented
  • Use tools as context for what you did with them, not as a standalone skills dump
  • Be specific and honest about your manual/automation mix and real depth
  • Tailor to the role — surface the evidence that role actually cares about
  • Show judgement, not just activity — a bug you caught that mattered beats "logged bugs"
  • Cut the generic summary ("detail-oriented QA professional") — it's invisible

The reframe that fixes most of it

Almost every mistake above is the same mistake wearing different clothes: describing the job instead of proving you're good at it. The fix is to read each line and ask "does this give a reason to interview me, or could anyone in my role have written it?" If it's the latter, rewrite it as a specific thing you did and what resulted. "Wrote automated tests" → "built the API regression suite that catches contract breaks before release." Same facts, completely different signal.

Your CV is competing against a stack of near-identical tool-lists. The way to win isn't a longer list — it's evidence of judgement and impact, told specifically. That's also the raw material you'll need for the interview, where you'll be asked to talk through a bug you caught and what your testing actually prevented. Write the CV that proves you can test, not the one that confirms you held the title.

// RELATED QA.CODES RESOURCES


// related

Career·13 June 2026 · 8 min read

What senior QA interviews really test

Senior interviews assess judgement, prioritisation, and influence — not deeper tool trivia. Prep risk-based reasoning, trade-off thinking, and stories of influencing decisions.

careerinterviewsseniorjob-search