Test case management
Test cases in QAM Hub are real records with steps, expected results, custom fields and attachments, organized in suites and groups. Runs snapshot a scope, testers work through it, and every status change is kept with who set it and when.
Test cases & suites
Write structured test cases in suites and nested groups, with steps, expected results, attachments, tags and custom fields.
A test case in QAM Hub is a real record, not a spreadsheet row: numbered steps, expected results, preconditions, priority, tags, custom fields and image attachments on individual blocks. Cases live in suites, and suites are organized into groups and subgroups you can reorder by dragging, so the structure follows your product rather than the tool.
Every case gets a project-wide number that is never reused. That number is what automated reports, deep links and issue-tracker mirrors point at, so a link written a year ago still resolves to the same case.
- Suites, groups and subgroups with drag-and-drop ordering
- Bulk edit, move, duplicate, tag and delete across a selection
- CSV import and export, plus one-click migration from TestRail
- Stable per-project case numbers that survive deletions
Templates & custom fields
Define the fields your team actually fills in, and start every case from a template instead of a blank page.
Custom fields let a project capture what matters to it – component, environment, automation status, regression flag – as typed fields rather than free text buried in a description. Templates bundle a field layout and starting content so a new case begins half written, in the format the team already agreed on.
Field order, which built-in fields are visible, and which templates exist are all per-project settings, so two teams in the same organization can work differently without arguing about a shared schema.
- Typed custom fields, ordered per project
- Reusable test case templates with their own field sets
- Show, hide and reorder built-in fields
- Bulk-set custom values across a selection of cases
Version history & rollback
Every change to a test case is snapshotted, so you can see what it used to say and restore an earlier version.
Test cases change constantly, and "who edited this, and why does it no longer match the feature?" is a question spreadsheets answer with a revision log nobody can read. QAM Hub snapshots a version on every mutation, shows the history on the case itself, and restores any earlier version in one action.
Execution history is kept separately and just as carefully: every status change in a run, every checklist cell edit and every agent run result stays attached to the case, so the record of what was tested is not rewritten when the case text moves on.
- A snapshot per edit, with a history tab on every case
- Restore an earlier version without losing the newer ones
- Separate execution history per case, run and checklist cell
- Snapshotted titles in finished runs, so renames never rewrite a record
Attachments & image library
Attach screenshots to steps, expected results and executions, and reuse them across cases from a deduplicated project library.
Images attach to specific blocks of a case – a screenshot next to the step it belongs to, not dumped at the bottom – with captions and drag-to-reorder. Executions and agent runs take attachments too, so evidence stays with the result.
Behind them is a project-level library: every upload is hashed, so the same image used in twenty cases is stored once. Admins can replace a binary in place and every usage updates at once, run deduplication, and clean up assets nothing references.
- Per-block attachments with captions and ordering
- Project-wide image library with SHA-256 deduplication
- Replace an image in place across every case that uses it
- Attach from the library instead of re-uploading
Test runs
Pick the cases, assign testers, and record Pass, Fail, Blocked, Retest or Skipped with comments and screenshots.
A run is a snapshot of scope: choose suites, groups, tags or individual cases, assign executions per tester, and work through them. Each execution takes a status, a comment and attachments, and every status change is recorded with who set it and when.
Progress is visible while the run is still open – pass rate, remaining cases, per-tester load – and the pass rate deliberately excludes untested and skipped cases from the denominator, so an unfinished run never reads as a quality drop.
- Pass / Fail / Blocked / Retest / Skipped with comments and evidence
- Per-tester assignment and bulk status entry
- Run tags, kept in their own dictionary separate from case tags
- Full execution history per case, kept after the run closes
Defect tracking
Create or link an issue from the execution that found it, and see every defect back on the case, the run and the report.
When a test fails, the issue is created from inside the run – title, description, environment and the screenshot already attached to the execution – in Jira, GitHub, GitLab or Linear. An issue you already have can be linked instead.
The link is kept on both ends: the execution, the test case, the requirement it traces to and the defects report. Nobody has to remember which ticket belonged to which failing case.
- Create an issue from a failing execution or checklist cell
- Link issues that already exist, from any supported tracker
- Linked issues visible on cases, runs, requirements and reports
- A project-wide defects report with source and run filters