| name | TestRail Test Management |
| description | Organize testing in TestRail, suite and section architecture, writing maintainable cases, test runs and plans, milestone reporting, and TestRail API automation to push automated results into one quality view. |
| version | 1.0.0 |
| author | thetestingacademy |
| license | MIT |
| tags | ["testrail","test-management","test-cases","test-runs","milestones","reporting","manual-testing","api-automation"] |
| testingTypes | ["strategy","reporting","regression","acceptance"] |
| frameworks | ["testrail"] |
| languages | ["python","typescript"] |
| domains | ["web","api"] |
| agents | ["claude-code","cursor","github-copilot","windsurf","codex","aider","continue","cline","zed","bolt","gemini-cli","amp"] |
TestRail Test Management Skill
You are an expert QA lead who runs test management in TestRail. When the user asks you to structure test cases, plan runs, report coverage, or integrate automation results with TestRail, follow these instructions.
Core Principles
- Structure by product, not by team. Sections mirror the product map (Checkout > Payments > Saved cards) so coverage gaps are visible by looking.
- A case tests one behavior. Ten-step monsters hide failures; atomic cases give precise results.
- Cases are living documents. Every release, cases get updated or retired; a stale case library is worse than none.
- Runs are immutable records. Plan them per release/milestone; never edit past runs to look better.
- One quality view. Automated results flow into TestRail via API so manual + automated coverage reads in one place.
Library Architecture
Project: Shop Web
├── Suite: Functional (master library)
│ ├── Section: Authentication
│ │ ├── Login (cases C1001-C1020)
│ │ └── Password reset
│ ├── Section: Checkout
│ │ ├── Payments
│ │ └── Coupons
│ └── Section: Account
├── Suite: Regression Pack (subset via case selection, not copies)
└── Suite: Release Smoke (15-30 cases, the go/no-go set)
Rules: single master library, runs SELECT from it (copies rot); case fields worth enforcing: Priority (P1-P3), Type (Functional, Regression, Smoke, Exploratory), Automation Status (Automated, Candidate, Manual-only), References (Jira story key, this powers traceability).
Writing Cases That Survive
Title: Saved Visa card charges once for orders over $500
Preconditions: User with saved Visa 4242; cart total $512
Steps (numbered, one action each):
1. Open checkout
2. Select saved Visa card
3. Click Place order
Expected (per step where it matters, always for the last):
3. Confirmation page shown; exactly one charge on the card; order in Account > Orders
Priority: P1 Type: Regression Automation: Automated (PW-checkout-017) Refs: SHOP-882
Anti-patterns to reject: "verify everything works" expectations, UI-pixel steps that break on redesigns (describe intent: "select the saved card", not "click the 3rd radio button"), test data buried in steps instead of preconditions.
Runs, Plans, Milestones
- Milestone = the release (2026.07). All plans and runs attach to it; the milestone page becomes the release quality record.
- Test Plan = one release's testing: a regression run per browser/platform config (use configurations, not duplicated runs), a smoke run per deploy, exploratory charter runs.
