A QA hiring manager reads your resume the way you would read a defect report, looking for specifics that can be checked. That means the tools you have actually run, numbers with a denominator attached, and evidence you can write a bug somebody else can reproduce. The 16 examples below cover the disciplines this job splits into, including four routes in for people with no paid testing job yet.
540k+ resumes created
Each template below is a real QA resume laid out in that format, grouped by the kind of testing it was written for. The automation and API layouts put the framework, the pipeline and the runtime numbers where an engineering manager looks; the entry-level ones give self-directed testing work its own dated section instead of burying it under a hobbies heading. Pick one, then replace the tools, the domain and the numbers with your own.
































Open the example closest to the testing you do, swap in your tools, your domain and your own numbers, and add the link to your repository. A page a QA lead can verify beats a page that only asserts.
Build my resumeA QA resume is read the way you would read a defect report: the reader is looking for specifics they can check. Name the tools you have actually run, attach a denominator to every number, and give them evidence you can write a bug somebody else can reproduce. Vague quality language is the one thing this audience is trained to distrust.
Most first QA jobs are manual, and manual testing is not a lesser skill. What loses interviews is the mismatch: a resume that reads like a tester who occasionally scripts will be screened out of automation roles, and a resume claiming automation on the strength of one course gets found out in the technical screen instead.
QA candidates are hired on the quality of their defect writing more than on anything else on the page, and the interview will test it directly. So show it, the way a designer shows a portfolio.
Everybody says quantify. Almost nobody says which numbers survive scrutiny. These do, because a QA lead can picture where they came from.
A QA posting screens on exact tool names, and the spelling matters more here than in most fields. Matching the posting's wording is not gaming the system; it is answering the question that was asked.
ISTQB Foundation Level is the credential QA postings name most often, and it is a knowledge exam rather than a practical one. That tells you exactly where it helps and where it stops.
One page is the norm below roughly ten years of experience, and two is the practical maximum for a lead. Beyond that you are asking a busy reader to work for it.
Five things. A summary of two to three sentences naming your testing type, your domain and your strongest number. A skills block grouped by languages, frameworks, tools, CI and testing types, listing only what you have actually run. Experience bullets that each carry one checkable number, such as the size of a suite you own, escaped defects before and after, or suite runtime before and after. Certifications, with ISTQB Foundation if you hold it. And a link to something real, a repository with a test framework in it or a written sample bug report, because defect writing is the skill this job is hired on. One page below roughly ten years of experience.
Do testing work that leaves a trace, then format it as a job rather than as a hobby. File defects on an open-source project and give the number accepted. Write a test plan for a real public application and put it in a repository. Build a small Playwright or Cypress suite and link it. Complete crowdtesting cycles and report how many and at what approval rate. Each of those gets a title, a date range and two to four bullets with numbers, exactly like paid work. Then put education and projects above work history, add ISTQB Foundation if you have it, and keep the tools you are still learning clearly marked as such rather than claimed.
Name them specifically, and spell them the way the posting does. Frameworks: Selenium, Playwright, Cypress, Appium, REST Assured, JMeter, k6, PyTest, Jest. Test management and tracking: Jira, TestRail, Zephyr, Xray, qTest. CI and infrastructure: Jenkins, GitHub Actions, GitLab CI, Docker, BrowserStack. Languages that match your work: Java, JavaScript or TypeScript, Python, SQL. Then the testing types themselves: functional, regression, exploratory, API, contract, performance, accessibility, user acceptance. Group them by category so a reader finds what they came for in one pass, and list only what appears in a bullet somewhere else on the page.
It depends on where you are. Early in your career, or moving into QA from another field, it is worth having and worth listing: it is verifiable proof you know the vocabulary and the standard techniques, and some employers filter on it, particularly larger organizations in finance, health care and government. Several years in, with frameworks you built and testers you have coached, your outcomes carry the page and the Foundation certificate adds very little. The Advanced levels are worth listing when your actual work matches them. Requirements and exam details change, so check the current position with the certification board rather than with a blog post.
One page below roughly ten years of experience, and two pages as the practical maximum for a lead or principal with results that fill the space. Every example on this page fits a single page, including the ones carrying four roles and a certifications block. If you are running over, cut the oldest role to two bullets, drop the tools you no longer use, and delete any bullet that has neither a number nor a named tool in it. A hiring manager screening a stack of QA resumes gives each one a couple of minutes, so a tight page beats a padded two.
Lead with whatever the posting is actually hiring for, and be honest about the gap. Most first QA jobs are manual, and manual testing is not a lesser skill: test design, exploratory testing and risk analysis are what stop defects reaching production. If you are applying for automation roles, the page has to read like an engineer who specializes in quality, with a language, a framework, a pipeline and code you can show. If you have some automation but not much, say exactly what, as in "wrote 30 Cypress tests for the booking flow". That is credible. Claiming automation on the strength of one course does not fail at the resume screen, it fails in the technical interview, which is worse.
Open the example closest to the testing you do, swap in your tools, your domain and your own numbers, and add the link to your repository. A page a QA lead can verify beats a page that only asserts.