First release vs ongoing testing: which mandatory tests repeat

The 46 published playbooks hold 406 mandatory tests between them, 7 to 11 per product type. Only 58 of those 406 done conditions name a recurring event as their trigger, such as "on every build", "after each release" or "a daily report". They sit in 31 product types. 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. The rest describe a state the product must reach once before launch.

This guide splits a playbook's section 4 into the two columns using that wording, and shows which test types repeat on which product types.

What repeats across product types

Counted over the 46 published test plans, by test type:

• Release smoke tests: mandatory on all 46 and first in order on all 46. 24 of the 46 done conditions repeat. 21 say only "on the release build", which is one build, and the desktop application names no trigger.
• Regression suite: mandatory on 17, repeating on 16. Only software as a medical device runs it once, on the release candidate.
• Data integrity and migration testing: mandatory on 27, repeating on 9, each tied to a bank statement, a ledger close, a rating data load, a renewal run, a pipeline run, an update or a day.
• Security scanning: mandatory on 42, repeating on 5, each a scan of every release or app build.
• Compliance checks: mandatory on 46, repeating on 3: the desktop application, where each build must pass notarization and store certification, the loyalty program app, where each change to earn rates, award prices or expiry is checked before release, and the insurance app, where each model change used in pricing or claims needs a sign-off.
• Analytics and event tracking tests: mandatory on 11, repeating on 1, the weekly review on the machine learning model service.

Of the 58 repeating done conditions, 11 name every build, 38 name each release, deploy, update, change, model version or onsale, 6 name a data event (a bank statement, a ledger close, a rating data load, a renewal run or a pipeline run), 2 name a daily report and 1 names a weekly review.

What never repeats in the plans

These test types are mandatory on several product types, and no published done condition for them carries a repeating trigger:

• End-to-end functional tests: mandatory on 43, repeating on 0.
• Penetration testing: mandatory on 39, repeating on 0.
• Integration tests: mandatory on 23, repeating on 0.
• Resilience and failure testing: mandatory on 20, repeating on 0.
• Payment and money-flow testing: mandatory on 17, repeating on 0.
• Accessibility testing: mandatory on 17, repeating on 0.
• Device and browser compatibility: mandatory on 15, repeating on 0.

Treat them as first-release gates. They come back when the change named in section 7 of your playbook happens, not on every build.

Procedure

1. Open section 4 of your playbook from the how-to-test index. Copy each mandatory item with its order, risk ids and done condition into a two-column sheet: "first release" and "ongoing".
2. Put release smoke tests at the top of both columns. It is order 1 on all 46 published plans, so it gates the first release and every later one.
3. Move an item into "ongoing" only if its done condition names a recurring event as its trigger ("on every build", "after each release", "after each partner bank statement", "a daily report"). Leave every other item in "first release". This is the same rule used for the counts above.
4. For a ledger or charge run that holds or moves customer funds, schedule its reconciliation as its own ongoing item. The neobank and peer-to-peer payment app reconcile after each bank statement, the crypto exchange after each ledger close and wallet movement, the ecommerce store runs a daily refund report and the subscription box a charge report after each renewal run, each tied to the money loss risk. The online marketplace runs a daily ledger report against the regulatory penalty risk.
5. If your plan repeats the regression suite, list the exact cases named in the done condition. The mobile banking app replays account switch, transaction list and statement download on every app update against the data breach risk and the records silently wrong risk; the social network rechecks privacy defaults for new teen and adult accounts after each release against the regulatory penalty risk.
6. For each first-release item, write the event that reopens it from section 7 of your playbook, for example a payment provider change for money-flow tests or a new supported OS for compatibility. Tie it to the event, not to a calendar date.
7. Attach the checklist for your type to the first-release column. It lists the same items in the same order as section 4.

Examples to compare

The loyalty program app has 11 mandatory tests, the most of any published type (shared with the mobile banking app and the trading app), and its release smoke test repeats "on every build". The telemedicine app writes its release smoke test "on the release build", so the same test type sits in the first-release column there. Reading both pages side by side shows that the column comes from the done condition, not from the test type name.