Who Should Write Test Cases: QA or Dev?

"Should QA write all the test cases, or should developers write them?" This question comes up in every team restructuring conversation. The answer matters less than most people think. The timing and quality of test cases matter much more.

---

The Case for QA Writing Test Cases

QA engineers are trained in test design techniques: equivalence partitioning, boundary value analysis, decision table testing. They think systematically about coverage. They're not attached to the implementation, so they test from a user perspective rather than a "how I built it" perspective.

QA-written test cases tend to be more comprehensive in the edge-case dimension because QA engineers specifically think about what could go wrong, not just what should work.

---

The Case for Developers Writing Test Cases

Developers know the implementation. They know which code paths are complex, which edge cases were tricky to handle, and where the implementation might be brittle.

Developer-written unit tests and integration tests — written alongside the code — are the fastest possible feedback loop. No handoff, no delay, immediate.

---

The Honest Answer: Both, at Different Layers

The testing pyramid tells you who should write what:

Layer	Primary Owner	Reason
Unit tests	Developer	Implementation knowledge
Integration tests	Developer + QA	Shared interface knowledge
API tests	QA (with dev input)	Contract from user perspective
E2E / UI tests	QA	User journey ownership
Exploratory	QA	User perspective specialization

Neither QA alone nor developers alone covers all layers well. The right answer is: developers own the bottom of the pyramid, QA owns the top, and the middle is collaborative.

---

The Timing Principle

More important than who writes test cases is when.

Test cases written before development starts:

• Define acceptance criteria clearly
• Guide implementation
• Catch spec gaps before they become code

Test cases written during development:

• Reflect implementation knowledge
• Catch edge cases the developer thought of

Test cases written after development:

• Are based on what was built, not what was specified
• Miss the spec gaps that slipped through

[!TIP] The best test coverage comes from both QA and developers contributing at different times: QA outlines acceptance-criteria-based tests before development, developers add implementation-based tests during development, and QA refines and expands after.

---

The Practical Recommendation

For most teams:

1. QA writes test cases during requirement review (acceptance criteria, happy path, obvious edge cases)
2. Developers write unit and integration tests during implementation
3. QA expands test cases after seeing the implementation (implementation reveals edge cases the spec didn't anticipate)
4. Both review the final test coverage before release

This distributes the work appropriately, maintains the benefits of both perspectives, and keeps testing integrated with development rather than sequential.

The teams that produce the best test coverage are the ones where the question "who writes test cases?" has a boring answer: "we both do, at different stages."