A QA résumé that survives ATS screening

You applied to 40 QA roles and heard back from two. The résumé looks good on your screen: two columns, a skills chart, a header with your photo. Then the company's software reads it and gets your job title as a blank field and your skills as an image.

Most large employers filter applications with an applicant tracking system, or ATS: software that parses your file into fields and lets a recruiter search and sort. If it cannot read your file, a human never sees it.

The fix is not tricks. It is a plain layout, the right words, and bullets that show impact with numbers.

Short version

One column, no tables, no text boxes, no images. Those break parsers.
Send a .docx or a text-based PDF, never a scan or an exported design file.
Match the job advert's exact wording for tools and skills.
Every bullet needs a number: time, count, percentage, or money.
Write for the recruiter who spends 30 seconds on it, not for a design award.

What breaks a résumé parser

An ATS reads your file and tries to fill in fields: name, title, dates, employer, skills. These things stop it.

Do not use	Why it breaks	Use instead
Two-column layouts	Text is read left to right across both columns and comes out scrambled	One column, top to bottom
Tables for skills or dates	Cells are merged or dropped	Plain lines with commas
Headers and footers	Many parsers ignore this area entirely	Put contact details in the body
Skill rating bars or charts	They are images with no text	Write the level in words, or leave it out
Icons for phone and email	The label is lost, so the value has no field	Plain text labels
Uncommon section names	"My Journey" does not map to "Experience"	Experience, Skills, Education, Certifications
PDF exported from a design tool	Text can be outlined into shapes	Export from a word processor, or send `.docx`

Quick self-test: open your PDF, select all, copy, and paste into a plain text editor. What you see is roughly what the ATS sees. If the order is wrong or words are missing, fix the layout.

The structure that works

Keep it to this order. Two pages maximum, one page if you have under three years of experience.

Name and contact. Name, city and country, phone, email, LinkedIn URL, GitHub or portfolio URL. No photo, no date of birth.
Title line. The exact title of the job you want, such as "QA Engineer" or "Senior QA Automation Engineer". Not "Passionate quality advocate".
Summary. Three lines. Years of experience, main domain, main tools, one measurable result.
Skills. Grouped in plain text lines.
Experience. Reverse date order. Company, title, dates as Jan 2023 – Present, then 3 to 5 bullets.
Education and certifications.

A usable summary looks like this:

QA Engineer with 5 years testing fintech web and mobile products. Playwright, Postman, SQL, Jira, CI with GitHub Actions. Cut production defect escapes by 41% in 2025 by adding API-level regression checks to the release pipeline.

That paragraph contains the job title, the domain, six searchable tools, and one number. It does the work of half a page.

Keywords screeners actually filter on

Recruiters search the ATS by keyword. If the advert says "Cypress" and your résumé says "JS end-to-end testing tools", you do not appear in the results.

Three rules:

Copy the advert's exact word. If it says "test automation", do not only write "automated testing". Use both forms once each.
Write the tool name in full and short. "Continuous integration (CI)" catches searches for either.
Spell tool names the official way. Playwright, Cypress, Selenium WebDriver, Postman, JMeter, Jira, TestRail, Xray, Charles Proxy, BrowserStack, GitHub Actions, Jenkins.

Terms worth including when they are genuinely true of you:

Test types: functional testing, regression testing, exploratory testing, API testing, accessibility testing, performance testing, cross-browser testing, mobile testing.
Design techniques: boundary value analysis, equivalence partitioning, risk-based testing.
Process: agile, Scrum, sprint planning, CI/CD, shift-left testing, defect triage, root cause analysis.
Technical: SQL, REST, JSON, Git, Linux, Docker, Chrome DevTools.

Never list a tool you cannot discuss for two minutes. Keyword stuffing gets you into the interview and then ends it. Hidden white text is worse: most systems strip it, and recruiters who spot it reject on the spot.

Rewriting your bullets

This is where most QA résumés lose. Duties describe a role that anyone could hold. Results describe you.

The pattern: action + scope + result. Start with a verb, say how big it was, end with the number.

Before: Responsible for testing the web application. After: Owned testing for a checkout flow used by 12,000 daily users across Chrome, Safari, and Edge.

Before: Wrote test cases for new features. After: Built a 180-case regression suite for payments, cutting release-day testing from 2 days to 4 hours.

Before: Reported bugs in Jira. After: Filed 300+ defects with reproduction steps and console evidence, reducing "cannot reproduce" responses from 18% to 4%.

Before: Worked with developers and product managers. After: Ran triage twice a week with 3 developers and the product owner, agreeing severity so critical fixes shipped within one sprint.

Before: Did automation testing using Selenium. After: Automated 45 regression tests in Selenium WebDriver and Java, running them in Jenkins on every merge and catching 6 release blockers in the first quarter.

Before: Improved the QA process. After: Introduced a required bug report template, which cut average time from report to first developer comment from 9 hours to 2.

Notice that every "after" bullet still contains the keyword from the "before" version. You are adding evidence, not removing searchable terms.

Finding numbers when you think you have none

Most QA work is measurable. You have probably just never counted it.

Open your tracker. Filter tickets by your name and a date range. That gives you defects filed and verified.
Count your test assets. Cases written, suites owned, tests automated, browsers or devices covered.
Time a task before and after a change you made. Regression run time, environment setup time, release checklist time.
Ask a developer. "How long did it take you to start on my tickets before and after we changed the template?" Their estimate is fair evidence.
Use scope when you cannot use improvement. Users, transactions, countries, team size, release frequency. "Tested a release shipped every two weeks to 40,000 users" is a real number.
Round honestly. "300+" is fine. Inventing "reduced bugs by 87%" is not, because you will be asked how it was measured.

If a number is genuinely an estimate, say so in the interview. "Roughly, based on our sprint reports" is a credible answer.

The last checks before you send

File name: Sara-Ahmed-QA-Engineer.pdf. Not resume_final_v3.pdf.
Dates in a consistent format everywhere, month and year.
No gaps left unexplained. A one-line note is enough.
Read it aloud once. Anything you would not say to a person, cut.
Tailor the title line and the top three skills to each advert. That takes five minutes and matters more than a full rewrite.

A plain, well-worded résumé from a real QA engineer beats a designed one every time in this pipeline, because only one of them makes it to the person who is hiring.

Frequently asked questions

Is a PDF or a Word file safer?

Both work if the PDF is text-based and exported from a word processor. If the advert names a format, follow it. When you are unsure, .docx parses most reliably.

Should I include a photo?

No. It adds nothing for the parser, and in several countries recruiters are asked to discard applications with photos to avoid bias.

How long should a QA résumé be?

One page under three years of experience, two pages after that. A third page is only justified for long consulting histories, and even then a projects section is better.

Do small companies use an ATS?

Many do, through their job board. Even without one, a plain layout is easier for a person to skim in 30 seconds, so you lose nothing.

Should I list every tool I have touched?

No. List what you can discuss confidently, grouped by type. A short honest list reads as more senior than 30 logos.