QA Career Roles in Software: What Each Job Actually Does

This is often the entry point into QA. QA Analysts and Manual Testers write and execute test cases, report bugs, do exploratory testing, and verify fixes after developers ship patches.

What actually happens day to day: you work from requirements or user stories, build test cases in TestRail or Zephyr, run regression passes before releases, and file bugs with clear repro steps. Exploratory testing — trying to break the product without a script — is where many real user-facing defects get found.

What matters most: attention to detail and understanding requirements. A vague bug report ("login broken") wastes everyone's time; a precise one (steps, expected vs actual, browser, screenshot) gets fixed fast. Basic SQL to verify database state and comfort reading logs separate strong analysts from struggling ones.

Industry norm: common in enterprise, healthcare, banking, and government — especially where UAT sign-off and audit trails matter. At product startups, pure manual-only roles are less common but still exist for compliance-heavy features.

SDETs (Software Development Engineers in Test) write automated test scripts and wire them into CI/CD so regression runs on every pull request — not just before a release panic.

What actually happens: you pick a stack (Playwright, Cypress, Selenium, or Appium for mobile), build page-object or API test layers, integrate with GitHub Actions or Jenkins, and triage flaky failures. When the suite goes red, you decide: real regression, bad test, or environment issue.

Skills that matter: solid coding in Java, Python, or JavaScript/TypeScript — SDET is a engineering-adjacent role at most product companies. At Microsoft, Amazon, and similar orgs, "SDET" or "Software Engineer, Test" is leveled like SWE.

Industry reality: this is the default hire at product companies. Mid-level SDETs design test plans and automate them. Many manual QAs move here by learning one language and one framework deeply.

Performance Testers focus on load, stress, and scalability — making sure the app holds up under real-world traffic, not just when one QA clicks through it locally.

What actually happens: you define scenarios (500 concurrent checkout users, spike to 10× normal traffic), run tests in JMeter, k6, Gatling, or cloud load platforms, and analyze response times, error rates, and bottlenecks. You work with SRE and backend teams on connection pools, caching, and database query plans.

When companies hire this role: e-commerce, fintech, streaming, and any product with SLAs or seasonal traffic spikes. At smaller companies, a senior SDET or SRE often owns this part-time.

What good looks like: baseline metrics before release, reproducible load scripts in version control, and reports stakeholders understand — p95 latency, throughput, error budget burn — not just "it felt slow."

Security Testers look for vulnerabilities — injection flaws, broken authentication, exposed secrets, insecure APIs — often using OWASP ZAP, Burp Suite, or commercial DAST tools.

What actually happens: you run automated scans, manual penetration-style testing on staging, review auth flows and session handling, and file findings with severity (Critical/High/Medium). In regulated industries, you may align with OWASP Top 10 checklists and compliance frameworks (PCI, SOC 2).

Title variants: Application Security Engineer, QA Security, Penetration Tester (more offensive). Pure "Security QA" is common in banks and health tech; product startups often rely on AppSec teams or external pentests instead of a dedicated QA security role.

Career note: this branch often leads toward AppSec or security engineering rather than traditional QA management.

API Testers validate backend services directly — independent of the UI — using Postman, REST Assured, Insomnia, or code-first HTTP clients.

What actually happens: you test REST or GraphQL endpoints for correct status codes, payload shape, auth headers, rate limits, and error handling. Contract testing (Pact) ensures services don't break consumers when schemas change. You're often the first to catch breaking API changes before the frontend team notices.

Industry fit: microservices architectures, mobile apps with heavy API backends, and B2B platforms. Many SDETs include API testing in their role; dedicated API QA appears when the surface area is large or integrations are business-critical.

Skills: JSON/XML validation, OAuth and JWT flows, basic understanding of HTTP and async jobs (webhooks, queues).

QA Leads and Managers plan overall test strategy, manage the team, decide what gets tested and when, handle risk assessment, and report quality metrics to stakeholders.

What actually happens: less hands-on testing, more planning — test plans per release, resource allocation, hiring, 1:1s, and escalation when quality blocks a ship date. You define the test pyramid split (unit vs integration vs E2E), own release criteria, and present escape-defect trends to leadership.

Title variants: QA Lead (often still partly hands-on), QA Manager, Head of QA, Director of Quality. In separate QA orgs (common in banks), QA reports outside engineering; in embedded QA (common in product startups), QA leads sit inside product squads.

Industry reality: first lead role often goes to the strongest Senior QA — not always the person who wanted management. Good leads grow people; bad leads micromanage test cases.

In some companies, a dedicated role owns user acceptance testing and sign-off before releases go to production — especially where business users must formally approve changes.

What actually happens: you coordinate UAT schedules with product owners and business stakeholders, prepare test environments and data, track sign-off checklists, and document who approved what. In regulated environments (finance, pharma, gov), this paper trail is audit-critical.

Title variants: UAT Coordinator, Business Acceptance Tester, Release Manager (broader). Often overlaps with Business Analyst or Project Manager at smaller orgs.

Industry fit: enterprise IT, ERP rollouts (SAP, Salesforce), and internal tools where "the business" must bless releases. Rare as a standalone title at pure product startups.

Smaller companies (roughly under 100 people): one QA engineer often does manual testing, writes Playwright scripts, tests APIs, and joins release calls. The job post says "QA Engineer" but the week touches four roles. Title inflation is common — "Senior QA" may mean "only QA person."

Larger organizations: roles split. Manual analysts handle UAT and compliance scripts; SDETs own automation frameworks; performance and security may be dedicated teams or centers of excellence. Big tech levels SDET like SWE (L3–L5+); banks may have separate QA departments with architects and release managers.

How to use this map: if you're building a team, start with one strong SDET-generalist, add manual capacity when compliance or UAT load grows, and hire specialists when traffic, security, or integration complexity demands it. If you're planning a career, pick a primary track (manual → SDET, or SDET → perf/security/API), then broaden — generalists thrive at startups, specialists at scale.