| What the role owns | Automated checks and the systems that make them believable: the test framework, the suite that runs on every pull request, the test data and the environments it runs against, the triage of every red build, and the judgement about what gets tested where. In 2026 the title usually sits inside a product engineering team rather than a separate QA department, and the output is a trustworthy release signal rather than a count of test cases. At larger employers a second variant sits on a platform or developer productivity team, where the product is the pipeline itself: runners, parallelisation, device clouds, flake detection, test reporting. |
|---|---|
| Licence or certification | None required. No licence, registration or board exam governs software testing in the United States, and no certification functions as a hiring gate at product companies. ISTQB Certified Tester Foundation Level is the only credential with real currency, and its currency is geographic: it is frequently a stated requirement in parts of Europe, in India, and in outsourced or government contracting work, and close to neutral at US and UK product companies where a public repository carries more weight. Tricentis Tosca certification matters in SAP and large enterprise estates. One wrinkle worth knowing: the word engineer is a protected title under provincial engineering acts in Canada, so postings there sometimes avoid it, which is a naming rule rather than a qualification you need. Regulated domains add domain knowledge rather than a personal licence: medical device software work expects IEC 62304 and software validation practice, avionics expects DO-178C, pharmaceutical systems expect computer system validation under GxP, and defence work needs a clearance an employer sponsors. |
| Technical baseline employers expect in 2026 | One language you can actually program in, not just script: TypeScript or JavaScript, Python, Java, or C# covers nearly the whole market. One web automation framework, with Playwright now the default for new work and Selenium or WebDriver still dominant in enterprise Java and C# estates. API testing without a GUI, meaning requests and pytest, REST Assured, Karate or supertest rather than clicking in Postman. Git, and a CI system you have configured yourself rather than inherited: GitHub Actions, GitLab CI, Jenkins or Buildkite. SQL good enough to set up and verify state. Reading logs, traces and a stack trace from the service under test. Docker, and ideally containerised dependencies for integration tests. Mobile roles add Appium, Espresso or XCUITest plus a device cloud. |
| Titles, ladder and where the jobs are | The same work is advertised as QA Automation Engineer, SDET, Software Engineer in Test, Test Automation Engineer, Quality Engineer, and at the infrastructure end Test Infrastructure Engineer or Developer Productivity Engineer. Which title you accept matters for pay, because SDET and Software Engineer in Test usually sit on the software engineering ladder while QA Analyst and QA Engineer often sit on a separate and lower band at the same employer. Manual-only testing roles have contracted sharply, and you can check that for yourself in an afternoon: count the postings in your market that ask for no code at all against those that ask for a framework. Separate QA departments are still normal in banking, insurance, telecom, enterprise software, payments, games, medical devices, automotive and aerospace, and largely gone from product companies, which embed one or two quality engineers per team instead. The newest requisitions sit around AI features, sometimes titled AI Quality Engineer or Evaluations Engineer. |
| Typical hiring process | Recruiter screen (20-30 min, often blunt about whether you write code daily), hiring manager screen (45-60 min, usually the real filter and usually run by the engineering manager who owns the product team or by a quality engineering lead), a coding stage that is either a live 60-90 minute exercise writing automated tests against a supplied application or API or a take-home of similar scope, a test design and strategy round (45-60 min), a debugging or triage round built on a flaky test, a red build or a log bundle, and a cross-functional round about a release you did not want to ship. Prepare on the assumption that test design is the deciding round and the coding round is a floor you either clear or do not. Two to six weeks end to end. For remote roles the take-home is often the entire technical stage. |
| Pay | Do not trust a band from any article, including this one, because the same work is paid on two different ladders. Check the sources. BLS OES code 15-1253 covers Software Quality Assurance Analysts and Testers and publishes the median plus the 10th through 90th percentiles by metropolitan area; OES code 15-1252 covers software developers and is the band that SDET and Software Engineer in Test roles at product companies are usually paid from, which is why the title on the offer letter is worth negotiating. Department of Labor foreign labor certification disclosure data gives exact employer-filed base salaries by employer, job title and worksite, with the limitation that only employers who sponsor visas appear in it. Posting ranges are mandatory in a growing list of states including Colorado, California, Washington, New York and Illinois, so read live postings in your market and check which states currently require it. levels.fyi shows level shape at large employers, self-reported and skewed high. |
| Time to get there | From manual QA with domain knowledge already in place, a realistic transition is six to twelve months of deliberate work: one language to genuine fluency, one framework, CI you configured, and a suite you built and measured at your current employer. From a software engineering role the technical move is quick and the gap is risk thinking rather than code. From no technical background, plan on a year or more, because the market filters hard on whether you can program and a bootcamp certificate does not answer that question; a working repository with a README that explains what you chose not to test does. |
| The single thing that gets you rejected | Describing tools instead of decisions. A candidate who lists Selenium, Playwright, Cypress, Postman, JMeter, Jenkins and TestNG and then cannot say what they chose not to automate, or why one check lives at the API level rather than the UI, fails the design round regardless of how long the list is. The fix is not more tools. It is one feature you can walk through end to end: the risks, the level you put each check at, the oracle you asserted against, the data you needed, and the defect that escaped anyway. |
What the job actually is in 2026, and the four places it lives
A QA automation engineer owns the evidence that a release is safe. Not the test count, not the coverage number, the evidence. That means an automated suite, the data and environments it runs against, the pipeline that runs it, and the triage of every failure it produces. If the suite is slow, flaky or shallow, nobody trusts it, engineers start merging past red builds, and the role quietly stops mattering. Most of the craft is in keeping that from happening.
The shape of the job changed before AI touched it. Through the 2010s many employers ran a separate QA department that received a build and tested it. That model has largely gone from product companies, replaced by one or two quality engineers embedded in a product team, with developers writing their own unit and integration tests and the quality engineer owning strategy, the end-to-end and API layers, the pipeline, and the hard question of what the team is not checking. Manual-only testing roles contracted hard, and the roles that survived assume you can program. If you are reading this because your manual QA job feels precarious, that read is correct, and the move is into code and into strategy rather than into more test cases.
Four variants hire differently and it is worth knowing which requisition you are looking at. Embedded quality engineer: one product team, you work the way the developers work, your interview will look like a trimmed software engineering loop with a test design round bolted on. Test platform or developer productivity engineer: your users are engineers, your product is the pipeline, and the interview goes deep on parallelisation, runners, caching, flake detection and cost. Regulated or validation testing: medical devices, avionics, pharmaceutical systems, automotive safety, where traceability from requirement to test evidence is the deliverable and the documentation is not overhead, it is the product. Specialist domains: games, embedded and hardware in the loop, telecom, payments, where the hard part is the test rig rather than the assertion.
Read the posting for which one it is. A requisition that talks about release trains, traceability matrices and signed test evidence is validation work, and your Playwright repository is not the main thing they want to see. A requisition that talks about build times and developer experience is a platform role, and your story about a flaky suite you fixed is the strongest thing you have. The same resume lands differently across those two, and tailoring here costs ten minutes and changes the outcome.
- Embedded quality engineer: one product team, trimmed engineering loop plus a test design round. The most common shape at product companies.
- Test platform or developer productivity: your users are engineers. Expect depth on CI runners, parallelisation, caching, flake detection and cost per build.
- Regulated and validation testing: traceability from requirement to evidence is the deliverable. IEC 62304, DO-178C and GxP validation practice matter more than framework fashion.
- Specialist domains: games, embedded, hardware in the loop, telecom, payments. The rig and the oracle are the hard parts, not the test code.
- Check the title on the offer: SDET and Software Engineer in Test usually sit on the engineering pay ladder, QA Analyst and QA Engineer often do not.
Why test strategy became the hiring filter
Until recently, being able to write a reliable automated test was itself a filter. Plenty of people who called themselves automation engineers could not get a suite to pass twice in a row, so demonstrating that you could was enough to separate you. That filter has dissolved. A model handed a ticket and a page can produce a plausible Playwright spec in a minute, and codegen plus an assistant turns a manual click-through into a draft test faster than a person can write the selectors. Authoring is no longer the bottleneck, so it is no longer the filter.
What remains hard is everything that requires knowing the system and the business. Three things in particular, and all three show up in interviews now.
The first is the oracle problem, which is simply the problem of knowing what correct looks like. A test without a credible oracle is theatre. If the displayed order total is what you assert against, and the displayed total is computed by the same buggy code path that charges the card, your test passes while customers get charged wrong. The strong answer names the authoritative source of truth and asserts against it, which is often not the thing on screen: the amount on the payment intent, the row in the ledger, the event on the queue, the value the downstream service received. Nothing in the current tooling generation picks the oracle for you, because picking it requires knowing which part of the system is allowed to be wrong.
The second is level selection. Every check can live in several places, and where you put it decides how fast it runs, how often it lies to you, and whether it tells you where the problem is. The old test pyramid is a useful default and a weak interview answer on its own, because the real reasoning is about feedback speed and failure localisation versus realism. A rule that holds up under questioning: push a check as low as it can go while still exercising the thing that can actually break, and keep the end-to-end layer small enough that you are willing to block a release on it.
The third is deciding what not to test. This is the single most undervalued thing a candidate can demonstrate. Suites fail because they grow without a deletion policy, not because they were badly written. Being able to say, out loud, that you deleted forty end-to-end tests covering error message wording and replaced them with four API tests and one journey, and that the escaped defect rate did not move, is a senior answer at any level of the ladder.
Here is a worked example, because abstraction is useless here. A checkout page gains a coupon code field. A candidate who answers "I would write end-to-end tests for valid and invalid codes" has said nothing. A candidate who answers in the shape below is hired.
- Risk first: this is the money path. The failures that hurt are a discount applied twice, a single-use code redeemed twice, and a displayed total that differs from the amount charged.
- Unit level: percentage versus fixed amount, rounding to the cent, stacking rules, expired code, minimum basket threshold, each supported currency. Cheap, exhaustive, fast.
- API level: the apply endpoint returns recomputed totals, rejects an unknown code, rejects an already-applied code, rejects an ineligible basket. Double submit is idempotent. Another user's single-use code cannot be redeemed. Code guessing is rate limited, which is a security test, not a nicety.
- Integration level with a real database and a containerised dependency: two concurrent redemptions of a single-use code decrement the count once. This is where the valuable bug lives and it cannot be found through the UI.
- End-to-end: two tests. One happy path where a valid code applies and the amount on the payment intent matches the displayed total. One rejection path proving the error surfaces at all.
- Deliberately not automated at the UI: every invalid-code message variant, visual placement, every currency. Covered lower down, or covered by one visual snapshot.
- Test data: codes created through the API with a unique suffix per run so parallel workers do not collide, and torn down after. Seeded fixtures shared across suites are how this suite becomes flaky in three months.
- Production watch: an alert on redemption count exceeding the limit, because the concurrency case is the one you will never fully close in test.
Suite health: the numbers that get you hired
Almost every QA automation resume is qualitative. The ones that get callbacks have numbers, and the numbers are not coverage percentages. Coverage is the weakest metric in testing: it tells you which lines executed, not whether anything was checked, and a generated suite can push it up while asserting almost nothing. Interviewers who have run a QA function know this, and quoting line coverage as an achievement signals that you have not.
These are the numbers that mean something. Flake rate: the proportion of pipeline runs where a test failed for a reason unrelated to the change, however you choose to define it, and defining it explicitly is half the credit. Time to signal: minutes from push to a definitive pass or fail on a pull request, at p50 and p90, because the p90 is the one that makes engineers stop waiting and start ignoring. False blocking rate: the share of red builds that were not product defects, which is the number that explains why your team trusts or distrusts the suite. Escaped defect analysis: production bugs per release that an existing test level should have caught, classified by which level missed them. Suite wall-clock time and the cost in CI minutes, which is the number that gets a platform role interested.
Escaped defect analysis deserves its own paragraph because it is the most senior-sounding artefact a QA candidate can bring, it costs about an hour a month to maintain, and almost nobody does it. The method is one row per production bug in a spreadsheet: the date, what it was, which test level should have caught it, and why it did not. After two or three months you have a pattern, and the pattern tells you where to invest instead of guessing. Typical findings are mundane and actionable: most escapes were data-shape problems that no layer checked, or permission cases that only existed in end-to-end tests that were quarantined, or regressions in a service nobody owned a contract test for. Being able to say in an interview that eleven defects escaped over four months, that seven of them were authorisation cases, that you had no API-level authorisation suite, and that you built one and the next quarter had one escape of that kind, ends the question of whether you think about quality strategically.
If your current employer tracks none of this, that is an opportunity rather than an obstacle, because the data is already sitting in your CI history. On GitHub Actions, gh run list with a high limit and the json flag for conclusion, createdAt, headSha and name, plus the rerun records, gives you a flake rate and a time to signal in an afternoon; Jenkins exposes the same history through its API, GitLab through its pipelines endpoint. Your issue tracker gives you the escape list. Two weekends of work converts a qualitative resume into one with evidence, and the work itself is exactly what the interview will ask you about.
On flake, hold a position. Retries are an anaesthetic. A test that passes on the second attempt is telling you something, and usually it is one of eight things: shared mutable state between tests, a wait on a condition replaced by a sleep, time dependence such as timezone or midnight rollover or a token expiring mid-run, data collisions from hardcoded fixtures, an environment that changed under the run, resource contention in CI where a starved runner blows a five second timeout, a slow third-party sandbox, or a genuine intermittent race condition in the product. The last one is a real bug and it is the most valuable thing your suite will ever find, which is the reason to treat every flake as a bug report until proven otherwise. A defensible policy, and a good interview answer: a flaky test is quarantined with a named owner and an expiry date, fixed or deleted by the expiry, and a quarantine list that only grows is a failure you report upward.
- Flake rate, with your definition stated. The definition matters as much as the number.
- Time to signal at p50 and p90, in minutes from push to definitive result.
- False blocking rate: the share of red builds that were not product defects.
- Escaped defects per release, classified by which test level should have caught each one.
- Suite wall-clock time and CI cost per run. The lever that gets platform roles interested.
- Never lead with line coverage. It measures execution, not checking, and experienced interviewers read it as naivety.
The resume: what belongs and what is ignored
QA automation resumes fail in a consistent way. They open with a tool inventory, list responsibilities rather than outcomes, and describe volume of test cases as though volume were the point. A hiring manager skims for three things: can this person program, did they own a pipeline, and do they think in risk. Make those three answerable in the first fifteen seconds.
Match the title in the posting at the top of the document, because QA automation work is advertised under at least eight names and both human screeners and keyword filters look for the one they wrote. Then three lines of summary that name the stack you actually used, the scale you worked at, and two numbers. Then a link to a public repository if you have one, at the top where it will be clicked, not in a footer.
For each role, write scope, ownership, evidence, in that order. Scope: what the product was, which platforms, what release cadence, how many engineers you supported. Ownership: the framework, the pipeline, the environments, the test data, whichever of those were genuinely yours. Evidence: numbers from the previous section. Implementation detail goes below that, and a tool list goes at the bottom where ATS parsers will still find it.
Some rewrites, since this is easier shown than described. "Wrote and maintained over 1,200 automated test cases using Selenium and TestNG" becomes "Owned the regression suite for a four-team checkout product: cut it from 1,200 UI tests to 180 UI plus 600 API tests, taking pull request signal from 52 minutes to 11 and flake rate from roughly one run in three to under one in twenty." "Performed manual and automated testing in an Agile environment" becomes "Embedded in a six-engineer payments team: owned the API and end-to-end layers, triaged every red build, and ran a monthly escaped-defect review that redirected the suite toward authorisation cases." "Experience with Postman for API testing" becomes "Built the API suite in pytest against a containerised stack, including authorisation matrices and idempotency checks on the payment endpoints."
The numbers in those rewrites are the shape, not your numbers. Put nothing on the resume you cannot reconstruct in the room: where the figure came from, how you defined it, and what you changed to move it. An interviewer who hears a confident flake rate will ask how you counted it, and a candidate who cannot answer has turned their strongest line into their worst moment. If you do not have the numbers yet, go and get them from your CI history before you apply.
What gets ignored or actively counts against you: test case counts; the phrase "manual and automation testing", which reads to a product company as mostly manual; "worked in Agile/Scrum environment"; soft skill adjectives; line coverage percentages; a certification block above the experience section when applying to US or UK product companies; and long tool lists containing things you touched once. If you have used eleven tools and are fluent in three, say which three, because an interviewer will probe the weakest item on the list and a thin answer there contaminates the rest.
- Mirror the posting's job title at the top. The same work is advertised under at least eight names.
- Three lines of summary: stack, scale, two numbers. Public repository link at the top, not the footer.
- Per role: scope, then ownership, then evidence with numbers. Implementation detail below. Tool list at the bottom for parsers.
- Use only numbers you can reconstruct on request: the source, your definition, and the change that moved it.
- Name the domain. Payments, health records, ads, trading and games each carry risk knowledge that transfers and that employers pay for.
- Cut: test case counts, line coverage, "manual and automation testing", Agile boilerplate, tools you used once.
- Mark fluency honestly. An interviewer probes the weakest item on your list, and a thin answer there casts doubt on the strong ones.
Credentials, degrees, and the honest answer on ISTQB
Nothing licenses this work. There is no board, no exam and no registration for software testing, which makes the credential question purely about signalling, and the signal depends heavily on where you are applying. The one naming caveat: engineer is a protected title under provincial engineering acts in Canada, so employers there sometimes advertise the same job as a specialist or developer, which changes the search string rather than the requirements.
ISTQB Foundation Level is the only certification with real market presence. The honest position: in parts of continental Europe, in India, and in outsourced, consultancy and government contracting work, it appears as a stated requirement often enough that not having it costs you applications. At US and UK product companies it is close to neutral, and it becomes mildly negative when it occupies the top of the resume in place of evidence, because it reads as someone who studied vocabulary rather than built something. The Advanced Level certificates follow the same pattern more strongly. If your market asks for it, take it; it is a modest cost and a weekend of study. Do not expect it to substitute for a repository.
Other credentials worth knowing: Tricentis Tosca certification carries weight in SAP and large enterprise automation estates where Tosca is the standard. Cloud certifications from AWS or Azure help for platform-leaning roles. Selenium and Playwright vendor badges are noise. A security certification is relevant only if you are moving toward security testing specifically.
Degrees: not required, and plenty of strong people in this role came through support, manual QA, or a different industry entirely. A computer science degree is still a hard filter at a handful of large employers for any engineering title, and it matters more if you are aiming at SDET roles on the engineering ladder at those specific companies. Regulated domains care about domain knowledge rather than degrees: medical device software hiring looks for IEC 62304 and validation experience, avionics for DO-178C, pharmaceutical systems for computer system validation practice under GxP, automotive for functional safety process familiarity. Those are learned on the job or through employer training, and they make you harder to replace than any framework does. Defence and some government work is gated on a clearance, which an employer sponsors and you cannot buy.
What actually replaces a credential is a public artefact, and there is a specific shape that works. A repository that tests a real public API or an open source application, containing: a README that states the risk model and explains which checks you put at which level and what you deliberately left out; an API suite that is the bulk of the tests; two or three end-to-end tests and a note on why only those; a CI workflow that runs on a schedule, not just on push, so the history shows real flake data; a report artefact; honest handling of test data and parallel execution; and one documented bug you actually found, with a reproduction. Interviewers read the README first and sometimes only the README. It is the closest thing this field has to a portfolio piece, it takes a few weekends, and it answers the two questions a certificate cannot: can you program, and do you think in risk.
- No licence exists for software testing. Every credential here is a signal, not a gate.
- ISTQB Foundation: materially useful in parts of Europe, India, consultancy and government contracting. Close to neutral at US and UK product companies.
- Tricentis Tosca certification matters in SAP and enterprise estates. Vendor badges for Selenium or Playwright do not.
- Regulated domains value IEC 62304, DO-178C, GxP validation practice and functional safety process knowledge, learned on the job.
- The artefact that beats a certificate: a repository with a README explaining your level choices and what you chose not to test.
How the loop runs in 2026-27, round by round
The loop for a QA automation engineer is shorter than a senior software engineering loop and longer than a frontline hire. Two to six weeks is typical. Who screens you matters: at a product company it is usually the engineering manager who owns the team, sometimes with a staff engineer, and there may be no QA specialist in the process at all, which changes what lands. At an enterprise with a real QA function it is a quality engineering lead or test manager, who will go deeper on process, traceability and coverage governance. Work out which you are talking to in the first call, because the same story needs different emphasis.
Recruiter screen, 20 to 30 minutes. Expect a blunt question about whether you write code every day, because the job title spans two populations and recruiters have learned to separate them early. Have a one-sentence answer naming your language and framework and the last thing you built in it. Location, visa and salary expectation get settled here.
Hiring manager screen, 45 to 60 minutes, and usually the real filter. This is where candidates are lost by talking about tools. The manager is listening for whether you talk about risk, whether you have owned a pipeline, and whether you can disagree with a developer without becoming an obstacle. Bring one feature you can walk through end to end, one suite-health before and after with numbers, and one escaped defect with its cause. Ask what the team currently ships on: who decides a release is safe today, and what breaks most often. The answer tells you whether the role is real or whether you are being hired to absorb a mess nobody has authority to fix.
The coding stage, 60 to 90 minutes live or a take-home of similar scope. Live versions typically supply a small application or API and ask you to automate a scenario, or ask plain programming questions: string and collection manipulation, a small class design, calling an API and parsing the response, and frequently SQL. They are not grading on whether you can produce tests, which everyone can now do. They are grading on structure, naming, how you wait, what you assert, whether you set up and tear down data, and above all whether you asked what matters before writing anything. Ask that question out loud. For take-homes, cap your time, and write a README that states what you built, what you deliberately skipped and why, and what you would do with another day. That note wins take-homes more often than extra tests do.
The test design round, 45 to 60 minutes. Prepare for this as the round that decides it. You get a feature, a diff, a screenshot or a user story, and you are asked what you would test. The pattern that scores is: restate the risk in business terms, enumerate what can go wrong, assign each check to a level and say why, name the oracle, name the test data problem, say what you are not automating, and finish with what you would monitor in production because no suite closes everything. Think out loud and ask questions; a candidate who asks who else consumes this data, or whether this endpoint is idempotent, has already passed.
The debugging and triage round. Formats vary: a flaky test to diagnose, a failing CI run with logs, a bug hunt in a sample application inside a time box, or a conversation about the worst flake you ever chased. What they are testing is whether you debug into the system or only at the surface. Say what you would look at and in what order, name the hypotheses, and say how you would distinguish them. If the round is a bug hunt, the grading is usually on the quality of the bug reports rather than the count: exact steps, environment, expected versus actual, severity reasoning, and one sentence on the likely mechanism.
Infrastructure or system design, for mid-level and above. Design the test and release strategy for a service, a mobile app or a multi-tenant platform. Cover environments, parallelisation, how you keep data isolated, contract testing between services, browser and device matrix with a justification for its size, where the suite runs and how long it may take, and cost. Have an opinion on shared test environments versus ephemeral per-branch stacks, and on mocking versus containerised dependencies, with the tradeoff named rather than a preference asserted.
Cross-functional and behavioural. Expect a version of: tell me about a release you did not want to ship. They are checking whether you can hold a position with evidence and then accept a decision that went against you without sulking, and equally whether you have ever blocked anything at all. Both failure modes are real. The department of no gets routed around; the person who never objects adds no value in the room where the call is made.
One practical note on take-homes and AI. Use assistants the way you would at work, and be ready to say which parts you generated and what you changed, because you will be asked, and the follow-up is usually to modify your own submission live. Candidates get caught not for using a model but for not understanding the code it produced.
- Recruiter screen: have a one-sentence answer to "do you code daily" that names a language, a framework and a thing you built.
- Hiring manager screen: the real filter. Lead with risk and numbers, not tools. Ask what the team ships on today.
- Coding round: graded on structure, waits, assertions, data lifecycle, and whether you asked what matters first.
- Take-home: cap your time and write a README stating what you skipped and why. That note wins more often than extra tests.
- Test design round: restate risk, assign checks to levels, name the oracle, name the data problem, say what you skip, end on production monitoring.
- Debugging round: order your hypotheses out loud. Debug into the service, not at the UI.
- Behavioural: one story where you blocked a release with evidence, and one where you were overruled and it was fine.
The two rounds to prepare hardest for, in detail
If you prepare for two rounds, prepare for test design and for debugging. The coding round is a floor you either clear or do not. These two are where offers are won.
For test design, build three worked features before you interview and rehearse them out loud until the structure is automatic. Pick ones with different risk shapes: a money path (a refund, a discount, a payout), a permissions path (sharing a document, role changes, tenant isolation), and a data path (a bulk import, a report, a sync between systems). For each, be able to produce the full chain: risks in business language, failure modes, level assignment with reasons, the oracle, the data setup and teardown, the parallel execution hazard, what you leave manual or leave unchecked, and the production signal that covers the residue.
The permissions example is worth spelling out because it is where real defects hide and where most candidates are thin. A document gains sharing. The risks are not about buttons. They are: a user seeing a document they were never granted; a revoked user retaining access through a cached token or a stale link; a tenant boundary crossed by an identifier that is guessable; a share link surviving the document's deletion; an export path that bypasses the permission check that the read path enforces. Almost none of that belongs in the UI layer. It belongs in an API-level authorisation matrix, generated across roles and resource states, run on every pull request, plus one integration test for revocation timing and one end-to-end test proving the share dialog is wired to the real endpoint. Say that in a design round and you are ahead of most of the field, because you have shown that you test the system rather than the screen.
For the debugging round, have a taxonomy ready rather than improvising. Given a test that passes on retry, the hypotheses in rough order of frequency: shared mutable state or test ordering; a sleep standing in for a wait on a condition, or a wait on an element that re-renders and leaves a stale handle; time dependence, which includes timezone, daylight saving, midnight and month-end rollovers, and auth tokens expiring mid-run; test data collisions from hardcoded values or fixtures another suite mutates; environment drift, where a dependency deployed mid-run or a feature flag flipped or a seeded database diverged; resource contention in CI, where a starved runner makes a short timeout fail and the same test passes locally forever; a slow or rate-limited third-party sandbox; and finally a genuine intermittent race condition in the product.
Say the last one out loud in the interview. The reason to investigate every flake rather than retry it is that the product race condition is the highest-value defect a suite can surface, and a retry policy is precisely the mechanism that hides it. Then give the method: reproduce in a loop with the same seed and worker count, bisect by running the test alone and then with its neighbours, compare the trace or video from the failing run against a passing one, check the service logs for the same request identifier rather than reasoning from the UI, and look at timing rather than the assertion that happened to fail. Playwright's trace viewer and a correlated request identifier between test and server logs are the two instruments that resolve most of these quickly, and naming them is concrete in a way that "I would investigate thoroughly" is not.
Bring one real story for each round, and make one of them a failure. The most useful thing you can offer is a defect that escaped on your watch: what it was, which level should have caught it, why it did not, and what you changed afterwards. Interviewers trust a candidate who volunteers that more than one who has only successes, because the second candidate either has not been in the role long or is not paying attention.
- Rehearse three features out loud before interviewing: a money path, a permissions path, a data path.
- Permissions belong in an API-level authorisation matrix across roles and resource states, not in UI tests. Include revocation timing and an export path that may bypass the read check.
- Memorise the flake taxonomy: ordering and shared state, sleeps and stale handles, time, data collisions, environment drift, CI resource contention, third-party slowness, real product race conditions.
- Name the instruments that resolve flake: trace viewer, correlated request identifiers between test and server logs, loop reproduction with fixed seed and worker count, bisecting by neighbour tests.
- Volunteer one escaped defect with its cause and the change you made. It builds more trust than any success story.
Getting in: four entry paths and how the search runs
From manual QA, which is the most common starting point and currently the most pressured one. Your advantage is real and often undersold: you know the product, you know where it breaks, and you have defect instinct that a developer moving sideways does not have. Your gap is code, and it is a genuine gap that a short course does not close. The plan that works takes six to twelve months and happens at your current employer. Pick one language and go past tutorial depth. Automate the five highest-risk journeys from your existing regression sheet, at the API level wherever possible. Get it running in CI on a schedule. Measure flake rate and time to signal, publish both to your team, and fix them. Then run an escaped defect review for a quarter. At the end you do not have a certificate, you have the exact set of stories the interview asks for, and you have them from a real system with real constraints, which is better than any portfolio project.
From software engineering. Technically this is easy and you should not pretend otherwise in the interview. The gap is that you have been trained to make things work and this job is about how they fail, under which combinations, for which users, with which data. Interviewers screen hard for engineers who see testing as a lesser craft, and they detect it in how you talk about manual testers and about exploratory work. The fast way to close the gap is to pick up escaped defect analysis on your current team and to spend time with whoever does exploratory testing, because the thing you lack is a catalogue of how systems actually betray users.
From support, implementation or operations. You have domain knowledge, customer empathy and a feel for severity, which are worth a lot and are hard to teach. You need the same code work as the manual QA path plus deliberate exposure to how the system is built: read the code, sit in design reviews, learn to read logs and traces. Your natural edge in an interview is the severity conversation, where you can explain which bugs actually hurt customers and which ones only look bad.
From no technical background. This is the hardest route and honesty serves you better than encouragement. The market filters on whether you can program and a bootcamp certificate does not answer that. Plan on a year. Build the public repository described earlier, with a README that argues its level choices. Contribute tests to an open source project, which gives you review comments from strangers, a public history, and something to talk about that is not self-assessed. Look at contract and QA-adjacent roles in enterprise or regulated settings where structured testing work still exists at entry level, and at internal moves inside any employer that has engineering. The internal move is by far the highest-probability path and it is systematically underused.
Running the search. Search all the titles, not one: QA Automation Engineer, SDET, Software Engineer in Test, Test Automation Engineer, Quality Engineer, Automation Engineer, Test Infrastructure Engineer, Developer Productivity Engineer, and at the AI end AI Quality Engineer or Evaluations Engineer. Volume applications work less well here than targeting, because the postings are heterogeneous: half want a programmer embedded in a product team and half want a process-literate tester in a regulated estate, and a resume that suits one reads as wrong to the other. Where the function is still institutionally strong, meaning banking, insurance, telecom, enterprise software, payments, games, medical devices, automotive and aerospace, there are more seats and slower processes. At product companies there are fewer seats, faster processes, and a higher bar on code.
Two final notes on the 2026 market. First, the roles growing fastest are adjacent rather than identical: evaluating AI features, and owning the pipeline as a platform product. Both reward a tester's instinct and both tend to pay on the engineering ladder. If you are already in QA, that adjacency is the most valuable door currently open to you. Second, when a posting describes a brand new quality function with no existing suite, ask in the screen who currently decides a release is safe and what authority this role has. A quality engineer hired without the authority to block anything spends a year writing tests nobody acts on, and that is a career year you cannot get back.
- From manual QA: six to twelve months, done at your current employer. One language, the top five journeys automated at the API level, CI on a schedule, flake and signal measured and published, then a quarter of escaped defect reviews.
- From software engineering: the code is not the gap. Learn how systems fail and never talk down about exploratory testing, which interviewers screen for explicitly.
- From support or operations: lead with severity judgement and domain knowledge, and close the code gap the same way the manual QA path does.
- From no technical background: a year, a public repository with an argued README, open source test contributions, and an internal move wherever one is available.
- Search eight titles, not one, and tailor per variant. Product company postings and regulated estate postings reward opposite resumes.
- Ask who currently decides a release is safe, and whether this role can block one. A quality hire without that authority writes tests nobody acts on.
What a QA automation engineer must know about AI in 2026-27
Start with what did not change, because overclaiming disruption here will cost you an interview. The core of this job is intact. Deciding what correct looks like for a feature is still a human judgement about the business. Choosing which level a check belongs at is still a reasoning problem about feedback speed and failure localisation. Diagnosing why a suite is flaky still requires knowing the system. Owning test data and environments is still unglamorous, still hard, and still where most suites rot. Negotiating with a product manager about whether a known defect ships is still a conversation between people. A good quality engineer from 2023 is still a good one, and anyone telling you the role has been automated away has not tried to get a non-trivial suite green.
What did change is the cost of authoring, and it changed completely. Assistants and agent modes will draft a Playwright spec, a pytest API suite, a REST Assured class or a page object layer from a ticket, a diff, a recorded session or a screenshot, in minutes. Codegen plus a model turns a manual click-through into a working draft faster than a person can find the selectors. The hiring consequence is direct: "I can write Selenium in Java" has stopped being a differentiator, because the scarce input is no longer typing. That is why interviews have moved onto design, triage and judgement, and why a take-home that asks you to write tests is now graded almost entirely on your choices and structure rather than on whether you produced output.
The most immediately marketable new skill is reading a generated suite and saying what it does not catch. A few employers now hand candidates exactly that exercise, and it is a cheap round to add, so expect more of it. The failure modes are consistent and worth memorising. Tests derived from the implementation assert the implementation, so a model shown a buggy function will encode the bug as the specification and produce a green suite that locks it in; this is the tautology problem and it is the biggest risk in machine-authored testing. Over-mocking is second: generated unit tests often stub every collaborator so thoroughly that the test cannot fail for any reason a user would experience. Brittle locators are third, with long CSS chains and positional selectors instead of roles and test identifiers. Then coverage inflation, where line coverage climbs convincingly while risk coverage and escaped defects do not move. And finally the systematic gaps, which are always the same categories: negative cases, boundaries, concurrency, authorisation, money and rounding, and anything requiring knowledge of what the business actually promises. Those come from the domain, not from the code, which is precisely why a human is still in the loop.
On self-healing locators and autonomous exploration tools, have a position rather than an allergy or an enthusiasm. Healing selectors genuinely reduce a real class of maintenance churn, and pretending otherwise reads as defensive. The problem is that a silently repaired selector can accept a real regression: if a button's label changed, or it moved to a different section, or two now match, the heal may paper over the defect your test existed to catch. The defensible position, and a good interview answer, is that a heal should produce a reviewable diff rather than a green build. Autonomous exploration agents are useful for what they are good at: discovering states, finding crashes and unhandled errors, sweeping for accessibility violations, and generating candidate journeys you had not thought of. They are weak at oracles, because they do not know the business rule. Use them to find states, not to certify correctness.
Testing non-deterministic systems is the growth area and the place where a tester's instinct transfers best. If your employer has shipped anything backed by a model, the old assertions mostly stop working: exact matching still holds for a classification label or a schema field, and is meaningless for generated prose, a passing run does not guarantee the next one, and "it worked when I tried it" is not evidence. What replaces it is an evaluation harness, and the components are learnable. A labelled set of cases held in version control, sized and sampled deliberately rather than scraped together. Assertions on aggregate pass rate against a stated threshold rather than per-case equality, with enough cases that the number means something. Pairwise comparison against the previous prompt or model version to catch regressions that an absolute threshold hides. Property-based checks that need no model to evaluate: is the JSON schema valid, does the cited document actually contain the claim, is any personal data present in the output, was a refusal appropriate, did the tool call have well-formed arguments. A model-as-judge where you need subjective grading, validated against human labels with an agreement rate you can quote, because an unvalidated judge is a random number generator with good manners. Model and prompt versions pinned in CI so a result is attributable to a change. Cost per request and time to first token as assertions, since both are user-visible and both regress silently. And an adversarial suite: prompt injection carried in retrieved content, jailbreak attempts, attempts to extract context or system instructions.
One operational point that employers now ask about directly: test data and model use. Synthetic data generation is a genuine win for this role, because realistic fixtures have always been a bottleneck and a model is good at producing them. The trap is feeding production records into a third-party model to do it. Know your employer's boundary, and in an interview name the boundary you worked within rather than claiming you never used the tools. The answer that lands is specific: synthetic data generated from a schema and a set of rules, with production data never leaving its own environment, and a documented check that generated fixtures contain no real identifiers.
What to show for all of this. One before and after on suite health that you can attribute to a decision you made. One instance where you reviewed generated tests and found what was missing, with the category named. One evaluation harness if you have touched an AI feature at all, even a small one, because the pool of candidates who have built a real eval set is still small next to the number of postings asking for it. And opinions specific enough to be wrong: on retries, on healing locators, on where mocking stops being useful, on whether a judge needs validating. Generic enthusiasm about AI is now a weak answer in this role, for the same reason a generic answer about test levels is weak. It shows no judgement about a specific system.
Reviewing machine-generated tests for what they fail to catch
Generating tests is cheap and the volume reaching repositories has risen sharply, so review capacity is the constraint. Generated suites systematically assert implementation rather than intent, over-mock, and miss negative, boundary, concurrency, authorisation and money cases. Some employers now test this directly by handing you a generated suite.
Show it: Walk through a specific review: the suite, what it appeared to cover, the category it missed, and what you added. Name the tautology problem explicitly, meaning a test derived from the code asserting the code and passing against a live bug. If you can show escaped defects falling after you changed review practice, lead with that number.
Choosing the oracle, not just the assertion
The hardest part of a test is knowing what correct is, and no tool decides this for you. Asserting against the same surface that computed the wrong answer is the most common way a green suite coexists with a broken product, and it is exactly what a model will do by default because the screen is what it can see.
Show it: Take a money or data example and name the authoritative source you asserted against rather than the visible one: the payment intent amount, the ledger row, the event on the queue, the value the downstream service received. Explain why the displayed value was not trustworthy.
Building an evaluation harness for a non-deterministic feature
Any product feature backed by a model cannot be tested with exact-match assertions on generated text, and most employers shipping one have no real evaluation discipline yet. This is where the new requisitions are, sometimes under titles like AI Quality Engineer or Evaluations Engineer, and they usually pay on the engineering ladder.
Show it: Describe the harness concretely: how many labelled cases and how you chose them, the pass threshold and why that number, pairwise comparison against the previous version, the property checks that need no model (schema validity, citation grounding, absence of personal data, tool-call shape), and if you used a model as judge, its measured agreement with human labels. Mention pinning model and prompt versions in CI.
Keeping a suite trustworthy as change volume rises
More code reaches pull requests faster and with less context about the surrounding system, which pushes more load onto the checks that catch a wrong change. A suite that is slow or flaky under that load stops being consulted, and the role loses its purpose quietly rather than loudly.
Show it: Give a before and after with your definitions stated: flake rate, p90 time to signal, false blocking rate, suite wall-clock time. Name the policy you introduced, such as quarantine with a named owner and an expiry, or a deletion rule for tests that have never caught anything.
Test data and environments, including synthetic data without leaking production
Data and environments cause more suite failures than test code does, and generating realistic fixtures with a model is now the obvious shortcut and the obvious compliance hazard. Employers ask about the boundary because somebody at their company already crossed it.
Show it: Explain how data was created and destroyed, how parallel workers avoided collisions, and whether you ran against shared environments or ephemeral per-branch stacks, with the tradeoff named. For synthetic data, state the boundary: generated from schema and rules, production records never leaving their environment, a check that fixtures contain no real identifiers.
Using agentic and exploratory tools for discovery, not certification
Autonomous browser agents are genuinely good at finding states, crashes, unhandled errors and accessibility violations, and genuinely bad at knowing whether the business rule was honoured. Candidates who cannot draw that line either dismiss useful tooling or trust it with the release decision.
Show it: Say what you used an agent to find and what you refused to let it decide. A strong version: an exploration sweep produced candidate journeys and two unhandled error states, which you then turned into deterministic tests with explicit oracles rather than leaving the agent in the pipeline as a gate.
Debugging into the system rather than at the surface
A failure at the UI is usually a symptom several layers down, and the skill that separates a QA automation engineer from a script maintainer is being able to follow it. This has become more valuable as the volume of changes rises and the authors of those changes have less context about the system.
Show it: Describe one chase in order: the hypotheses you held, how you distinguished them, and the evidence that settled it. Name real instruments, such as a trace viewer, a request identifier correlated between test and server logs, loop reproduction with a fixed seed and worker count, or bisecting by neighbouring tests. Finish on the mechanism, not the workaround.
What a screen is looking for
These are the terms that a resume screen, human or automated, is matching against for this role. Use the ones that are true of you, in the words the posting uses.
- QA automation engineer
- SDET
- software engineer in test
- test automation engineer
- quality engineer
- test infrastructure engineer
- developer productivity engineer
- QA engineer resume
- QA automation interview questions
- test automation framework
- Playwright
- Playwright trace viewer
- Selenium WebDriver
- Cypress
- WebdriverIO
- TestNG
- JUnit
- pytest
- Jest
- NUnit
- Cucumber
- Gherkin
- page object model
- API testing
- REST Assured
- Karate
- supertest
- Postman
- contract testing
- Pact
- GraphQL testing
- gRPC testing
- Appium
- Espresso
- XCUITest
- mobile test automation
- device cloud
- BrowserStack
- Sauce Labs
- visual regression testing
- Applitools
- accessibility testing
- axe-core
- WCAG
- performance testing
- k6
- JMeter
- Gatling
- load testing
- security testing
- OWASP ZAP
- test strategy
- risk based testing
- test design techniques
- boundary value analysis
- equivalence partitioning
- exploratory testing
- test pyramid
- test levels
- unit testing
- integration testing
- end to end testing
- regression suite
- smoke test
- test oracle
- flaky tests
- flake rate
- test quarantine
- test triage
- defect escape rate
- escaped defects
- bug report quality
- severity and priority
- test data management
- synthetic test data
- test fixtures
- database seeding
- SQL
- Testcontainers
- Docker
- Kubernetes
- WireMock
- service virtualisation
- CI/CD
- GitHub Actions
- GitLab CI
- Jenkins
- Buildkite
- pipeline reliability
- parallel test execution
- test sharding
- test reporting
- Allure
- observability
- OpenTelemetry
- distributed tracing
- log analysis
- feature flags
- canary release
- shift left testing
- release readiness
- quality gates
- Git
- TypeScript
- JavaScript
- Python
- Java
- C#
- AI assisted test generation
- AI generated tests review
- self-healing locators
- autonomous testing tools
- Mabl
- Testim
- Katalon
- Tricentis Tosca
- LLM evaluation
- eval harness
- golden dataset
- LLM as judge
- prompt regression testing
- model version pinning
- RAG grounding checks
- prompt injection testing
- PII leakage testing
- non-deterministic testing
- ISTQB
- ISTQB Foundation Level
- IEC 62304
- DO-178C
- computer system validation
- GxP
- traceability matrix
- test evidence
- validation testing
- regulated software testing
Mistakes that cost people this job
Leading with a tool inventory instead of a decision.
Open with one feature you can walk end to end: the risk, the level you put each check at, the oracle you asserted against, the data problem, and what you chose not to automate. The tool list goes at the bottom of the resume for parsers. An interviewer who hears six framework names and no decision concludes you executed someone else's plan.
Treating the number of test cases as the output.
Report suite health instead: flake rate with your definition stated, p90 minutes from push to a definitive result, the share of red builds that were not product defects, and escaped defects classified by which level missed them. A suite that shrank and caught more is a stronger story than one that grew.
Quoting a number on the resume you cannot reconstruct in the room.
Pull every figure from a source you can name: the CI history behind the flake rate, the pipeline durations behind the p90, the issue tracker behind the escape count. Say how you defined it and what change moved it. An unexplainable number turns your strongest line into the moment the interview goes wrong, and interviewers probe numbers first.
Automating the manual regression sheet one-for-one at the UI level.
Re-derive coverage from risk rather than from the old document. Push most checks to the API and integration levels where they are fast and localise failure, keep a small end-to-end layer you are willing to block a release on, and delete the UI tests that only assert wording. The one-for-one port produces the slow, flaky suite that everyone learns to ignore.
Making flake go away with retries.
Treat every flake as a bug report until proven otherwise, because the intermittent product race condition is the most valuable defect your suite will ever find and a retry policy is exactly what hides it. Quarantine with a named owner and an expiry date, fix or delete by the expiry, and escalate when the quarantine list only grows.
Letting someone else own test data and environments.
Claim them. Most suite failures come from data and environment drift rather than from test code, so whoever owns those owns the credibility of the signal. Know how your fixtures are created and destroyed, whether parallel workers can collide, and whether you run on a shared environment or an ephemeral per-branch stack, with the tradeoff named.
Answering the design round with the test pyramid.
Start from what can actually go wrong in business terms, then assign checks to levels with reasons. The pyramid is a default, not an argument, and reciting it signals memorised theory. The reasoning that scores is feedback speed and failure localisation against realism, plus a clear statement of what you are leaving uncovered and what production signal covers the residue.
Asserting against what is on the screen.
Name the authoritative source of truth and assert against that: the payment intent amount, the ledger row, the event the downstream service received. If the displayed value is computed by the same code path that can be wrong, your test will pass while customers are harmed, and interviewers probe for exactly this.
Becoming the department of no, or never blocking anything.
Separate the finding from the decision. Present severity with evidence and a recommendation, accept the call when it goes against you, and write down what you will watch in production instead. Both failure modes are real: the obstacle gets routed around, and the person who has never objected adds nothing in the room where the release is decided.
Submitting a take-home with more tests and no README.
Cap your time and spend some of it on a README that states the risk model, the level choices, what you deliberately skipped, and what another day would buy. Reviewers read that first and sometimes only that. A thoughtful note about omissions beats twenty more assertions, and it is the clearest evidence that you think rather than generate.
Hiding how you used AI on the exercise, or pretending you never use it.
Use assistants the way you would at work and be ready to say which parts were generated and what you changed, because you will be asked and the follow-up is often to modify your own submission live. Candidates fail for not understanding the code they submitted, not for having had help producing it.
Collecting certifications instead of building one public artefact.
Take ISTQB if your market actually asks for it, which parts of Europe, India and government contracting do, then stop. Put the remaining weekends into a repository that tests a real API, runs in CI on a schedule, and carries a README arguing its level choices. That answers the two questions a certificate cannot: can you program, and do you think in risk.
Applying only to QA Analyst titled roles.
Search SDET, Software Engineer in Test, Quality Engineer, Test Infrastructure Engineer and Developer Productivity Engineer as well, because at many employers those titles sit on the software engineering pay ladder for substantially the same work. The band is usually attached to the title rather than to the duties, which makes the title worth negotiating before the offer is drafted.
Questions people ask
Is QA automation engineering still a good career in 2026 now that AI can write test code?
QA automation engineering is still a viable career in 2026, but the centre of the role has shifted from writing tests to deciding what is worth testing and keeping the signal trustworthy. Generating a Playwright or pytest suite is now cheap, so a QA automation engineer whose only skill was authoring scripts is genuinely exposed, while one who owns test strategy, failure triage, test data, environments and the pipeline is in demand. The roles growing fastest are adjacent: evaluating AI features, and owning the test pipeline as a platform product, and both tend to pay on the software engineering ladder rather than a separate QA band.
What skills do I need to get hired as a QA automation engineer?
A QA automation engineer in 2026 needs one language they can genuinely program in (TypeScript, Python, Java or C# covers most of the market), one web framework with Playwright now the default for new work and Selenium still dominant in enterprise estates, API testing in code rather than through a Postman GUI, Git, a CI system they have configured themselves, SQL good enough to set up and verify state, and the ability to read logs and traces from the service under test. Beyond tooling, the hiring filter is judgement: assigning a check to the right test level, naming the oracle you assert against, owning test data and parallel execution, and diagnosing flake instead of retrying it. Mobile roles add Appium, Espresso or XCUITest plus a device cloud; regulated roles add validation and traceability practice.
Do I need a degree or an ISTQB certification to become a QA automation engineer?
No credential is required to work as a QA automation engineer: software testing is not a licensed occupation in the United States, and no certification functions as a hiring gate at product companies. ISTQB Foundation Level is the one certificate with real currency, and that currency is geographic: it is often a stated requirement in parts of continental Europe, in India, and in outsourced or government contracting work, while reading as close to neutral at US and UK product companies and mildly negative if it sits above your evidence on the resume. A computer science degree is still a hard filter at a few large employers for any engineering title, and regulated domains such as medical devices or avionics care about IEC 62304, DO-178C and validation practice rather than a personal licence.
What is the difference between a QA automation engineer and an SDET?
In practice a QA automation engineer and an SDET often do the same work, and the difference is more about ladder and emphasis than duties. SDET, short for software development engineer in test, usually sits on the software engineering ladder, is expected to build test tooling and infrastructure rather than only use it, and is interviewed closer to a software engineering loop. QA Automation Engineer and QA Engineer titles more often sit on a separate and lower pay band at the same employer, and more often carry responsibility for test process and coverage governance. Because the band usually attaches to the title rather than the duties, it is worth asking which ladder a role sits on before the offer is drafted.
How long does it take to move from manual QA to QA automation?
A manual tester moving into QA automation should plan on six to twelve months of deliberate work, and the fastest version of it happens at their current employer rather than in a course. The sequence that works: take one language past tutorial depth, automate the five highest-risk journeys from your existing regression sheet at the API level where possible, get them running in CI on a schedule, then measure and publish flake rate and time to signal and fix both. A manual tester already has the thing that is hard to teach, which is defect instinct and knowledge of where the product breaks, so the gap is code and the evidence of having owned a suite.
Which language and framework should a QA automation engineer learn first?
A QA automation engineer starting today should learn TypeScript with Playwright if the target is product companies and modern web work, or Java or C# with Selenium if the target is enterprise, banking, insurance or telecom estates where those stacks still dominate. Python with pytest and requests is the strongest choice for API-heavy, data or platform-leaning roles and is the easiest to reach real fluency in. Pick one and go deep rather than collecting three shallowly, because interviewers probe the weakest item on your list, and then add API testing in code, Git, and a CI pipeline you configured yourself, which together matter more than a second framework.
What do QA automation engineers get paid, and where should I check?
Pay for a QA automation engineer varies more by which ladder the title sits on than by the work itself, so check sources rather than trusting a quoted band. BLS OES code 15-1253 covers Software Quality Assurance Analysts and Testers and publishes the median and the 10th through 90th percentiles by metropolitan area; OES code 15-1252 covers software developers and is usually the band that SDET and Software Engineer in Test roles are paid from at product companies. Department of Labor foreign labor certification disclosure data gives employer-filed base salaries by employer, title and worksite, though only for employers who sponsor visas; posting ranges are mandatory in a growing list of states including Colorado, California, Washington, New York and Illinois, so read live postings in your market; and levels.fyi shows level shape at large employers with the caveat that it is self-reported and skews high.
What does a QA automation engineer interview actually test?
A QA automation engineer interview typically runs a recruiter screen, a hiring manager screen that is usually the real filter, a coding exercise or take-home against a supplied application or API, a test design round, a debugging or triage round, and a cross-functional conversation, over two to six weeks. The coding round is a floor and is graded on structure, waits, assertions, data setup and teardown, and whether you asked what matters before writing anything. Prepare hardest for test design: given a feature, you are expected to restate the risk in business terms, assign checks to levels with reasons, name the oracle you would assert against, name the test data problem, say what you are deliberately not automating, and finish with what you would monitor in production.
How do I get a QA automation engineer job with no professional experience?
Someone with no professional experience aiming at a QA automation engineer role should expect roughly a year and should build one public artefact rather than collecting certificates. The artefact that works is a repository testing a real public API or open source application, with a README that states the risk model and explains which checks sit at which level and what was deliberately left out, an API suite as the bulk of the tests, two or three end-to-end tests with a note on why only those, a CI workflow running on a schedule so the history shows real flake data, and one documented bug with a reproduction. Contributing tests to an open source project adds review comments from strangers and a public history, and an internal move inside any employer that has an engineering team is the highest-probability path and the one most often overlooked.
Will AI replace QA automation engineers?
AI has not replaced QA automation engineers, and the honest description is narrower than the hype: it has made writing test code cheap while leaving the hard parts untouched. Knowing what correct looks like for a feature, choosing which level a check belongs at, diagnosing whether a flake is a test problem or a real race condition in the product, owning test data and environments, and deciding whether a known defect ships are all still human judgements about a specific system and a specific business. What has genuinely changed is the hiring bar for a QA automation engineer: one who only authored scripts is exposed, one who can review a generated suite and name what it misses is more valuable than before, and testing non-deterministic AI features with evaluation sets and validated judges is a new and actively hiring line of work.
Put this on a resume in about a minute
Paste your history once and point it at the QA Automation Engineer posting you are looking at. No account, no card.
Build my resume free More roles