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 dialog and checklist of steps before testing starts; the QA Validation Runner panel rewrites =* Results= in place on save.

* 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

# The QA Validation Runner treats *any* non-empty Clients cell below as
# "this is a multi-client scenario" and then expects every step nested
# one level deeper, under a per-client heading (Runner source:
# QaValidationRunnerWidget.cpp, `multi_client =
# !find_field_value(*info, "Clients").isEmpty()`). 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) silently loads zero
# steps. 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 colours/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 dialog | (Qt dialog class 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 QA Validation Runner's 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. The panel writes each step's PASS/FAIL/PENDING outcome and
notes back as a =*** Result= child heading directly under it.

** Log in as <persona>

# This must be the scenario's first step (the QA Validation Runner
# panel doesn't track pass/fail for prose in * Context, only for
# * Steps entries) -- 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