Sign in Subscribe
quality-engineering

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

“Ready for Test” Isn’t the Problem - But How You Use It Might Be
“Ready for Test” isn’t a handoff; it’s a heartbeat check. Used well, it coordinates teams. Used poorly, it creates silos. Quality isn’t a phase. It’s a mindset.

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.

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.

👉 Want more posts like this? Subscribe and get the next one straight to your inbox.  Subscribe to the Blog or Follow me on LinkedIn

Read next

Comments ()