“Ready for Test” Isn’t the Problem — But How You Use It Might Be

In the age of DevOps and CI/CD, does the "Ready for Test" status still belong in your workflow? The answer isn’t black and white.

“Ready for Test” — three words that spark heated debates in QA circles.

Some say it undermines shift-left. Others say it creates silos. But after 15+ years in QA leadership and helping build quality practices at startups and scaleups, I’ve come to believe something more nuanced:

It’s not the status that’s broken. It’s how teams treat it.

The Common Criticism

Most of the pushback against “Ready for Test” boils down to this:

• It encourages handoffs, not collaboration
• It delays testing until dev work is “done”
• It hides QA effort from early sprint planning
• It fosters mini-waterfall workflows

And when used in these ways, it does work against modern quality engineering principles.

But that’s not the whole story.

Why “Ready for Test” Can Still Work

In many fast-moving product teams—especially 12–24 months into a modern QA transformation—RTT serves a practical purpose:

✅ Signals that code has been deployed and is testable
✅ Coordinates environments, merges, and staging flows
✅ Integrates into Jira or CI tools for traceability
✅ Helps QA triage and prioritize exploratory, integration, or regression testing

At Snap, for example, we use "Ready for Test" to signal that a feature is deployed to a QA environment—not that testing starts now, but that we’re ready to validate what's already been planned and partially tested in parallel.

It’s not a handoff.
It’s a coordination flag.

The Real Danger: Mindset, Not Metadata

Where RTT becomes a problem is when it reflects broken ownership models:

🚫 Developers toss stories over the wall
🚫 QA gets squeezed at the end
🚫 Testing wasn’t considered in story pointing
🚫 Regression cycles feel rushed and unplanned

That’s not a workflow issue—it’s a culture issue.

A Roadmap View: RTT in Context

Let’s say your org is 18 months into building a modern QE practice. You likely:

• Have automation in place, but it’s still maturing
• Are expanding API and E2E coverage
• Have CI pipelines, but still rely on environment-based testing
• Are exploring shift-left—but still figuring out TDD/BDD/adoption
• Need status markers like RTT to coordinate, not delegate

That’s not bad. That’s realistic.

How to Evolve the Role of RTT

Instead of abolishing RTT, use it as a stepping stone toward full shift-left maturity:

✅ Pair dev + QA on test design in grooming
✅ Include QA in estimation
✅ Automate pre-merge validations
✅ Make “Done” mean “Tested”
✅ Use RTT transparently, not as a crutch

Eventually, your team may not need RTT at all.
But if you’re not there yet? That’s okay. Just use it wisely.

Closing Thought

Quality isn’t a checkbox. It’s a continuous conversation.

“Ready for Test” can be part of that conversation—as long as we don’t let it become the end of one.