ores.doc.agile.test_scenario

{{! GENERATED FILE — tangled from projects/ores.codegen/library/templates/doc.org. Edit the org source. }}
:PROPERTIES:
:ID: {{id}}
:END:
#+title: {{title}}
#+description: {{description}}
#+type: test_scenario
#+level: s1
#+filetags: {{filetags}}
#+target_dialog:
#+created: {{date}}
#+updated: {{date}}
#+environment:
#+todo: PENDING | PASSED FAILED
#+startup: inlineimages

This page documents a test scenario verifying [[id:{{parent_id}}][{{parent_title}}]] in [[id:{{story_id}}][{{story_title}}]]. It is filled in with the target screen and checklist of steps before testing starts; record the outcome by hand in =* Results=.

* Before you start

# System-readiness prerequisites (build, database state, provisioning)
# belong here, performed by *you* (build/recreate/provision yourself,
# never hand this to the tester) before opening the client with this
# scenario -- not folded into Step 1 as a conditional the tester has to
# evaluate. By the time the tester opens this doc, the system must
# already be in the state Step 1 assumes. See [[id:0A22B752-D5CF-4B36-8429-2950130AAABD][How do I ready up an
# environment?]] for the standard confirm/recreate/provision sequence.
# Delete this whole section if the scenario has no such prerequisites
# (e.g. it only reads static reference data).

- The database must be freshly provisioned (state what tenant/data the
  scenario needs, e.g. "via =--source acme=") — confirm via
  =compass db status=, recreating only if stale: =compass db recreate
  -y -k= then the relevant =compass shell -f= provisioning script.
  Confirm the run completes with no failed steps before starting.

* Scenario Info

# A non-empty Clients cell below means "this is a multi-client
# scenario": every step then nests one level deeper, under a
# per-client heading. Leave the cell genuinely blank — no placeholder
# text, not even "(single client)" — for the common single-client
# case; a non-empty cell here with flat `**` steps (no per-client
# `**`/`***` nesting) is a malformed scenario. Only put text in it
# when the scenario truly needs several running client instances at
# once (e.g. a NATS notification lands on a second instance) — list
# the instance labels, e.g. "blue, red", and nest every step one
# level deeper under a `**` heading per client as shown further down.

| Field         | Value                                   |
|---------------+------------------------------------------|
| Verifies task | [[id:{{parent_id}}][{{parent_title}}]] |
| Parent story  | [[id:{{story_id}}][{{story_title}}]]   |
| Target screen | (UI screen under test, if any.)         |
| Clients       |                                          |
| State         | {{state}}                               |

* Steps

Each step is its own heading — the title should be five to seven
words so it fits on one line in the step list
without wrapping or truncating (e.g. "Edit and save the record", not
a full sentence describing the whole operation). The body below the
title is a bullet-point checklist, not a prose paragraph: give the
tester every piece of context needed to execute that one step without
looking anything up elsewhere — what UI state must already exist,
exactly what to click or type, and exactly what confirms the step
passed. Record each step's PASS/FAIL/PENDING outcome and notes as
a =*** Result= child heading directly under it.

** Log in as <persona>

# This must be the scenario's first step (only * Steps entries
# carry a pass/fail outcome) -- name the *specific* persona this scenario
# actually needs: the exact account to log in as and its password
# (e.g. =tenant_admin@acme_corporation= / =Secure-Password-123=, or a
# specific staff username -- see doc/agile/versions/.../
# acme_corporation_holding_group/story.org for how generated staff
# usernames work, they're randomised per provisioning run so look one
# up via `accounts list` rather than assuming a fixed name). Assume
# the system is already in the state * Before you start establishes --
# this step is pure tester mechanics, not a readiness check. Never
# leave the tester to guess credentials -- and never copy this
# placeholder verbatim.

** (Next manual step the tester should perform.)

(Optional longer instructions for this step.)

# For a multi-client scenario (Clients field above is non-empty),
# nest steps one level deeper instead, under one sub-heading per
# client, e.g.:
#
#   ** blue
#   *** Open the counterparty lookup and search
#   ** red
#   *** Confirm the notification arrived and the list refreshed
#
# Single-client scenarios (the common case) keep steps as direct
# children of * Steps, as above.

* Results

| Field         | Value |
|---------------+-------|
| Status        |       |
| Completed at  |       |
| Branch        |       |
| Commit        |       |
| Worktree      |       |

* Notes