What Systems Testers actually do.
Plain English. Real examples. QA stands for Quality Assurance — we'll use both terms, just like the industry does.
The one-sentence version
A Systems Tester checks that software does exactly what it's supposed to do — and finds what's broken before real users do.
What Systems Testers actually produce at work
Testing is not clicking around hoping something breaks. It's a disciplined process with specific, repeatable outputs.
Test Cases
A test case describes one specific thing to check — what you do, what you expect to happen, and whether it passed or failed.
Defect Reports
When something doesn't work, a tester writes a defect report — clear enough that a developer can reproduce and fix it without asking follow-up questions.
Test Plan
Before testing begins, a QA writes a test plan — what will be tested, what won't be tested, how long it will take, and what "done" looks like. It sets expectations with the team.
- Scope: what's included and what's not
- Approach: functional, regression, accessibility, performance
- Entry criteria: when testing can start
- Exit criteria: when testing is complete
- Risks: what could prevent testing from happening
Test Evidence
Screenshots, screen recordings, and logs that prove testing happened and show exactly what was found. Evidence protects the tester and the team — if something goes wrong in production, the test evidence shows what was checked.
This is one of the first professional habits new testers build.
Types of testing — good to know early
You don't need to master all of these now. Just recognise the names.
Does it do what it's supposed to do? The most common type for new testers.
Did this new change break something that was working before? Run after every release.
Can people with disabilities use this? Mandatory for Australian government projects.
No script — just explore the system looking for things that feel wrong. Requires judgment, not just process.
Real users test the system before it goes live. BAs often coordinate this. QAs support it.
Scripts that run tests automatically. Useful for repetitive checks. Humans still decide what matters.
Common QA pitfalls — good to know early
"The login is broken" is not a defect report. A developer can't fix what they can't reproduce. Steps, expected, actual, environment — every time, without exception.
Testing what works when everything goes right is easy. The real skill is testing what happens when things go wrong — bad data, slow connections, unexpected user behaviour.
If it worked once on your machine, in Chrome, with perfect data — that's not a passed test. That's one data point. Good testers vary their conditions deliberately.
QAs find bugs — but the goal isn't to catch developers out. It's to ship quality software together. Good testers share findings early, communicate clearly, and focus on the product.
Quick self-check — does QA fit you?
These aren't requirements — just signals worth noticing:
- You notice when things don't work the way they should
- You like being thorough and checking your own work
- Writing clear, reproducible steps feels satisfying
- You enjoy finding edge cases and asking "but what if...?"
- You care about the user experience, not just whether it technically functions
You don't need all five. Two or three is enough to explore further.