Framework architecture
Most test suites grow without design until they hit a wall. Building a framework on purpose, with layers and abstractions that hold, is what separates SDETs from senior testers.
What makes a good test framework
Every team thinks their framework is fine until a new hire takes three weeks to add their first test. Designing for the third year, not the first month, is the SDET mindset.
You'll learn to
- Name the qualities of a good framework: readable, fast, deterministic, extensible
- Spot the smells: hidden state, magic helpers, copy-paste tests, slow CI
- Decide what to share across tests and what to keep local
- Choose between a wrapper around an existing framework and a bespoke layer
- Defend framework decisions with reasoning, not preference
Layering: drivers, abstractions, and fixtures
Test code reads top to bottom; framework code is read tree-first. Layering lets a new engineer skim the test and only dig deeper when they need to change behaviour.
You'll learn to
- Separate the driver layer (Playwright, Selenium) from your test API
- Build a test-data builder pattern that scales beyond fixtures.json
- Use fixtures and hooks deliberately — not as dumping grounds
- Write a helper that earns its place; reject ones that don't
- Introduce TypeScript types or generics where they make the API self-documenting
POM and beyond
Page Object Model is the default for a reason — it works. But it's not the only pattern, and clinging to it past its usefulness is how frameworks calcify.
You'll learn to
- Implement POM well: thin objects, no assertions, no waits
- Know when to reach for Screenplay, App Actions, or component-level patterns
- Spot when POM is hiding flakiness rather than fixing it
- Refactor a tangled object hierarchy into something maintainable
Tooling and CI/CD
Tests that don't run in CI don't run. Owning the pipeline — the schedule, the cache, the parallel execution, the failure reporting — is half the SDET job.
Choosing a CI provider
GitHub Actions, Jenkins, GitLab, CircleCI all run the same workloads but cost different things to operate. The choice locks you in for years.
You'll learn to
- Compare GitHub Actions, Jenkins, GitLab CI, and CircleCI on real criteria
- Calculate the actual cost: compute, maintenance, plugin licences, engineer time
- Know when a managed provider beats self-hosted (and when it doesn't)
- Migrate a workflow between providers without losing test history
Pipelines that don't lie
A green pipeline that skips half the tests, retries failures three times, or runs on yesterday's image is worse than no pipeline at all. Honest signal is the goal.
You'll learn to
- Detect false greens: skipped tests, swallowed failures, retry-to-pass
- Set up artefact retention so failures can be debugged days later
- Split fast and slow tests across pipelines with clear gating
- Cache dependencies and browser binaries without poisoning runs
- Wire pipeline failures into Slack or PagerDuty deliberately, not noisily
Containerised test environments
Tests that pass on a laptop and fail in CI are a half-day debugging session every time. Containers collapse the gap.
You'll learn to
- Write a Dockerfile that runs a test suite reproducibly
- Manage browser images for cross-browser runs
- Use docker-compose to spin up the SUT and dependencies together
- Decide when Kubernetes is worth the operational cost (often: it isn't)
- Cache layers to keep CI image pulls fast
Reliability and signal
Once your framework runs at scale, the bottleneck shifts from writing tests to trusting them. Quarantine the flakes, instrument the runs, and measure coverage in ways that matter.
Flaky test detection and quarantine
One flake in a thousand-test suite poisons the whole thing — engineers stop trusting any failure. A quarantine process is non-negotiable past a certain scale.
You'll learn to
- Detect flakes statistically: retry success rates across the last N runs
- Quarantine flakes automatically without losing them entirely
- Diagnose flake root causes: timing, state leakage, environment, real bugs
- Set an SLA for how long quarantined tests can stay quarantined
- Communicate the flake budget to the team so it gets owned
Test result observability
If you can only see pass/fail, you're flying blind. Treating tests like production code — with metrics, traces, and dashboards — turns the suite into a feedback system.
You'll learn to
- Capture rich test artefacts: traces, videos, network logs, browser console
- Aggregate run history into a queryable form (BigQuery, Postgres, or a SaaS)
- Build dashboards that answer real questions: 'is the suite getting slower?'
- Surface trends to the team in standups, not just to yourself
- Decide what data is worth keeping vs deleting after each run
Coverage that actually means something
Line coverage is easy to hit and easy to lie with. Real signal comes from coverage paired with mutation testing, behavioural coverage, or risk-weighted reporting.
You'll learn to
- Read line, branch, function, and statement coverage critically
- Use mutation testing to expose tests that don't actually test anything
- Choose coverage targets that match risk, not vanity
- Report coverage trends, not single snapshots
- Recognise when coverage is the wrong metric for the question being asked
Platform and team
SDET tips into platform thinking when you start optimising for other testers, not just yourself. Internal tooling, conventions, and team leverage are the senior moves.
Internal tooling for QA teams
The leverage isn't in writing tests yourself — it's in building the thing that lets ten other people write tests faster, more reliably, and with less duplication.
You'll learn to
- Identify the friction points worth automating away
- Build CLI tools and scripts that earn adoption by being genuinely useful
- Generate boilerplate (test scaffolds, fixtures, types) instead of asking people to copy-paste
- Use AI tools like Claude Code to accelerate repo-wide platform work
- Know when to build internally vs adopt an existing OSS solution
Documentation and conventions
A framework with no docs is one engineer's pet project. A framework with great docs is a team's productivity multiplier.
You'll learn to
- Write a README that gets someone running their first test in 10 minutes
- Document conventions, not just APIs — when to use what, and why
- Keep examples in the repo and verified by CI (no rot)
- Decide what to enforce with lint rules vs what to leave to review
- Build a one-page reference for the most common testing tasks
Mentoring and code review for testers
OptionalSenior SDETs spend more time reviewing tests than writing them. Reviewing well — fast, specific, kind — is what compounds team quality over months.
You'll learn to
- Review test PRs without rewriting them yourself
- Spot the missing case before approval, not three weeks later in CI
- Teach through review comments — explain the why, not just the what
- Pair with newer testers on hard debugging, not just feature work
- Recognise when a tester is stuck on the system, not the test