A QA tester evaluates software before users do: designing test cases from requirements, executing them against new builds, hunting the regressions a change introduced, and turning what they find into bug reports a developer can act on. The stereotype is "clicking through the app all day"; the reality is closer to applied skepticism, figuring out where software is most likely to be wrong and proving it. (For how the tester role relates to QA as a discipline, see QA vs QC; this post is about the job itself.)
The Day-to-Day#
A tester's week, across most teams:
- Test design: reading a ticket or spec and deriving what to check: the happy path, the edge cases, the inputs nobody intended
- Test execution: running planned cases against the latest build, manually or by triggering automated suites
- Exploratory testing: unscripted investigation of new features, where many of the interesting bugs surface
- Regression checking: verifying a change did not quietly break what already worked
- Bug reporting: writing reproducible reports with steps, expected vs actual, environment, and evidence; a bug a developer cannot reproduce barely counts as found
- Verification: re-testing fixes and closing the loop
The output is information: a clear picture of the build's risk, delivered while there is still time to act on it.
Manual, Automation, or Both#
The role splits into overlapping profiles. Manual testers excel at exploratory work, usability judgment, and the cases automation cannot evaluate. Automation engineers (often titled SDET) write the scripted suites: unit-adjacent API tests, Playwright or Cypress end-to-end flows, the CI wiring that runs them per commit. Most modern roles sit between: testers who design cases, automate the repetitive ones, and spend the freed hours exploring.
In practice the split of time looks like: understanding the change, deciding what could break, automating the checks worth keeping, exploring what scripts cannot judge, and writing up findings.
Skills That Matter#
- Reading a system critically: spotting the ambiguous requirement and the untested boundary before they ship
- Reproduction discipline: shrinking "it sometimes breaks" into five reliable steps
- Enough code to automate: JavaScript or Python plus a framework (Playwright, Cypress, Selenium) is the going expectation
- Tooling fluency: bug trackers, API clients, browser devtools, CI pipelines, test management
- Communication: a tester's bug report and risk summary are the product; vague ones waste everyone's week
How the Role Is Changing#
Two shifts define the last few years. Quality work moved earlier: testers review requirements, pair on test plans before code exists, and own quality gates in CI rather than inspecting at the end. And automation, increasingly AI-assisted, took over the repetitive execution: generated and self-maintaining test suites now handle the regression grind that used to consume tester hours, moving the human work up the stack to test strategy, exploratory depth, and judgment calls automation cannot make.
What did not change: someone still has to decide what "working correctly" means, notice when it quietly stops being true, and say so clearly.
Limitations and Misconceptions#
- Testers do not "assure" quality alone. Quality is built by the whole team; a tester provides information about it.
- Testing cannot prove absence of bugs. It raises confidence and finds problems; it never certifies perfection.
- "Anyone can test" is half-true. Anyone can click around; designing the minimal set of cases that exposes maximum risk is a learned skill.
Conclusion#
A QA tester turns "the build seems fine" into evidence: designed test cases, executed checks, explored corners, and reproducible bug reports, with automation carrying the repetitive load. The role keeps moving toward strategy and judgment as tooling absorbs the grind.
The grind it absorbs first is the regression suite. ObserveOne's Autopilot generates Playwright tests from your app's URL and self-heals selectors when the UI shifts, which hands testers the suite-maintenance hours back for the work that actually needs a human: deciding what to test next.