Testing
Where the team writes down what it checks before it ships: the test cases with their steps, the suites they are filed in, the review that makes a case active, and the versions every save keeps; plans, runs, defects and the traceability matrix join as the module grows.
The test phase reads the planning record and the work the build phase shipped, and writes down
what the team checks before anything goes live. A test case is one scripted check: what it
proves, what must be true before it starts, the steps a tester walks or a script runs, the data
each step uses, and what should happen. Cases number on their own sequence (CRM-TC-45), carry
a kind and a priority, say whether a person or a script runs them, and pass the same
review a requirement does before a plan may pick them. Suites are the
folders the cases are filed in, nested by area and then by screen or flow, each tied to a
component when it covers one. Every save of a case keeps a version,
steps included, so a run can name the version it executed and a tester can put an earlier
script back.
| Piece | What it is |
|---|---|
| Test case | A scripted check numbered within the project: the objective, the preconditions, the kind and priority, how it is run and by which test in the automation suite, how long it takes, who owns it, the data and environment it needs, its status from draft to active, and its steps. |
| Step | One row of a case: what the tester does, what should happen and the data the row uses, numbered in order and kept inside every version of the case. |
| Suite | A named folder of cases, nested under another suite or at the root, tied to a component when it covers one; renamed or moved in place, never deleted while it still holds suites or cases. |
The cases link to what they check: a case verifies a requirement or a business rule and covers a story or a use case, through the same links every planning artefact carries. Test plans, runs with a result per step, defects raised from a failed step, the import of automation results, the traceability matrix and the client's UAT sign-off join this section as the module grows.
Where test cases meet the rest of the record
A case reaches review and active through an approval like a requirement does, so the people the project's policy names agree the script before a run executes it. A guest sees the active cases only, and the Links, Files and Discussion panels on a case are the same panels every planning artefact carries.
Test cases
Write a case with its steps and data, file it in a suite, name the test that automates it, put it to review, and keep every version it had.
Suites
Shape the folders the cases are filed in: nest them by area and screen, tie one to a component, and read how many cases each holds.
Approvals
How a case moves from draft to in review to active, who decides, and what a returned request does.
Traceability
The links that say which requirement a case verifies and which story it covers, read from either side.
How is this guide?
Last updated on
CI and deployments
What a pipeline reports about a deployment, how it shows on the environment with the version now running, the statuses a deployment moves through, who is told when one fails or reaches production, and the GitHub deployments that arrive on their own.
Test Cases
The Test Cases page of a project: what each case proves, what must be true before it starts, the steps a tester walks or a script runs, the suite it is filed in, how it is automated, the review lifecycle and the versions.