How to write a CV for a QA engineer role

What a hiring manager scans for first

Someone hiring a QA engineer is not reading your CV top to bottom on the first pass. They're looking for three things, in roughly this order: what you tested (the domain — fintech, healthcare, e-commerce, embedded, games), how you tested it (manual, automated, or both, and which layer — unit, API, UI, end-to-end), and what you tested it with (the specific tools named in their stack). If those three things aren't visible in the first third of the page, the CV gets set aside, because the reader has a stack of them and a job advert that named specific tools for a reason.

This is why "detail-oriented team player with strong communication skills" at the top of a QA CV is dead space. It tells the reader nothing they can't assume, and it pushes the useful information — Selenium, Playwright, Postman, whatever it is — further down the page where it might get missed on a skim.

Put your automation stack and testing scope in the first few lines, either as a short summary or as a skills line directly under your name. Not a skills cloud with forty tools in alphabetical order — the handful you've actually used in production, with enough specificity that someone reading it knows immediately whether you overlap with their stack.

Qualifications and certifications: what they actually signal

QA is not a licensed profession — there's no equivalent of a bar exam or a nursing registration. Nobody is checking a register before you can call yourself a QA engineer. That means certifications here function differently than in regulated fields: they're a signal of formal grounding, not a legal requirement, and hiring managers vary a lot in how much weight they give them.

The ISTQB Foundation Level (and the higher Advanced and Expert levels, if you have them) is the certification most likely to be recognised on sight by a QA hiring manager, because it's the closest thing the field has to a shared vocabulary — test levels, test types, defect life cycle, the terminology used in test plans. It won't get you an interview on its own, but leaving it off if you have it is a mistake: some applicant tracking systems and some hiring managers do filter on it.

Beyond ISTQB, what matters more is tool-specific and cloud-specific credentials that map onto the job advert directly: AWS or Azure certifications if the role touches cloud infrastructure testing, a Certified Selenium Professional or similar if automation is central, security testing credentials like OSCP or CEH if the role has a security-testing component (increasingly common in QA adverts that ask for penetration-adjacent skills). List these near your name or in a short "certifications" line, not buried at the bottom under education — a hiring manager scanning for a specific credential named in the job advert will look near the top first.

A computer science or software engineering degree helps but is not treated as a gate the way it might be for some engineering disciplines — plenty of working QA engineers moved in from other technical or even non-technical backgrounds, and CVs that show a clear testing track record tend to outweigh a missing or unrelated degree. If your degree is unrelated to software, don't apologise for it or explain it away — let the experience section do the talking.

How to evidence your testing experience

This is where most QA CVs go wrong, and it's the same mistake in every case: listing responsibilities instead of testing outcomes. "Responsible for testing the checkout module" tells the reader nothing about what you actually did or what changed because of it.

What a QA hiring manager wants to see, for each role, is some combination of:

• What you tested and at what level — unit, integration, API, UI, end-to-end, performance, security, accessibility. Naming the level tells the reader where you sit in the testing pyramid, which is a real distinction in this field and affects what a role actually needs.
• What you found and what happened to it. Not a defect count on its own (a high bug count can mean thorough testing or a badly built feature — it doesn't read as unambiguously positive), but the shape of the work: severity classifications you used, how defects were triaged, whether you wrote the reproduction steps that got a fix shipped faster.
• What you automated, and the before-and-after. "Reduced regression cycle from three days of manual execution to a two-hour automated suite" is concrete and checkable in an interview, which is exactly why it lands better than "improved testing efficiency."
• Coverage, where you can state it honestly. Test coverage percentages are commonly quoted on QA CVs, but they're a proxy for thoroughness, not a proof of it — a hiring manager who has done this job will ask what the coverage tool measured and whether it was line, branch, or requirement coverage. If you quote a number, be ready to say what it measured.
• Your position in the release process. Did you own sign-off for a release, or execute test cases someone else wrote? Did you write the test plan, or follow one? This is one of the clearest signals of seniority in QA and it's routinely left implicit rather than stated.

Write test cases and bug reports the way you'd write them for a real ticket: specific, reproducible, with the outcome stated. A hiring manager who has read thousands of vague bug tickets will notice a CV bullet point that reads like one.

Tools, frameworks and vocabulary that belong on this CV

Generic "proficient in testing tools" is invisible. Name the actual stack, because the tool names are doing real filtering work, both for a human skimming the page and for any keyword-matching in an applicant tracking system.

Automation frameworks and tools: Selenium, Playwright, Cypress, Appium (for mobile), TestNG, JUnit, PyTest — and which language you paired them with, since "Selenium" alone doesn't tell a reader whether you wrote it in Java, Python, or C#.

API and service-layer testing: Postman, REST Assured, SoapUI — name these separately from UI automation, because API testing and UI testing are different skills and a job advert that specifies one is telling you which they need.

CI/CD and pipeline integration: Jenkins, GitHub Actions, GitLab CI, CircleCI. Stating that your automated suite ran as part of a pipeline, rather than being triggered manually, signals a more mature testing practice than a standalone script run by hand.

Defect and test management: JIRA (and specifically whether you used Xray or Zephyr alongside it), TestRail, qTest. These are worth naming because different QA teams standardise on different ones, and familiarity with the specific tool in the job advert removes onboarding friction the hiring manager is thinking about.

Performance and load testing: JMeter, Gatling, k6 — worth a separate line if you have it, since it's a distinct skill set from functional testing and often what separates a mid-level QA engineer from a senior one.

Accessibility testing: axe, WAVE, or manual WCAG conformance testing — increasingly asked for and rarely listed, which makes it worth including if you've genuinely done it.

Version control and environment vocabulary: Git, Docker, staging versus production environments, feature flags. QA engineers who can speak to how they tested across environments, not just what they tested, read as more senior.

What gets left out, and shouldn't

A few things QA engineers routinely omit, not out of dishonesty but because they don't think to mention them:

The scale of what you tested. Number of test cases maintained, size of the regression suite, number of environments or browser/device combinations covered. These numbers are concrete and give a hiring manager a sense of the operation's size without needing to ask.

Whether you worked in an Agile team and what your role was in the sprint cycle — writing acceptance criteria, testing within the sprint versus after, participation in sprint planning or retrospectives. QA's involvement in Agile ceremonies varies a lot between companies and is worth stating rather than assuming.

Cross-functional work with developers. Whether you paired with developers on test-driven development, reviewed pull requests, or wrote tests that ran as part of the developer's own workflow rather than a separate QA pass. This distinction — QA as a gate at the end versus QA embedded in development — is one hiring managers actively screen for, and it's rarely stated plainly.

Any exploratory testing you've done, as distinct from scripted test case execution. It's a real and valued skill in this field and it doesn't show up in an automated test count, so it has to be stated directly or it's invisible.

What to do next

Pull the job advert next to your CV and check that the specific tools, testing levels, and certifications it names appear on your CV in the same words, near the top. Rewrite your three most recent roles as testing outcomes, not responsibilities — what you tested, what you found, what you automated, and what changed as a result. Cut the summary paragraph that could describe any engineer and replace it with your actual stack and domain.

If you're sending out CVs faster than you can tailor them to what each advert specifically asks for, that's usually where the silence comes from — not from the quality of the work behind the CV. jobmarket.pro reads each advert in full, matches it against one profile it can't invent experience into, and prepares the application from that.