Ana içeriğe geç
Versiyon: Next

Best Practices

Guidance for getting the most out of TestPilot's plans, runs, executions, and reports.

Planning​

Name plans so they sort well​

Plan names appear in dropdowns on the Test Runs, Test Executions, Reports, and Issue Tracker pages, so a vague name costs you every day.

Include the cycle, the version or sprint, and the area:

  • Sprint 23 - Payment Module
  • Release 2.3.0 - Checkout
  • Hotfix 2.2.1 - Login

Avoid Project 1, Testing, or My Plan.

Give a plan an end date you mean​

Plan health and the Overdue state on both the plan list and the dashboard are derived from the end date. A plan with a date nobody intends to meet turns every dashboard red and stops being a signal.

Keep one plan per cycle, not per team​

The plan is the reporting boundary. Splitting one release across several plans means no single report covers it.

Structuring runs​

Split by purpose, not by size alone​

A run carries one type, one environment, and one set of platforms, so those are the natural seams:

  • A smoke run and a regression run, rather than one mixed run
  • A staging run and a production-verification run, rather than one run retagged halfway through

Use multi-platform runs deliberately​

A run can cover Web, Mobile, API, and Desktop at once. That is useful when the same cases genuinely apply everywhere.

When platforms need different cases or different testers, separate runs report far more clearly.

Clone instead of rebuilding​

Recurring cycles - a weekly smoke run, a per-sprint regression run - are quicker to Clone than to rebuild. Clone with all four options clear to get the same test cases with a clean slate of results.

Use the plan seed​

Test cases attached to a plan seed every run created inside it. Putting the standing regression set on the plan saves picking it again for each run.

Executing​

Work in one run at a time​

The execution screen is scoped to a single run. Switching runs mid-session loses your filters and your place in the list.

Filter down, then work top to bottom​

Use the status pills and the assignee filter to reduce the list to your own outstanding work, then use Next Test Case inside the execution form rather than returning to the list between tests.

Mark steps, not just the overall result​

Step-level marks are what make a failure reproducible later. They also set the overall result for you: any failed step marks the test Failed, all passed steps mark it Passed.

Record evidence while you have it​

Attachments are limited to 10 MB per file. A cropped screenshot of the failure with the error visible is worth more than a full-screen capture you have to compress.

Write the result description for someone else​

The Comments tab holds one description that is overwritten each time it is saved. Treat it as the final account of the run, not a running log:

  • Passed - a line confirming the scope you covered
  • Failed - what you expected, what happened, and where
  • Blocked - what blocks it, who is fixing it, and what you did instead
  • Skipped - why it did not apply to this run

Defects​

Raise the issue from the failing test​

The bug action on a failed row prefills the summary, priority, preconditions, the steps up to and including the failure, and the test's attachments. Filing the same bug by hand in Jira loses all of that, and loses the link back to the execution.

Pick the tracker once, per team​

An issue created in RabbitQA and then sent to Jira or Azure DevOps exists in both systems; the original is not converted. Decide up front whether your team's issues live internally or externally.

Verify device-specific bugs across devices​

For a bug raised from a device session, use Verify on Other Devices on the issue rather than opening a second bug. The verification record keeps the reproduction evidence attached to the original issue.

Reporting​

Report per run, and plan your runs accordingly​

A report covers one test run. If a stakeholder needs one report for a whole release, that release needs to be one run - or you need to summarize several reports yourself.

Check the two toggles before exporting​

Display Deleted Test Cases and Display Not Linked Project Issues change what the report contains, and the counts in the headings follow them. Set them the way you want before exporting, because the export reflects the current view.

Share Report copies a link that always shows current data. Export PDF or Export Excel freezes the numbers, which is what you want for a sign-off record.

Keeping the workspace tidy​

Archive finished plans​

Archiving keeps a plan's history without leaving it in the default Active Plans view. It is reversible.

Remove from Plan is not Delete​

Removing a run from a plan unlinks it and keeps the run. Deleting destroys it. Prefer removal whenever the run's results still matter.

Review Impact Analyzer suggestions before materializing​

Materializing writes real test cases into the shared repository, where every module sees them. Filter by priority, expand the rows, and drop anything that duplicates a case you already have.

Next steps​