{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

Format{{ resultsReady ? formatLabel : '—' }} Risk cases{{ resultsReady ? computation.values.risk_count : '—' }} Review cues{{ resultsReady ? computation.values.review_count : '—' }}
Use a ticket title, requirement name, or product flow reviewers will recognize.
Optional, but recommended when the pack will enter a managed test suite.
The selected layer changes generated execution and evidence language.
Use the convention expected by the destination test-management workflow.
Describe the behavior to verify instead of saying it should work correctly.
Use one verifiable starting condition per line.
Concrete values make a case repeatable instead of merely conceptual.
Two to twelve concise actions usually make the primary case easiest to execute.
Use a source-backed oracle that can be compared with actual behavior.
Keep cleanup and resulting state separate from action steps.
Each unique line becomes one focused secondary case.
The format changes the readable pack while preserving the same canonical case rows.
Letters, numbers, underscore, and hyphen are retained and normalized to uppercase.
Whole numbers from 1 through 999.
The neutral default is off. Enable it when accessibility and observability belong in this pack.
{{ include_quality_cases ? 'Included' : 'Not included' }}
{{ computation.values.case_pack }}

The chart renderer is unavailable. Coverage counts remain available in the summary and case matrix.

Review pointStatusEvidenceNext actionCopy
{{ row.point }}{{ row.status }}{{ row.evidence }}{{ row.action }}
Feature Flag Cleanup Checker Review feature flag inventories for stale rollouts, usage gaps, code references, dependencies, ownership gaps, and archive-ready cleanup work.
Regex Sample Matches Checker Test a JavaScript regex against lines that should match or fail with whole-line checks plus match evidence, input caps and backtracking guards.
DNS Wildcard Behavior Check Test DNS wildcard behavior with random public resolver probes and distinguish broad matches, branch boundaries, mixed views, and cached negatives.
Acceptance Criteria Generator Draft testable acceptance criteria from behaviors and edge cases, then check Gherkin or QA handoff wording for missing coverage and vague terms.

A test case turns a behavior claim into a repeatable check. It identifies the starting state, the data, the actions, and the evidence that separates a pass from a failure. Without those parts, two testers can follow the same title and still test different things.

The expected result carries most of that decision weight. It should name something observable, such as a response code, message, stored value, permission denial, notification, or audit event. Phrases such as “works correctly” leave the tester without a dependable test oracle, which is the source used to judge actual behavior against intended behavior.

Precondition
A role, record state, configuration, environment, or dependency that must exist before the first action.
Test data
The concrete account, ID, payload, file, or fixture needed to repeat the check.
Expected result
The observable evidence that proves the behavior matched the governing requirement.
Postcondition
The state or cleanup that should remain after execution.

Format changes presentation, not the behavior under test. A manual case emphasizes execution detail, a Gherkin scenario expresses context and outcome with structured keywords, and an automation handoff adds setup, assertions, and cleanup guidance. All three still need a narrow objective and a trustworthy oracle.

Useful coverage follows risk rather than row count. Permission failures, invalid input, limits, duplicate actions, retries, timeouts, and recovery paths often reveal faults that a happy path misses. Each risk belongs in its own focused case when combining conditions would make a failure hard to diagnose.

A well-formed pack is review material, not proof that the requirement is correct. Product owners, developers, and testers should still confirm the source rule, environment, fixtures, and expected evidence before cases enter a managed suite or automated pipeline.

How to Use This Tool:

Define one primary behavior first, then add only the risk conditions that deserve separate execution.

  1. Enter the Feature or requirement, a precise Test objective, one or more Action steps, and an observable Expected result. Add a Reference ID when the pack must trace back to a story, risk, or release item.
  2. Choose the Test layer and Priority, then supply any preconditions, concrete test data, and postconditions needed by another tester. The layer changes setup and evidence language for UI, API, workflow, regression, or exploratory work.
  3. List one negative or boundary condition per line. Select manual, Gherkin, or automation handoff output, and set the case prefix and starting number to match the destination suite.
  4. Review Coverage mix and Quality review before using the pack. Resolve missing setup or data, vague expected wording, weak risk coverage, or absent traceability against the real requirement.

Interpreting Results:

The generated case count describes the pack, not its quality. One primary case is always present, each unique risk line adds one case, and the optional quality setting adds accessibility and observability cases.

  • Case pack is the selected readable representation. Confirm its wording against the requirement and team vocabulary.
  • Coverage mix separates primary, risk, and optional quality cases. A larger risk count does not prove that the important risks were chosen.
  • Quality review applies compact drafting heuristics. A passing row means the supplied text cleared that check, not that the product behavior has been independently verified.
  • Review cues means at least one setup, step, oracle, risk, or traceability check still needs attention. Ready for review means those built-in checks passed and human review remains the next step.
  • Use synthetic accounts, IDs, payloads, and tokens whenever possible. Copied or downloaded case packs repeat the test data supplied.

Technical Details:

The governing mechanism is an ordered rule set rather than a scoring formula. Inputs are cleaned, repeated lines are removed case-insensitively, a canonical case list is built, and that same list is rendered into the selected format.

Rule Core:

Rule Exact behavior
Case construction One primary row is followed by one row for each unique negative or boundary line. Enabling quality coverage appends exactly two rows for accessibility and operational evidence; their P0 priority is reduced to P1.
Risk classification Permission, role, access, authentication, token, and session terms are Security. Timeout, retry, network, latency, race, duplicate, and common 4xx or 5xx retry codes are Resilience. Limit, empty, invalid, expired, retention, and similar edge terms are Boundary. Checks run in that order; remaining lines become Negative or Exploratory.
Line limits Only the first 20 unique preconditions, data rows, actions, postconditions, and risk lines are retained. Duplicate comparison ignores letter case.
Identifiers The prefix keeps letters, numbers, underscore, and hyphen, becomes uppercase, and falls back to TC. Numbers start from 1 to 999 and display with at least three digits.
Step review Two to twelve primary actions pass the granularity check. One action or more than twelve produces a review cue.
Setup and traceability Setup passes only when at least one precondition and one test-data row are present. A missing reference ID produces Review.
Risk review Zero risk lines fails the coverage check, one produces Review, and two or more pass. The rule measures supplied lines, not real risk completeness.
Oracle review Generic terms such as “works,” “correctly,” “as expected,” or “successfully” produce Review. More specific wording can pass while still being factually wrong, so the source requirement remains authoritative.

Transformation Core:

Format Transformation
Manual Each row becomes a case with metadata, preconditions, data, numbered steps, expected result, and postconditions.
Gherkin Shared preconditions become a Background when present. Actions map to When and And; the expected result maps to Then.
Automation handoff Each row becomes setup, deterministic data, action sequence, assertions, and cleanup guidance shaped by the selected test layer.

Risk wording also selects a reusable expected-result pattern. Security cases require denial, no unauthorized state change, and traceability. Resilience cases require safe retry or recovery without duplicate side effects. Other negative and boundary cases require safe blocking or validation. Replace any generic generated sentence when the governing contract requires a more exact oracle.

Worked Examples:

Retrying a failed export

A primary objective can verify that an administrator retries a failed export without creating a duplicate file. Separate risk lines for missing permission and a repeated retry produce Security and Resilience cases. The pack is useful only after the expected message, stored state, retry event, and duplicate-prevention rule are confirmed from the real product contract.

References: