Agree the result before choosing the test tool
Acceptance tests turn “the automation works” into a set of results that a buyer and builder can check together. Each test needs a starting condition, an action and an observable expected result. Agree those details before the build is ready for release.
A successful demonstration is useful, but it does not establish that missing fields, repeated requests or unavailable tools behave correctly. Write a short acceptance matrix for one defined workflow. Use it to decide whether that version is ready for its agreed use.
This guide covers release acceptance. For the checks that continue after release, use the automation monitoring guide. For the mechanics of safe retries, use the duplicate-action guide.
Give each test a rule, an example and evidence
Use a stable test identifier, such as T01, so that a failed run or screenshot points to one specific requirement. Record these fields:
- Rule: the business requirement this test checks.
- Given: the required starting data, permissions and destination state.
- When: the event or action that starts the test.
- Then: the exact output, status and important actions that must not occur.
- Evidence: the source identifier, run record, destination record and version tested.
- Decision: pass, fail, blocked or not run, with the reviewer and date.
The Cucumber Gherkin reference uses Given, When and Then to describe a scenario. You can use that structure in a document without installing Cucumber. An executable test also needs code that connects the steps to the system being tested.
Describe the business behavior
“The workflow created a draft card with the correct request identifier” is more useful for acceptance than “the third node turned green.” The Cucumber guidance on writing scenarios recommends describing behavior rather than the mechanics of an interface. Keep technical logs as supporting evidence, not the whole acceptance decision.
Fictional example: prepare a dispatch request
This example and every test below are fictional. A team wants incoming dispatch requests copied into an internal board. This first release prepares work for a person. It does not book a shipment, buy a label, change an order or send a customer message.
The fictional rules are deliberately small:
- R01: A request must have a request identifier, customer reference and positive whole-number package count.
- R02: Counts from 1 through 20 create one board card in
draft. Counts above 20 create one card inneeds_review. The exact count and identifiers must remain intact. - R03: Missing or invalid required fields create no board card. The source request stays available for correction, with a visible reason.
- R04: A repeated delivery of the same unchanged request must not create another card. A different request must not be mistaken for a repeat.
- R05: A connection problem must not be reported as confirmed completion. A person gets the evidence needed for recovery.
Each row starts with a clean test destination unless its starting condition says otherwise. Use synthetic identifiers such as TEST-SHIP-001. The reviewer compares the destination fields and status with the agreed rule. Counts alone cannot establish correct mapping.
Build a small matrix that includes the boundaries
| Test and rule | Starting condition and action | Expected result |
|---|---|---|
| T01 / R01, R02 | Valid identifiers; 1 package. Submit once. | Exactly one draft card. Request identifier, customer reference and count 1 match the input. No shipment or message. |
| T02 / R02 | Valid new request; 20 packages. Submit once. | Exactly one draft card with count 20. The upper draft boundary is included. |
| T03 / R02 | Valid new request; 21 packages. Submit once. | Exactly one needs_review card with count 21. It does not enter the draft route. |
| T04 / R01, R03 | Count is 0. Submit once. | No board card. The source shows the invalid count and remains available for correction. |
| T05 / R01, R03 | Customer reference is missing. Submit once. | No board card. The reason identifies the missing reference. No guessed replacement. |
| T06 / R04 | A confirmed draft card exists. Deliver its unchanged source request again. | The same request still has one card. Record the repeat without creating a second business action. |
| T07 / R04 | A card exists for one request. Submit a different request with the same package count. | A separate card exists for the new identifier. Matching counts do not make two requests duplicates. |
| T08 / R05 | The board accepts a card, but the acknowledgement is deliberately lost. | The run stays unconfirmed until destination evidence is checked. Recovery finds the existing card before another create attempt. Confirm one card after reconciliation. |
T02 and T03 test either side of the routing threshold. T04 tests an invalid lower value. Add the input types and limits your real system accepts, such as a decimal, text value or maximum field length. Do not silently change a package count to make a test pass.
T08 needs a controlled way to interrupt the acknowledgement after a destination write. A simple failure before the write does not test that same risk. If the team cannot create the required condition, mark the test blocked and explain the missing setup. Do not claim that a local mock proves a live provider integration.
Run the agreed path and keep the evidence
Use an isolated test board and synthetic source records. Confirm that the test cannot purchase anything, message a customer or change a production order. State who can authorize the test and who can review its result.
Run the same trigger path that the release uses. For example, n8n's Error Trigger documentation says that an error workflow responds to automatic executions, not a manually started workflow. If automatic error notification is part of the agreed scope, include a controlled automatic failure test.
Provider behavior also affects the matrix. Stripe's webhook documentation, for example, describes duplicate deliveries and delivery ordering limits. Test the guarantees of each actual connection. This fictional dispatch matrix does not establish that a Stripe or shipping integration exists.
For every result, retain the test identifier, input fixture version, workflow version, configuration, time and destination evidence. Redact credentials and customer data. A screenshot of an execution status is insufficient when the requirement concerns the destination record.
Separate pass, fail, blocked and not run
Pass means the observed result meets the agreed criteria. Fail means a tested result differs. Blocked means a required condition or dependency prevented a valid test. Not run means no result exists yet. Rejected bad input can be a passing negative test if rejection is the expected behavior.
Agree which tests block release. Do not average a critical failure into a favorable percentage. Record any accepted exception with its impact, owner and agreed limit. A blocked test stays visible; it does not become a pass because the demonstration looked good.
After a fix, repeat the failed case and the cases that could be affected by that change. If someone adds a new requirement, update the scope and criteria before testing it. Do not relabel a defect as a feature or rewrite an expected result only to match the current output.
Copy the acceptance worksheet
AUTOMATION ACCEPTANCE RECORD Workflow / scope / excluded actions: Business rules and identifiers: Workflow version / configuration version: Test environment / authorized destinations: Synthetic input fixture / starting destination state: Test owner / acceptance reviewer: TEST CASE Test identifier / linked rule: Given: When: Then: required fields / status / unique records / prohibited actions Expected completion window for this test: Observed result: Evidence: run identifier / destination identifier / redacted record Decision: pass / fail / blocked / not run Reason / issue owner / correction required: Reviewer / date: RELEASE REVIEW [ ] Every agreed rule has a relevant test. [ ] Success, invalid input and boundary cases are covered. [ ] Repeat delivery and uncertain outcomes are checked where relevant. [ ] The actual trigger and destination path are tested. [ ] Blocked and untested cases remain visible. [ ] Changes have the relevant repeat checks. [ ] Release blockers are resolved or explicitly accepted by the owner. [ ] Scope, version, evidence and acceptance decision are saved.
Bring this worksheet to a free workflow fit call. The Workflow Automation page explains the current starting scope and handoff. The tests for a real build are agreed around that specific process, access and risk.