The Role of QA in a Modern Team: QA vs SDET vs Developer
What does a QA engineer actually do today? Understand the difference between QA, SDET, and Developer roles, where test boundaries lie, and the anti-patterns that kill team quality.
“What do you actually do all day?”
I’ve been asked this question more times than I can count — by developers, by product owners, by recruiters, and occasionally by my own family. The question usually comes with good intentions but reveals a genuine gap in understanding what modern QA engineering involves.
It matters because how a team thinks about QA shapes how they structure work, who gets involved in what, and ultimately how much quality their product actually has. In this post I want to clear up the confusion between three roles — QA Engineer, SDET, and Developer — and explain what healthy and unhealthy versions of each look like.
Three Roles Defined
QA Engineer (Quality Assurance)
A QA Engineer’s primary focus is quality strategy, risk analysis, and process improvement. They are the person in the team who asks “what could go wrong?” before the code is written.
Core skills: Test design, exploratory testing, requirements analysis, defect communication, documentation.
What they produce: Test plans, test cases, risk assessments, exploratory session notes, quality metrics, process improvement recommendations.
What they may or may not do: A QA Engineer does not necessarily write automation code. Some do — especially in modern teams — but “QA” does not automatically imply automation.
The best QA Engineers I’ve worked with are excellent at critical thinking, communication, and understanding systems holistically. They can spot an ambiguous requirement in a user story at 100 paces and know which combination of inputs is most likely to break a new feature.
SDET (Software Development Engineer in Test)
An SDET is a software engineer who specialises in test tooling, test automation frameworks, and test infrastructure. The role bridges QA strategy and software development.
Core skills: Programming, CI/CD, test framework design, API testing, performance testing tooling.
What they produce: Automation frameworks, test helpers, CI pipeline configurations, custom test reporters, test data factories.
What distinguishes them from QA: SDETs write production-quality code — not just scripts. They think about maintainability, design patterns, and performance of the test suite itself. A poorly written E2E test suite is their problem to fix.
What distinguishes them from developers: SDETs think about how to test a system, not just how to build it. They design for testability. They care about observability. They ask “how will we know this broke?” from day one.
Developer (with Testing Responsibility)
In modern teams, every developer has testing responsibilities — and this is not optional.
Core testing responsibilities:
- Writing and maintaining unit tests for business logic
- Participating in code reviews that include test coverage
- Understanding the difference between testing and debugging
- Not merging code that breaks the test suite
Where many teams fail: Developers who treat testing as “QA’s job” create a structural bottleneck that no amount of QA resource can fix. If two developers introduce defects faster than one QA can find and report them, the pipeline leaks — permanently.
Where Test Boundaries Lie
One of the most useful exercises for any team is explicitly defining who writes, maintains, and reviews each layer of tests.
| Test Layer | Primary Owner | Secondary Owner | Review |
|---|---|---|---|
| Unit tests | Developer | — | Code review |
| Integration tests | Developer / SDET | QA (strategy) | Code review |
| API / contract tests | SDET | Developer | QA sign-off |
| E2E tests | SDET / QA | Developer | QA |
| Exploratory testing | QA | SDET | — |
| Performance tests | SDET | DevOps | QA strategy |
This table doesn’t apply universally — team size, maturity, and architecture all affect ownership. But having an explicit table is far more useful than vague assumptions.
import Callout from ’@/components/mdx/Callout.astro’;
Collaboration Patterns That Work
Three Amigos
The Three Amigos is a short meeting (15–30 min) where three perspectives review a user story before development starts:
- Developer — “How will I build this?”
- QA — “How will I test this? What could go wrong?”
- Product Owner / BA — “Does this actually meet the business need?”
The goal is to surface misunderstandings early — when a whiteboard marker is cheaper than a code refactor.
Definition of Done as a Quality Gate
A well-written Definition of Done forces quality conversations into the sprint workflow. A DoD that includes “unit test coverage for new code” and “exploratory session completed for new features” is a structural quality gate — it doesn’t depend on anyone remembering to check.
Pair Testing
Having a developer and a QA engineer test together — where the developer drives and the QA asks questions — surfaces edge cases that neither would find alone. It also builds mutual understanding of what “done” means.
Anti-Patterns That Destroy Team Quality
”QA as Gatekeeper”
The most common and most damaging anti-pattern. QA sits at the end of the sprint as a final checkpoint. Development “throws work over the wall” to QA, who finds defects, reports them, and development fixes them — in a loop that extends every sprint by days.
Consequences: Blame culture, slow delivery, QA as bottleneck, no shared quality ownership, “QA approved it” as an excuse for production bugs.
Fix: Involve QA at sprint planning. Test in parallel with development. Remove “QA phase” from the sprint timeline.
”QA Is Just Execution”
QA is given a test plan written by someone else and asked to execute it. They find defects but have no influence on what’s being tested or how the product is designed.
Consequences: Defects found too late, no risk-based prioritisation, QA morale collapse, high turnover.
Fix: QA should co-author acceptance criteria. QA should review designs. QA should have a voice in prioritisation.
”Developers Don’t Test”
“That’s QA’s job” is heard in sprint reviews when testers find bugs developers should have caught. QA becomes a catch-all for things that should have been prevented.
Consequences: QA spends 80% of time finding obvious bugs, 20% doing real risk analysis. Test automation ROI is negative.
Fix: Unit tests as a definition-of-done requirement. Code review coverage checks. Pair testing for complex features.
”SDET Is a Testing Robot”
An SDET is hired, handed a list of manual test cases, and told to “automate all of these.” No strategy, no framework design, no risk analysis — just convert scripts into Playwright code.
Consequences: Thousands of E2E tests that take hours to run, fail frequently, and tell you nothing useful. The SDET leaves within 12 months.
Fix: Give the SDET a strategy problem, not a transcription problem. Let them design the framework. Let them choose what not to automate.
The Modern Model — Embedded Quality
The model that works in high-performing engineering teams looks like this:
- QA is involved from requirements, not just from “ready for test”
- Developers own unit and integration test quality
- SDET maintains the automation framework and CI integration
- Quality gates are automated — no human bottleneck
- Exploratory testing is a scheduled activity, not an emergency response
This isn’t utopian — it’s what teams with good quality cultures actually do. And it starts with one thing: agreeing on who is responsible for what.
Conclusion
There is no single right model for QA, SDET, and developer roles. It depends on team size, product maturity, and organisational structure. But there are wrong models — and the most common ones are the patterns described above.
Start with the simplest fix: involve QA earlier. Share test ownership. Make the Definition of Done include quality criteria. These three changes alone will improve quality more than any new tool or test framework.
This is the second post in the Series 1 — QA General series.