“Development is done.”
We’ve all heard this before.
The feature is implemented.
The code is merged.
The pull request is approved.
And yet… the work is not finished.
Done is not the same as ready
In many teams, “done” is treated as a milestone.
But what does “done” actually mean?
- Code written?
- PR approved?
- Deployed to staging?
None of these guarantee that the system behaves correctly.
Because working code is not the same as validated behavior.
The real checkpoint: validation
A release is not ready when development is done.
It’s ready when the team has nothing left to prove.
That means:
- The feature behaves as expected
- Edge cases are handled
- Business rules are respected
- The user experience makes sense
Until then, the work is still in progress.
When QA is misunderstood
Many teams see QA as a final step.
A checkpoint.
A gate.
Sometimes even a blocker.
But that’s a misunderstanding.
QA is not the problem.
QA is the feedback loop.
If issues are consistently found late in the process, it usually points to:
- Missing acceptance criteria
- Lack of shared understanding
- Weak validation during development
- Gaps between product, development, and QA
Quality is not a phase
One of the biggest mistakes teams make is treating quality as a stage.
Something that happens after development.
But quality is not something you add at the end.
It’s something you build throughout the process.
From:
- refinement
- to development
- to review
- to testing
Quality is not what QA finds at the end — it’s what developers prevent at the beginning.
What strong teams do differently
High-performing teams don’t “throw things to QA”.
They:
- Involve QA early in the process
- Clarify acceptance criteria before coding
- Validate behavior during development
- Share responsibility for quality
They don’t wait for code to be ready to start testing.
QA helps define how the system should be tested before the first line of code is written.
QA doesn’t validate alone.
Quality is owned by the team.
A more mature way to think
Instead of asking:
“Is development done?”
Start asking:
“Has this been validated end-to-end?”
Because delivery is not about code.
It’s about behavior.
Final thought
A release is not ready when development is done.
It’s ready when the team has nothing left to prove.
Because quality is not a phase.
It’s evidence.
References / Further Reading
Engineering & Quality
- Continuous Delivery — Jez Humble & David Farley
Product & Collaboration
- Inspired — Marty Cagan
- Empowered — Marty Cagan
Engineering Management
- The Manager’s Path — Camille Fournier
Top comments (0)