QA test plan

A preview of how this template lays out — the boards, their custom workflow states, and where the sample issues land. WIP caps show a badge.

• Smoke: sign-up → onboarding → first board

  Critical path. Block release if this fails.

  P02pt

• Regression: billing webhook updates plan quotas

  P13pt

• Edge case: import a 10k-issue workspace

  P25pt

These rules aren't created when you apply the template — they're recipes you can wire up in Settings → Automations once your board exists.

• When

  Test case moves to 'Failed'

  Then

  Create a linked bug issue and notify the owning team

• When

  All cases reach 'Passed'

  Then

  Post a release-ready summary to the release channel

To write, Ready to test, In testing, Failed, Passed. Failed being a column rather than a flag is the important choice: a failed test is not a finished test, it is an open loop that owes a linked bug and a retest. Treating pass and fail as symmetric end states is how regressions get closed as 'known issue'. The soft cap of six on In testing is the second opinion — a tester with fifteen cases open is context-switching, not testing.

1. 1.Scope the plan to a release, not to forever

   A test plan is for a specific release. An eternal board accumulates cases nobody runs, and its pass rate becomes meaningless because half the cases are stale. Clone the plan per release and prune as you go — a case that has passed twenty times unchanged is a candidate for automation, not for another manual run.

2. 2.Write cases somebody else could execute

   Preconditions, steps, expected result. The test for a good case is whether a colleague who did not write it gets the same outcome. 'Check billing works' is not a case; it is a reminder that will be interpreted differently every time it is run, which makes its pass history worthless.

3. 3.Mark the critical path explicitly

   Some cases block a release and most do not. Flag the handful that cover sign-up, payment, and core flows at top priority so that when time runs out — and it will — the cuts happen from the bottom rather than from wherever the list happened to end.

4. 4.Make a failure spawn a linked bug immediately

   Failed is a state that owes two things: a bug issue linked to the case, and a retest once the fix lands. The link is what lets you answer 'is this fixed and verified' in one place. Without it, the test plan says failed and the bug board says closed and nobody knows which is current.

5. 5.Use all-passed as the release signal

   When every case is Passed, the plan is the artifact that says the release is ready — a concrete, inspectable statement rather than someone's confidence. That is also what makes a decision to ship with known failures a deliberate, recorded choice instead of an accident.

This board encodes one opinion about how the work should run. Here is where that opinion is wrong and something else fits better.

• Your suite is mostly automated. Automated results belong in CI, where they run on every commit and report in seconds. Mirroring them onto a board is duplicate bookkeeping that will be out of date within a day.
• You need formal test management. Traceability from requirement to test to defect, versioned test runs across environments, and coverage reporting are what Xray, Zephyr and TestRail exist for. If an auditor will ask which requirement a test covers, use one of those.
• You run exploratory testing only. Charter-based exploratory sessions produce notes and discoveries, not pass or fail on predefined cases, and forcing them into a case pipeline destroys what makes them valuable.
• One developer tests their own work. Below a certain size the whole apparatus is overhead, and the honest answer is a short checklist per change plus decent automated coverage.

Honest comparisons, including where the other tool wins. Planoda is pre-launch, so nothing below is a benchmark — it is a description of how each product approaches this job.

• TestRail and Xray

  These are dedicated test-management tools and they do things this board does not attempt: reusable case libraries, test runs as versioned executions across multiple environments and builds, and requirement-to-test traceability matrices. This template tracks a release's cases as issues, which is a simpler and much narrower model.

  Where TestRail and Xray is better: If you need to run the same case library against three environments and report coverage per requirement, a real test-management tool is the correct choice and this board will frustrate you within a release or two.

• Jira

  With a test issue type and linked defects, Jira reaches roughly where this board sits, and it has the advantage of living next to the development work with strong linking semantics. Most teams that do this end up adding Xray or Zephyr on top anyway.

  Where Jira is better: Jira's issue linking — blocks, is-tested-by, relates-to — is richer than a simple link, which matters for tracing a failure back through the work that caused it.

• Spreadsheets

  The honest incumbent. Most manual test plans are a sheet with a row per case and a pass or fail column, and it works, right up until you need history across runs or a failure to be connected to the bug that fixed it.

  Where Spreadsheets is better: A spreadsheet is faster to write, trivially bulk-editable, and needs no adoption. For a single release with thirty cases, it is genuinely competitive with this board.