Test management guide

Test management holds the test cases, plans and strategies that your team writes and reviews. It sits beside the test results that your runs report. It does not replace them, or the lasting records that link the same test across runs.

Cases, plans and strategies

Open Test cases in the sidebar (/test-management). Its tabs are Cases, Suites, Plans and Approvals. Under More you find Strategy, Duplicates, Audit log and Knowledge.

• To write a test case by hand, choose New test case. You need the Tester role or higher.
• To group cases for a release or a piece of work, choose New Plan on the Plans tab.

Each record has its own job. A test case describes a procedure and its expected result. A plan groups chosen cases. A strategy describes the wider testing approach. A test result in a run records what happened, and a lasting test record links the same test across runs.

Testers and above can import cases from CSV or Excel files as drafts. Each import runs as a trial first. It accepts:

• a file of up to 5 MB;
• a workbook that unpacks to at most 50 MB;
• up to 2,000 rows.

TestLookup stores a cell that starts with =, +, - or @ as text, so an Excel export imports back unchanged.

A project export, with or without run history, carries the test catalog to another TestLookup installation. There it is imported as a new project, and cases that were waiting for review arrive as drafts. Move projects and share reports describes the archive limits.

Catalog tools

• Library health: the server works this out for each project, across all its written cases. It measures automation against the project’s automation target, which is 60% by default and set by a QA lead. A project with no written case reads as not measured instead of 0.
• The case timeline: it brings together, newest first, a case’s versions, review requests and decisions, comments, plan and automated executions, defects, and links to requirements.
• Restore (Tester or higher): saves an older version’s content and classification as a new version. It never restores the status, the owner or the fingerprint.
• Bulk actions (Tester or higher): apply one action to up to 200 cases of one project. The action can be a status change, an owner, a priority, tags or a move to another suite. Each case gets its own version and audit row. If anyone below QA lead includes a move to retired, TestLookup refuses the whole request.
• Comments: accept @username mentions. A mention notifies an active project member inside the app only, with at most 10 mentions per comment.

Drafts and review

Write and revise test cases through their review workflow. Approving a test case does not approve, rewrite or reclassify earlier test results. Requiring review before a case becomes Active is a setting for each project, and it is off by default.

Who can do what:

• Every change to a case needs the Tester role or higher. A Viewer can read everything, and gets HTTP 403 on any change.
• Claiming and deciding a review needs a QA engineer or higher. Only the reviewer who claimed a review can decide it.
• Deprecating, reinstating and archiving a case need a QA lead and a reason.
• With review required, a QA lead or administrator may approve their own case, with a reason. A QA engineer can never approve their own case.

Editing never changes a case’s status. Each save sends the version the editor started from (expected_version). If someone else saved in between, the save answers HTTP 409 with the current version, and TestLookup does not retry it automatically.

With review on, a change to the steps, expected result or preconditions of an approved or active case marks it as edited after approval. TestLookup then offers a new review request.

Allowed transitions

Change a case’s status only through the actions the server offers for it, and send the version you read. These are the stages a case can be in: draft, review_requested, under_review, approved, active, rejected, needs_update, deprecated and archived. There are no shortcuts between them.

Features you can turn on or off

The newer lifecycle and AI-assisted writing depend on project settings and on feature flags (on/off settings). If an action is hidden or refused, it is turned off in your installation.

• Newer lifecycle: the test_case_lifecycle_v2 flag ships on. While it is off for a project, the status-change API and a bulk transition answer HTTP 404, and the older request-review and Delete (deprecate) actions stay.
• Requirement links: the test_case_requirement_traceability flag is on for new installations and off for upgraded ones. While it is off, every requirement route answers HTTP 404 with the message “Requirement traceability is off for this project.”, and the page hides requirements.

Where a case came from

Each case keeps a record of where it came from: its source references, how it was created, the decisions of its editors and reviewers, its versions and their times. A draft written with an AI model’s help goes through the same review as one written by hand.

Linking cases to test results

For traceability, you can link a test case to the lasting record of a test, or to its results. The two stay separate. A result keeps its own run, environment, CI details, evidence and outcome, and the case’s status is never copied onto it.

By default, a test leaves its suite’s change view as soon as one run no longer reports it. An administrator can turn off the suite_membership_legacy_writes flag, which is on by default. After that, a test leaves its suite only after the catalog’s deletion period.

To promote a test seen in your runs, you need the QA engineer role or higher. TestLookup links the test to the one written case with the same fingerprint, or creates a draft case with that fingerprint. If several cases match, TestLookup reports a conflict for you to resolve.

When automation stops reporting a test across the observation period, the test joins the orphan queue. There, a QA lead confirms its retirement with a reason. Neither record is ever permanently deleted.

Ownership and assignment

Two layers decide who owns a failure:

• Suite owners: a QA lead sets an owner for each suite, on Test cases › Suites.
• Ownership rules: set on Settings › Project › Ownership, they map tests to a service and a team. A rule can match by suite name, component or class, package, full path, or feature label. Importing GitHub’s CODEOWNERS file, which says who owns which folders, creates path rules and replaces the rules from the last import.

When a run is finalized, TestLookup assigns every failed or broken result that has no owner yet. It picks the first match from this list:

1. the suite’s owner;
2. the owner from a path or CODEOWNERS rule;
3. one of the project’s QA leads, including the default QA lead account, qalead-<project slug>;
4. the project’s manager;
5. one of the administrators.

Automatic assignment fills only results with no owner, so it never undoes a manual reassignment. If automatic assignment fails, the run is still stored.

We suggest this setup order:

1. Set suite owners for your top suites.
2. Add ownership rules for families of suites, or import CODEOWNERS.
3. Add team channels for the teams those rules name, under Settings › Project › Team channels.
4. Check the next run. Failures should reach the right Inboxes, and the team view shows anything that fell through to the QA leads.

The test catalog guide on GitHub has the full rules for each action.

Ownership and status values

Status values

Object	Values and what they mean
Test result	PASSED, FAILED, SKIPPED, BROKEN and UNKNOWN once stored. A JSON batch accepts the first four
Test run	IN_PROGRESS, PASSED, FAILED, STOPPED
File upload task	pending, then parsing, then ingesting, and finally succeeded or failed. The status expires after 24 hours
AI pipeline, as stored	pending, running, retry_wait, completed, passed, failed
AI pipeline, as shown	Shows in_progress for the stored pending, running and retry_wait. Keeps the names completed, passed and failed
AI review	pending, accepted, rejected or superseded. A completed pipeline does not mean that a person approved the report
Release decision	GO, NO_GO or NOT_EVALUATED. The field also allows CONDITIONAL_GO, but at this version only a single run’s decision can be Conditional GO. While review is enforced, an unreviewed decision shown outside TestLookup reads PENDING_REVIEW
Written test case	draft, review_requested, under_review, approved, active, rejected, needs_update, deprecated, archived

For the exact status changes allowed, see the workflow state and test-case lifecycle code, and the request and response data formats. A pipeline that finished with some steps skipped is still completed. Its details record the skipped steps, and there is no separate “partial” status.

Continue with the knowledge guide to draft test cases from your own documents.