The standard, in full
The rubric
This is the entire standard the Calibrator scores against. Nothing is hidden; the rubric is the product.
A
Levels
| ID | Title | Band |
|---|---|---|
| L1 | QA Engineer | Executes |
| L2 | Senior QA Engineer | Owns a feature area |
| L3 | SDET | Builds the tooling |
| L4 | Senior SDET | Owns the framework |
| L5 | Lead / Principal SDET | Sets technical direction |
| L6 | QA Manager / Head of QA | Owns the org's quality outcome |
| L7 | Director / VP of Quality | Owns quality as a business function |
B
The calibration rule
Final level = median of the seven dimension scores, capped at (lowest score + 1).
The cap is what gives the tool teeth. Someone with L6 influence and L2 technical depth is not an L4; they are an L3 with a spiky profile, and the result says so.
C
Confidence band
- High — quantified outcomes and named systems present.
- Medium — responsibilities specific, outcomes vague.
- Low — adjectives only. The level is unverifiable from what was supplied, and that is itself the finding.
D
Dimensions and anchors
Each dimension is scored 1–7 independently against these anchors.
01
Technical depth
| 1 | Executes manual test cases. Reads code but does not write it. |
| 2 | Writes UI automation against an existing framework. Follows patterns set by others. |
| 3 | Writes and maintains automation across UI, API and integration layers. Comfortable in the CI config. |
| 4 | Designs and owns a framework. Makes build-vs-buy calls. Debugs the pipeline, not just the test. |
| 5 | Sets technical direction across multiple frameworks and teams. Contributes to the product codebase. |
| 6 | Directs technical strategy through others. Depth is current enough to challenge the choices. |
| 7 | Sets the engineering standard for quality across an organisation. Depth is strategic, not hands-on. |
02
Test strategy
| 1 | Follows a test plan written by someone else. |
| 2 | Writes test plans for a feature. Coverage-driven thinking. |
| 3 | Applies risk-based prioritisation. Understands the test pyramid and where things belong. |
| 4 | Decides what NOT to test and can defend it. Shapes the pyramid for a service. |
| 5 | Owns strategy across a product. Balances speed and confidence explicitly. |
| 6 | Owns strategy across an org. Aligns it to release model and business risk appetite. |
| 7 | Defines the quality operating model. Strategy is a board-level artefact. |
03
Scope of ownership
| 1 | A set of test cases. |
| 2 | A feature area. |
| 3 | A service or a squad. |
| 4 | A framework or platform used by multiple squads. |
| 5 | A technical domain across teams. |
| 6 | The quality outcome of a whole engineering org. |
| 7 | Quality as a business function, with budget and headcount. |
04
Engineering practice
| 1 | Aware of CI. Does not participate in code review. |
| 2 | Commits to a shared repo. Reviews test code. |
| 3 | Practises TDD or something close. Reviews production code credibly. |
| 4 | Drives trunk-based development, pairing and collective ownership within a team. |
| 5 | Raises the practice bar across teams. Recognised as a reference point. |
| 6 | Institutionalises practice. Changes how the org builds, not just how it tests. |
| 7 | Practice is an organisational standard with measurable adoption. |
05
Quality economics
| 1 | Counts defects. |
| 2 | Tracks pass rate and coverage. |
| 3 | Tracks defect escape rate. Aware of DORA. |
| 4 | Ties test investment to release throughput. Argues cost of delay. |
| 5 | Runs quality as a measured system. Trades coverage against lead time deliberately. |
| 6 | Owns the numbers executives see. Defends the QA budget with them. |
| 7 | Quality economics is part of the P&L conversation. |
06
Influence
| 1 | Influences own work. |
| 2 | Mentors a junior. Trusted within the squad. |
| 3 | Sets standards for a squad. Onboards others. |
| 4 | Influences across squads without authority. |
| 5 | Recognised authority across the engineering org. |
| 6 | Influences peers in engineering leadership. Sets policy. |
| 7 | Influences the business and the external market. Speaks for the function. |
07
Delivery evidence
| 1 | Can describe tasks completed. |
| 2 | Can describe features shipped. |
| 3 | Can point to a system built and its adoption. |
| 4 | Can attach a number to an outcome (escape rate, cycle time, incident count). |
| 5 | Multiple quantified outcomes across contexts. |
| 6 | Org-level outcomes with a before and after, verified by others. |
| 7 | Outcomes that changed how the business ships, sustained over years. |
Ready to be measured against it?