How small QA teams set up test management from scratch (in an afternoon)
A practical walkthrough of setting up test management from scratch for a small QA team — what to define first, what to skip, and how to be running real cycles by the end of the day.
- Seven steps. Start at 1 pm, finish by 6.
- Use defaults everywhere. Pass / Fail / Blocked / Skipped covers 95% of cases.
- One project, not five. Add more when you have a real reason.
- End the day with one cycle run, results recorded, one exploratory session logged. That’s the bar.
01The afternoon, in order
Your afternoon, at a glance
Sign up and create your workspace
Sign up, name your workspace after your company. The Free plan covers 5 users, 2 projects, 200 active test cases, 1 GB.
Define your first project
A project is a unit of work that gets tested independently. For most small teams, “the product” is one project. Resist the urge to create five projects on day one.
Read the docs on ProjectsSet up statuses and lifecycles
Don’t reinvent. Use the defaults. Pass / Fail / Blocked / Skipped covers 95% of needs. You can add custom statuses later when you have a real reason.
Read the docs on StatusesBring your test cases in
You have two paths:
Clean up your spreadsheet (delete obvious dupes, remove anything that hasn’t been touched in 6 months), then create the cases directly in the test case repository. It’s manual but quick at this size, and it forces you to drop the cruft.
Contact support. We’ll load your cases into your workspace so you don’t have to retype hundreds of rows. A self-serve bulk-import UI is on the roadmap.
Whichever path: organise into folders by feature area, not by environment or release.
Read the docs on Test CasesInvite your team
Add the testers. Set access levels (regular user is fine for most). Skip custom roles on day one.
Read the docs on Users & AccessRun your first cycle
Create a cycle for your current release. Add a run inside it. Select the cases you want to execute. Run them. Record results.
This is the shift: from “we have test cases somewhere” to “we have a recorded run with attributable results.”
Read the docs on Cycles & Test RunsTry one exploratory session
Pick a feature that recently changed. Open an exploratory session with a charter (“explore the new search filter, looking for state issues”). Time-box 30 minutes. Log what you find.
Read the docs on Explorations02What to do tomorrow
You did the afternoon. The workspace exists, the cases are in, one cycle is recorded. Tomorrow is about making the habit stick — not adding features. In rough order:
The morning-after checklist
- Add a cycle template so future releases reuse the same structure.
- Set up a regression cycle as a recurring habit — weekly or per-release, your call.
- Review the dashboard with the team and decide what’s missing.
- Skip everything else until you hit a real reason to add it.
03The principle
The fastest test management setup is the one with the fewest configuration choices. You can add complexity later when you have a problem complexity solves. You can’t easily remove it once it’s there.
Most setups fail not because the tool is wrong but because day one tries to encode every edge case the team has ever encountered. Build for the 80% release. Add structure only when something specific demands it.
04Frequently asked questions
How long does this really take?
The mechanical steps are about an afternoon if your case set is small. The big variable is Step 4 — getting your existing cases in. If you have a thousand-row spreadsheet, that’s a separate workstream and we’ll do the import for you.
What should I skip on day one?
Custom statuses, custom roles, multiple projects, fancy folder hierarchies, integrations, dashboards. All of it. They’re useful tools — but only once you have a habit of recorded cycles. Add them as needs surface, not in anticipation.
What if my team is bigger than 5?
Free covers 5 users. Past that, Starter at $19/month flat covers up to 15 users; Pro at $79/month flat covers up to 50. You can still complete the afternoon on Free — invite the first 5, add the rest after. See our pricing post for the reasoning.
Can I do this for a project that’s already in flight?
Yes — most teams do exactly this. Pick your next release, set up the workspace around it (not historically), and run that release’s cycle through TestOrchestrator. The previous releases stay in the spreadsheet; new ones start clean.
Start the afternoon now.
Free plan, no card. Workspace stood up in 10 minutes; first cycle by sunset.