Career
A competency matrix you can prove
Six areas of QA work at four levels, where each level names what someone can do and a task on this site that proves it. Mark where you are, mark where you are heading, and take the evidence in between to your next review.
How to read the levels
The levels describe how much support the work needs and how far its effect reaches, not job titles. “Senior” means different things in different companies, and this site knows nothing about yours, so you won't find titles, salary bands, or years of experience here.
- Supported. Does the work with a template, a checklist, or someone to ask. The output is right; the decisions were made with help.
- Independent. Owns the routine work end to end, including the judgement calls it needs, and notices when something is off.
- Shaping the team's practice. Changes how the team works: sets the standard, makes the call when the evidence is thin, and others follow it.
- Setting direction. Changes how quality works beyond one team, and is accountable for the result. Mostly proven by what happened, not by an exercise.
Why each cell names evidence
A matrix made of adjectives (“good at automation”) is argued about; a matrix made of evidence is checked. So each of the first three levels points at a task here with a “done when” behind it: a report that scores, a check that finds exactly the seeded rows, a test the reviewer passes.
The top level mostly can't be proven by an exercise. Those cells say so, and ask for what actually happened instead.
For frameworks maintained as standards, see SFIA's seven levels of responsibility and ISTQB's certification levels. This matrix is this site's own, written for the material here, and doesn't map onto either.
Assess yourself
For each area, pick the row you could show evidence for today. Selecting the same row again clears it. Then, if you want a plan rather than a snapshot, pick the level you are heading for: the summary will list every step in between and what each one asks you to show. Your choices stay in this browser, and the summary is yours to paste into a one-to-one, a review, or a development plan.
Judgement about testing
Knowing what testing can and can't tell you decides everything else: what to test, when to stop, and what a green run means.
Test design
Well-chosen inputs find bugs that clicking around misses, and turn vague requirements into questions someone can answer.
Finding and reporting
A bug nobody can reproduce is a bug nobody fixes, and a report that reads as an accusation costs more than it should.
Below the user interface
Some defects never reach a screen: a wrong status code, a total that doesn't add up, a row nothing points at.
Automation that holds up
Tests that pass while checking nothing are worse than no tests: they cost the same and buy false confidence.
Delivery and release
Tests only protect a release if they run on every change, are trusted when they fail, and someone can still say no.
Nothing assessed yet. Pick the row that matches what you can show today, not what you know about.
Using it with a team
Two people assessing the same person should land on the same row, because each row names something observable. Where they don't, the disagreement is usually about evidence nobody has seen: that's the useful conversation, and the “show me” line is there to settle it.
The areas follow the QA roadmap, so a gap here has a path there. The roadmap's optional specialisms (visual testing, Selenium and Java, BDD, AI agents) are deliberately not levelled: they're choices a team makes, not a ladder everyone climbs.
What this isn't: a hiring rubric, a performance score, or anything to rank people with. It has no weights and produces no number, because a single score would hide exactly the detail that makes the conversation useful.