Test Cases

Test cases are the blueprint of manual tests, written in GIVEN-WHEN-THEN Gherkin syntax.

For detailed guidelines on writing test cases, see: Manual Testing Guidelines

Test Case Template

Use the template below to create a new test case:

##

- Description:
- Given
- When I
- Then I
- Execution Time:
- E2E Implementation Complexity:
- E2E Implementation Status:
- Regression Likelihood:
- Level of Criticality:
- Actual Result:
- Test Result:
- Notes:

Metric Clarifications

  • Execution Time:

  • Estimate the execution time from typical categories: 10s, 20s, 40s, 1min, 2min, 5min, 10min.

  • Always update the execution time field to reflect the maximum observed value during manual test execution.

  • E2E Implementation Complexity:

    • Estimate the time required to automate the test, using the same approach as issue complexity estimation.
    • Use hours (e.g., 1h, 2h, ...), and for anything above 8h, use "1 day" (1 workday = 8h).

  • E2E Implementation Status:

    • Use: Not Planned, Planned (#<issue_number>), Implemented.
    • If status is Planned, provide the corresponding issue number for reference.
    • If status is Implemented, the test is fully automated and no longer needs to be manually tested.

  • Regression Likelihood:

    • Use the following scale: Low, Medium, High, Recurring (for cases where regression has already happened).
    • "Low": Stable features with low change frequency, e.g., login/logout or map creation.
    • "Medium": Features updated more often, e.g., plant placement or plant search, where data changes can cause regressions.
    • "High": Features updated very frequently or based on dynamic data, e.g., move plant tests on the canvas or other fragile tests.
    • "Recurring" indicates the test case has required repeated adjustments due to changes (e.g., data changes, business logic updates, or shifting relationships such as between plants in heatmap tests).

  • Level of Criticality:

    • Use: Low, Medium, High, Critical.
    • Examples:
      • Low: Minor feature, little user impact if broken.
      • Medium: Important for some users, but easy to work around.
      • High: Major feature, significant user impact if broken.
      • Critical: Core functionality, would render software unusable or is safety critical, must never break.

Automation Candidate & Effort Analysis Guidance:

  • Consider execution time of manual tests – longer manual tests are good candidates for automation.
  • Balance test value vs. automation effort.
  • Don't estimate individual tests, but a whole group of tests.
  • For each manual test, estimate automation effort analysis based on the metrics above.