Test management for CI/CD teams: structure for the manual half of testing

TL;DR

CI stays in CI. The manual half lives here. Regression cycles, exploratory sessions, and release sign-off in one structured surface — with defects linking out to Jira, GitHub, or Linear so you're not maintaining two issue systems.

01The CI/CD team test management problem

Sound familiar?

Your CI is healthy. Every PR runs unit + integration + a Playwright suite, and you ship green builds multiple times a week. But pre-release regression sweeps, exploratory testing on the feature behind the flag, mobile checks on real devices, third-party smoke tests — that work lives in a Slack thread.

02Why TestOrchestrator fits CI/CD teams

Automation-friendly, not automation-replacing

TestOrchestrator stays out of CI's way. It's not your test runner — it's the structured surface where the manual cases, exploratory sessions, and sign-offs live.

Exploratory as a first-class artefact

When a dev or PM kicks the tires on a new feature, the findings shouldn't disappear into a Slack thread. Sessions log charters, time, and findings — searchable later when someone asks "did we test this?"

Release sign-off you can audit

Run a regression cycle. See pass/fail per case. Sign it off. The cycle is the record of what was tested before that release went out. Auditors love it. Postmortems love it.

Defect linking out, not duplication

External references let cases and runs link to Jira, GitHub Issues, Linear — whatever you use. No need to recreate defects in a second system.

One source of truth for release readiness

Instead of scattering the conversation across CI dashboards, Slack, and Notion, the cycle is where "are we ready to ship?" gets answered.

Predictable pricing as the team flexes

Engineers helping QA during a crunch don't spike the bill. Flat per-workspace pricing means adding occasional contributors costs nothing until you cross the user tier.

03What a CI/CD team week looks like

Engineers ship to staging behind a flag
QA (or a dev pairing as QA) runs an exploratory session in TestOrchestrator, logging findings as external references to GitHub issues
CI continues running its automated suite as it always has
Pre-release, run a regression cycle from the repository — manual + any automation results you've chosen to track here
Sign off the cycle, ship the release
The cycle stays as a record of what was tested

Roadmap note: A public ingest endpoint for posting CI results into TestOrchestrator runs is planned. Today, the value for CI/CD teams is the structured home for manual + exploratory + sign-off work alongside what CI already does.

04Related reading

05Frequently asked questions

If our tests are automated, do we still need test management?

Yes. Automation covers known regression. Test management covers everything else: exploratory testing, release sign-off, manual edge cases that aren't worth automating, third-party integration testing, accessibility checks, mobile-on-real-devices.

Does TestOrchestrator replace my CI test runner?

No. CI keeps running your automated suite as it does today. TestOrchestrator is the home for everything CI does not cover — manual cases, exploratory sessions, release sign-off — so the release-readiness conversation has a single source of truth.

Can we link test cases to Jira / GitHub issues for defects?

Yes — external references let you link cases and runs to issues in any system you use for defect tracking, so you do not duplicate defects across two tools.

How does it handle release sign-off?

Run a regression cycle pre-release, see what passed/failed, sign off explicitly. The cycle becomes the audit record for what was tested for that release.

Will TestOrchestrator integrate directly with CI later?

A public ingest API for posting CI results is on the roadmap. Today, manual cycles and exploratory sessions live in TestOrchestrator alongside any automated coverage you choose to track manually; deeper CI integration is planned, not currently shipped.