When automation is worth it: follow the repeating done conditions

The case for automating a test rests on how often the plan reruns it. Across the 46 published test plans, 58 of the 406 mandatory done conditions name a recurring event as their trigger ("on every build", "after each release", "after each partner bank statement", "a daily report"). A done condition repeats when it names a recurring trigger: each build, release, deploy, update, change, run, statement, ledger close, data load, model version or onsale, or a daily or weekly report. Those 58 sit in 31 product types. Those 58 are where this site's data supports automation; the rest run once per first release or per named change.

Which tests repeat

The plans assign these tool classes: of the 58, 15 name browser automation, 14 test management, 11 mobile automation, 11 data validation, 3 a DAST scanner, 2 a SAST scanner and 2 an API client.

Which risks the repeating tests cover

Risk ids on the 58 repeating items: records silently wrong on 16, regulatory penalty on 14, data breach on 13, money loss on 13, store rejection on 12, wrong numbers acted on on 9, fraud or abuse on 4, user harm on 3, outage under load on 2, third-party dependency failure on 2 and lost user actions on 1. Each count links to the risk page with its evidence.

Which tests the plans never repeat

No published done condition repeats for end-to-end functional tests (mandatory on 43), penetration testing (39), resilience and failure testing (20), payment and money-flow testing (17), accessibility testing (17), device and browser compatibility (15), exploratory testing (11) or performance and load testing (9). On the current plans, these are run when the first release or a named change calls for them. Exploratory testing is unscripted by definition.

Procedure

  1. Open section 4 of your playbook from the how-to-test index and mark each done condition that names a recurring event as its trigger. These are your automation candidates; the others are not, on the current plan.
  2. Automate the release smoke test first where it repeats. The ride-hailing app runs it "on every build" with a test rider and a test driver; the mobile banking app runs it "on every store build" against the store rejection risk and the data breach risk.
  3. Automate the regression cases next where the plan repeats them. The clinical trial management software reruns validated scripts for edit checks, signatures and audit trail before each release; the machine learning model service scores each new model version on the same held-out set as the live one, against the wrong numbers acted on risk.
  4. For a ledger reconciled on a recurring event, script the comparison and its difference report: the done conditions on the neobank and peer-to-peer payment app already require "a run that finds a difference lists it by customer" (or "by user"), which is the output the script must produce, against the money loss risk.
  5. Wire the security scan to the release or app build where the plan repeats it, as the mobile banking app, neobank, peer-to-peer payment app, crypto exchange and messaging app do, and use the pass rule written in the done condition.
  6. Keep the never-repeating tests out of the per-build pipeline and run them when the first release or a change named in section 7 of your playbook calls for them. If section 7 of your playbook adds a cadence for one of them later, apply step 1 to it again.
  7. When a section 5 condition becomes true and a test moves into section 4, read its done condition for a repeating trigger before you decide to automate it.