Testing & Quality Engineering: SFIA levels and developer seniority
Fennec team · 20 Apr 2026 · 4 min read
Quality engineering is not 'the people who click buttons before release'. It is the discipline of deciding what to test, how much, and how to catch problems before users do, and increasingly, of building the automation that makes that possible at speed.
SFIA levels here move from running the tests you're given, to designing a testing strategy, to owning quality culture across an organisation. Above level 4, the ladder splits into a technical specialist track (test architecture, automation) and a management track (resourcing and governance), and the paragraphs below reflect both.
1
Level 1: Follow
“I can run test scripts and report bugs clearly with reproduction steps. I understand what a test case is.”
Evidence at this stage is about clarity: bug reports you wrote with clear, reproducible steps, test scripts you executed and reported against accurately, or notes from shadowing someone writing an automated test for the first time.
Write a bug report clear enough that a developer reproduces it on the first try, that skill alone saves a surprising amount of time for everyone. Study an existing test suite to learn what a good test case actually looks like, and ask to shadow someone writing an automated test.
2
Level 2: Assist
“I write and execute test cases from requirements, document defects with severity, and maintain test environments.”
The evidence shifts toward documentation and judgement: test cases you wrote directly from requirements, defects you documented with severity and supporting evidence, or a test environment you maintained yourself for a sprint without needing reminders.
Write your first automated test, even a simple one, since that's usually the hardest step to take. Maintain a test environment for a sprint on your own, and practice prioritising defects by severity rather than just reporting everything you find at the same level of urgency.
3
Level 3: Apply
“I design test strategies and build automated test suites across unit, integration, and e2e levels. I hook them into CI/CD and actively improve quality: I'm not just running tests, I'm engineering quality in.”
This is where strategy enters the picture: a test strategy you designed spanning unit, integration, and end-to-end levels, a test suite you wired into CI/CD so it actually blocks bad merges, or a quality issue you found and drove to a fix without being asked.
Design a test strategy for a feature before it's built rather than bolting tests on afterward. Wire a suite into CI so it has real teeth, and pick one quality gap, flaky tests or missing coverage are common candidates, and fix it as a deliberate project rather than a side effect of other work.
4
Level 4: Enable
“I own the test strategy for a product. I decide how quality is measured, introduce approaches like TDD or BDD, and help other engineers write better tests. Quality in my area is my responsibility.”
By now the evidence is ownership of quality itself: a product's test strategy that you own outright, a quality practice you introduced like TDD, BDD, or contract testing, or an engineer you helped write meaningfully better tests.
Own quality for a product area rather than a single test suite, and introduce one new quality practice and actually measure whether it worked. Mentoring an engineer on testing is often the clearest sign that quality has become a leadership responsibility for you, not just a technical one.
5
Level 5: Ensure & Advise
“I set quality engineering standards and culture across the organisation. As a technical specialist I design test automation architecture spanning multiple products and mentor senior testers; as a test manager I own resourcing, delivery and governance of testing across programmes.”
The ladder splits here: the evidence is a test automation architecture spanning multiple products if you're on the specialist track, or resourcing and governance of testing across programmes if you're managing it, alongside senior testers you've mentored either way.
Build an automation framework used by more than one team, or take ownership of testing delivery and resourcing across programmes, whichever track fits. A quality standard the organisation follows because you set it is the throughline for both paths at this level.
6
Level 6: Initiate & Influence
“I define quality engineering direction at an organisational level. As a Principal Test Engineer / Test Architect I set automation and tooling strategy used org-wide; as a Head of Quality I set assurance frameworks and quality governance and represent quality at senior leadership level.”
At the top, the evidence is organisation-wide direction: automation and tooling strategy you set as a Principal Test Engineer or Test Architect, or an assurance framework and quality governance you defined as a Head of Quality, plus a track record of representing quality at senior leadership level.
From here, set the automation and tooling direction for the organisation, or set assurance frameworks and represent quality at the leadership table, and publish your quality engineering thinking externally so it outlasts any single team you've worked with.
Go deeper
A large community and content hub for software testers.
The syllabi behind widely recognised testing certifications.
Google's own writing on testing practice and culture.
Knowing where you sit is one thing, proving it later is another. Fennec lets you log testing & quality engineering evidence as you go, a shipped feature, a decision, a review, tagged to the level it demonstrates, so the case for your next step is already made when you need it.