How to move into QA engineering from another career

What actually transfers

If you've worked in customer support, you already know how to reproduce a problem, ask the right follow-up questions, and write down steps clearly enough that someone else can repeat them. That is most of what a bug report is. If you've taught, or written procedures, or done any kind of compliance or audit work, you already think in terms of "what could go wrong here, and how would I check." That instinct is the actual job, more than any tool.

Domain knowledge carries over directly. If you spent five years in insurance, healthcare admin, or logistics and you're testing software built for that industry, you already understand the business rules a generic tester would have to learn from scratch — what a claim should never be allowed to do, what a shipment status can't skip. Recruiters in regulated or complex domains do notice this, because it shortens onboarding.

Participating in User Acceptance Testing (UAT) from the business side, even informally, is closer to QA than people realise. If you've ever signed off a release, filed tickets against a vendor, or run a test script someone else wrote, say so explicitly — it's evidence, not just an interest.

What does not transfer is any assumption that testing is just "using the software and noticing things." That's exploratory testing, and it's one technique among several, not the discipline. QA engineering also means writing structured test cases, designing coverage using methods like equivalence partitioning and boundary value analysis, and — increasingly — writing automated checks in code. None of that comes from adjacent experience. It has to be built.

What you actually need to build

A modern QA job advert, even at entry level, will usually list some combination of: a bug tracker (Jira is the common one), a test management tool, SQL for checking what the application actually wrote to the database, and an automation framework — Selenium, Cypress, or Playwright, driven from Java, Python, or JavaScript. Many also mention API testing with Postman, and some mention performance testing with JMeter or accessibility testing against WCAG.

You do not need all of these before applying. You need enough to survive a technical screen and to have something to point at. In practice that means:

• Write test cases and a test plan for a real piece of software (your own project, an open-source tool, anything with visible behaviour) and put it somewhere reviewable.
• Learn one automation tool properly rather than several badly. Playwright and Cypress are currently the ones most new job ads ask for in JavaScript-heavy shops; Selenium with Java is still common in older enterprise stacks.
• Learn enough SQL to write a join and a filter. QA work involves checking data, not just clicking buttons.
• Get comfortable with the vocabulary: regression testing, smoke testing, test coverage, defect severity versus priority, the shift-left idea of testing earlier in development rather than at the end. Interviewers use this language without defining it, and not knowing it reads as not having done the work.

If you're coming from a technical field — support engineering, data analysis, even a partial computer science background — the automation side will move faster because the coding isn't new, only the application of it. If you're coming from a non-technical field, be honest with yourself that this is the slow part, and budget real months for it, not a weekend course.

Is there a licence or qualification you need?

No. QA engineer is not a licensed or regulated title anywhere in the way that, say, an accountant or an electrician is. Nobody is checking a register before you're allowed to work.

The closest thing to an industry-recognised credential is the ISTQB Foundation Level certificate, issued by the International Software Testing Qualifications Board through national member boards. It covers the standard vocabulary and testing techniques and is genuinely common to see referenced in job adverts, particularly in Europe and in larger, more process-heavy organisations.

Whether it's worth doing is contested, and you should know both sides rather than take a verdict on faith. In its favour: it gives you the shared vocabulary fast, it's a concrete line on a CV that answers the "do they know what testing actually is" question, and some employers use it as a screening filter, so having it gets you past an ATS keyword match you'd otherwise fail. Against it: a lot of experienced testers and hiring managers regard it as a paper credential that proves you can pass a multiple-choice exam, not that you can test software, and they'll say so if you lean on it too hard in an interview instead of showing actual work.

A reasonable position: if you have no other evidence of testing knowledge yet, sit the ISTQB Foundation exam early — it's a few weeks of study — and then spend the bulk of your effort on a portfolio that shows you can do the thing, not just define it.

What your application actually has to overcome

Two problems stack on top of each other for a career changer, and they're different problems.

The first is the applicant tracking system. Job ads for QA roles increasingly name specific tools and years of experience with them — "3+ years Selenium", "experience with Cypress and CI/CD pipelines" — and an ATS will often filter on exact keyword matches before a person ever sees the CV. If your CV doesn't contain the tool names from the advert because you genuinely haven't used them yet, no amount of transferable-skills framing gets you past that stage. This is a real mechanical filter, not a metaphor, though how aggressively any given employer's system applies it varies and isn't something you can verify from outside.

The second is the human one, once you're past that filter: a hiring manager looking at your CV and needing to answer "can this person find bugs and write a test case without heavy supervision by month two." A career-change CV with no QA job titles on it has to answer that question with evidence rather than assertion — the portfolio, a specific project, a specific bug you found and how you documented it — because your job history won't answer it for you.

The practical fix for both is the same: put the named tools and techniques from the advert in the first third of your CV or application, backed by something real, not just listed as "familiar with." A one-line project description — "wrote and automated 40 regression test cases for a Django app using Playwright and Python, found and filed 12 defects" — does more work than a bullet point claiming attention to detail.

The honest timeline

There are two separate routes here, and they take very different amounts of time.

Manual and functional testing, without automation, is the faster door. If you can build a small but real portfolio — a couple of test plans, a bug-hunting writeup, ISTQB Foundation — and you're applying for junior test analyst or QA analyst roles rather than "QA engineer" proper, some people move in within a few months, especially if they can first get a QA-adjacent title internally at their current employer, which sidesteps the CV problem entirely.

Automation-capable QA engineering is a longer route, and you should treat it as learning to code with a specific purpose, not a light skill to pick up on the side. Getting to the point where you can write a maintainable automated test suite, debug flaky tests, and talk credibly about integrating tests into a CI/CD pipeline commonly takes the better part of a year of consistent practice for someone without a coding background — sometimes longer if you're doing it around a full-time job.

It's also worth saying plainly: the market has shifted. Pure manual-testing roles with no automation expectation at all are shrinking as companies push testing responsibility earlier into development, and a growing share of "junior QA" adverts already list a scripting language as a requirement, not a nice-to-have. That doesn't close the route, but it does mean the manual-only path is a narrower door than it used to be, and it's worth aiming your study time at automation from early on rather than treating it as a stage two you'll get to eventually.

What to do next

Pick one automation tool and one small real project, and build the portfolio piece before you send another application — a CV claiming QA skills with nothing to show for them is the thing getting filtered out right now, not your lack of a QA job title. Sit ISTQB Foundation if you have no other credential to point to. Then go back through the job ads you've already been rejected by and check, tool by tool, whether your CV actually contained the words they were filtering on.

jobmarket.pro reads each advert in full and prepares an application from your actual work history, matching it against what the ad genuinely asks for rather than guessing at keywords.