Orchestrate multi-stage testing by starting one run from another
Some testing workflows are bigger than a single run.
The Start run step lets you trigger a new DoesQA run from inside an existing run, so you can chain packs together, reuse session state, and automate more complex quality workflows without adding manual steps or extra CI logic.
This is an advanced capability, but when used well it can unlock faster feedback, cleaner environments, and far more control over how your test packs execute.
What the Start run step does
When this step runs, it starts a new run as part of the same overall workflow. That new run can:
execute a different set of flows
run with different values
act as a follow-up stage to the current run
run only when a condition has been met
run cleanup or supporting flows after your main tests
This is particularly powerful when combined with values, conditions, notifications, recipes, and tagging.
Why teams use Start run
Split smoke and regression for faster feedback
A common pattern is:
Run a small smoke pack first
Only if smoke passes, trigger the full regression pack
This keeps feedback fast and avoids wasting runners on a long regression when the environment is already broken. It also reduces test data churn and unnecessary load on shared systems.
Reuse authenticated sessions without repeated logins
Some systems rate-limit login attempts or rely on external auth providers such as Google, which can make repeated logins slow or unreliable.
Start run can help by:
logging in once
capturing session state (cookies, local storage, session storage)
starting a child run that injects that session into the next stage
running the rest of the pack without going through the login UI again
This can reduce runtime, improve reliability, and avoid triggering security throttles.
Trigger targeted packs from a single orchestration flow
Instead of duplicating logic across multiple pipelines or schedules, you can create one orchestration flow that decides what to run.
For example:
if feature flag A is enabled, run pack A
if region is EU, run the EU pack
if a deployment tag is present, run the related pack
This centralises decision-making in DoesQA, making it easier to change behaviour without editing CI pipelines or committing code.
Automate cleanup and housekeeping
Some tests create data that should be removed afterwards. Start run can trigger a cleanup run at the end of a workflow.
Examples include:
deleting an order created during checkout testing
clearing test accounts or sessions
resetting feature flags
removing items created during a test run
You can pass values such as an order number, user ID, or reference into the cleanup run so it can act precisely.
This keeps environments cleaner and reduces long-term test pollution.
How this helps operationally
Start run is a practical way to:
reduce wasted runner time
keep concurrency available for other work
avoid duplicating pack logic across tools
reduce repeated actions like login steps
keep test packs modular as they grow
build more complex quality workflows without complexity in your CI setup
It is a tool for scaling how you run testing, not just how you write tests.
Pairing ideas for stronger workflows
Start run works best when combined with:
values and value overrides to control what runs next
conditions to trigger the next run only when needed
notifications so teams get results at the right time
tagging and recipes to select the right flows and tests for each stage
Used together, you can build multi-stage packs that behave like a quality pipeline inside DoesQA.
When to use Start run
This step is ideal when:
your packs are getting large and you want better structure
your system makes repeated logins expensive or fragile
you want staged execution: smoke then regression
you need automated cleanup after test creation
you want a single place to control conditional pack execution
If your test suite is growing and you want more control without adding maintenance or pipeline complexity, Start run is often the step that unlocks the next level.