User Guide / Test Design

Test Design

Test Plans set the strategy, Test Suites organize the work, and Test Cases are the actual thing someone runs — plus how to get a test case reviewed and signed off before it's trusted.

Test Plans

A Test Plan is the "why and how" for a round of testing — usually tied to a release. It holds:

• Objectives, entry criteria, and exit criteria — free text describing what needs to be true before testing starts and before it's considered done.
• Environment — a short description of what you're testing against (staging, a specific build, etc.).
• Risk notes — anything worth flagging up front.
• A list of resources (people allocated to this plan) and linked test cases — the actual cases in scope, added the same way requirements are linked to test cases.
• Optional file attachments, if your test plan also exists as an external document (Word, PDF, etc.) you want kept alongside the in-app record.

A plan moves through Draft → Active → Completed. A project can have several plans at once — there's no one-plan-per-project limit.

Test Suites

Suites are folders for organizing test cases, nested as deep as you need. A suite is either a folder (just for grouping) or a leaf suite that actually holds test cases and carries a type:

Regression Smoke Sanity API UI Performance Security

You can clone or move a whole folder — including everything inside it — and the app blocks you from accidentally moving a folder into its own subtree.

Writing a test case

A test case lives inside a leaf suite and holds:

• Title, description, and preconditions.
• Steps — an ordered list of action / expected-result pairs. You can also pull in Reusable Steps from a shared project-level library instead of retyping a common sequence (like "log in as a standard user") in every case.
• Priority and severity (Low/Medium/High/Critical), an optional freeform category tag, and colored tags for your own grouping.
• Whether it's manual or automated, and its usability status: Draft Active Deprecated.

Every edit is kept as a numbered version with an optional change summary, so you can see exactly what changed and when. You can also duplicate a test case (steps, tags, and reusable steps come along; comments don't), bulk-update a set of cases at once, and export the list to CSV or Excel.

Reviewing and approving a test case

Alongside that Draft/Active/Deprecated status, every test case also carries a separate review status — one dial tracks whether the case is in use, the other tracks whether someone has signed off on it.

1. Open the test case and click Submit for Review — no form, it just moves to In review.
2. A reviewer opens it and clicks Approve, or Request Changes with a short explanation — shown to the author right on the test case, with the reviewer's name and the date.
3. A case sent back for changes can be edited and resubmitted, going straight back into In review.

The Test Cases list has a Review Status filter and column, so a lead can pull up everything waiting on review without opening each case one by one.

Next: Test Execution →