Use this feature risk worksheet
Describe the feature as an action and a state change, not just a screen. A saved payee touches identity, approval, storage, and later payments. List where the new field appears in the database, logs, export, analytics, and support tools.
| Item | Check or owner | Evidence |
|---|---|---|
| New actor | Who gains access? | Test role and tenant boundary |
| New data | What becomes visible? | Test export and log paths |
| New state | What can move money? | Test repeat, failure, and rollback |
| New integration | Who can call back? | Test identity and replay |
Test and retest
Test an allowed user, a user from another account, and a stale session. Change one field after approval and send two requests together. Simulate a provider error after the internal state changes. The release record should say which checks passed and which integration paths were left out.
Evidence to keep
Use a risk worksheet with one row for each new capability, not one row for each screen. Saving a payee, approving a transfer, and releasing a payment are separate capabilities even if they appear in one flow. For each, record caller, object, allowed state, forbidden state, and evidence. A test plan passes review when every state-changing capability has at least one allowed case, one denied role case, and one failed downstream case. This keeps the plan focused on product rules rather than a long list of generic scanner checks.
Turn a feature story into tests
Synthetic feature: a customer can schedule a recurring transfer. Write one normal story and four failure stories before coding. A normal request creates one schedule owned by that customer. A second customer cannot read or change it. A request with a changed payee after approval must ask for approval again. Two workers firing at the scheduled time must still create one transfer. A provider timeout must leave the schedule in a clear pending state that can be reconciled.
For each story, name the actor, starting records, action, expected API result, and expected ledger or provider result. Run the tests on the deployed candidate, not just a local handler. Save scheduler job IDs and provider references so a reviewer can find the outcome. If the team cannot reproduce the timeout safely, mark that story untested instead of marking the feature secure. The OWASP business logic guidance treats workflow order and state transitions as test targets.
Give each recurring payment an identity
For the recurring-transfer example, give the schedule a stable ID and each due occurrence a unique operation ID derived from that schedule and due instant. Two workers handling the same occurrence must claim the same intent; two different due dates must remain separate payments. Save the approved payee version and amount on the occurrence before release.
Test cancellation at three points: before the due job runs, after it creates an intent, and after the provider accepts. Define which point stops release and which point needs a separate reversal or support action. Cancelling a schedule cannot undo a transfer the provider already made. Recheck the schedule state inside the release decision, then inspect queue, provider, and ledger results rather than the schedule badge alone.
Cut the response after provider acceptance. Keep that occurrence pending until its original provider result is found. A confirmed rejection permits reservation release under the policy; a timeout does not. Save a failed case for each boundary in the release ticket, name its owner, and set the switch that pauses future occurrences. Run the allowed case too so the guard does not block all scheduled payments.