Implementation and automation QA

6.1 Build from a platform-neutral specification

Document the flow before touching automation software:

• Trigger and eligibility.
• Consent source.
• Message order.
• Delay after each event.
• Branch and fallback logic.
• Exit and suppression rules.
• Required fields and default values.
• Link destination owner.
• Tracking parameters.
• Test contacts and test cases.

This specification becomes the reference when platform screens change.

6.2 Run content QA

Verify:

• The promised resource is the first primary action.
• Product name, contents, format, price, and terms match the live offer.
• Every claim is supportable.
• Fictional examples are labeled.
• Links say where they go.
• Preference and unsubscribe controls work.
• Sender and support routes are accurate.
• No draft notes, placeholders, or hidden test text remain.

6.3 Run logic QA

Test at least these scenarios:

1. Eligible new subscriber enters once.
2. Ineligible or suppressed contact does not enter.
3. Missing first name renders a natural greeting.
4. Existing customer follows the intended branch or exits.
5. Purchase during the flow triggers the intended exit.
6. Unsubscribe stops later messages.
7. Bounce or complaint suppression applies.
8. Tracking-disabled behavior still produces a coherent path.
9. Resource and checkout links resolve.
10. Time-zone and delay logic behave as documented.

6.4 Run rendering and accessibility QA

Test representative desktop and mobile clients when available. At minimum:

• Narrow and wide viewports.
• Light and dark display modes.
• Images enabled and blocked.
• Keyboard navigation in web-hosted versions.
• Screen-reader reading order for semantic templates.
• Plain-text fallback.
• Long names, missing names, and long URLs.

Save evidence of the test, the date, the tester, and the result.