A quality assurance engineer is the person who gets paid to assume the software is broken until proven otherwise. You design the tests, build the automation that runs them, and decide with the team whether a release is safe to ship. The title sits between a tester and a developer, and where you go from here depends on which side of that line you lean toward.
A tester runs checks. A QA engineer decides which checks are worth running, writes the code that runs them, and gets pulled into the design conversation before a line of the feature exists. That's the real difference, and it's why hiring managers ask you to write code in the interview even when the posting says "QA".
On most teams you'll own a slice of the product: the checkout flow, the mobile login, the public API. You read the ticket in Jira while it's still a draft and ask the awkward questions. What happens if the card is declined twice. What if the user has two tabs open. You then write the automated tests in Playwright, Cypress or Selenium, wire them into the CI pipeline in Jenkins or GitHub Actions, and keep them green. When they go red, you figure out whether the product broke or the test did. That second case is more common than anyone admits.
You run test cases from TestRail or a spreadsheet, click through builds, and file bugs that a developer can reproduce without asking you a single follow-up. You're judged on the quality of those bug reports: clear steps, the exact build, a screen recording, the console error. Someone who writes great bug reports gets noticed fast.
You own the test strategy for a feature area, write and maintain automated suites, and have a real say in whether a release goes out. People judge you on escaped bugs, on whether your tests are trusted or quietly ignored, and on how early in the sprint you catch problems. A flaky suite nobody believes is worse than no suite at all.
You design the test framework other people write tests in. You pick the tools, set up test data and environments, add contract tests between services, and coach developers to write their own checks. Your work is measured by how fast the whole team can ship without breaking things, not by how many tests you personally wrote.
Here the ladder forks. The management track has you hiring, running the release process, and arguing for test time in planning meetings. The expert track has you setting quality practices across several teams, owning performance and reliability testing, and sometimes moving into developer productivity or site reliability work. Pick the track by asking which part of your week you'd miss.
Postings for this title lean hard on automation, so the coding skills below carry more weight than any single testing term.
You're the last stop before customers, which means you're often the person saying no at the worst possible moment. The release is Thursday. The product manager has promised it to a big client. You've found a bug that only shows up on Safari with a saved password, and now it's your call whether it blocks.
That pressure is real, and so is the other quiet grind: maintaining tests. Every time the design team renames a button, a handful of your selectors break. Some weeks you'll spend more time fixing tests than writing new ones. If that sounds miserable, lean toward a team that treats test code like product code, with reviews and refactoring time.
The upside is the view. Few people on a software team understand the whole product the way a good QA engineer does, and that knowledge is exactly what product and engineering managers look for when they promote.
You're ready to move toward senior when developers start asking you how to test their code instead of handing it to you. Another sign: you've fixed a flaky test by fixing the product's timing bug, not by adding a longer wait. Start writing small internal tools, like a script that seeds test accounts or a Slack alert when the nightly suite fails. Those are the things a hiring manager asks about when you say you're ready to own a framework.
6% of openings are fully remote.
$76,200 – $100,000
Typical range in the 21 of the newest 60 postings that list pay.
Yes, for this title. Manual testing jobs still exist, but they usually carry the analyst or tester title. A QA engineer is expected to write automated tests and read application code well enough to guess where a bug lives. Python, Java, JavaScript and TypeScript are the languages you'll see most, and picking the one your target team already uses is smarter than picking the trendiest.
It doesn't have to be. Plenty of QA engineers move into development, site reliability or product management because they already know the system end to end. The trap is staying on manual work for too long. If you keep writing code and owning automation, the doors stay open.
An SDET, or software development engineer in test, is usually a more code-heavy version of the same job. The SDET builds frameworks and tooling, while a QA engineer may split time between automation, exploratory testing and release decisions. Many companies use the titles loosely, so read the posting's day-to-day duties instead of trusting the title.
The ISTQB Foundation Level is the one recruiters recognise, and it helps most if you're switching careers and need something on paper. For a working QA engineer, a public GitHub repo with a clean Playwright or Cypress suite against a real site says more than any certificate.