How do you document automation tests for QA?

You've built the automation, tested it a few times, and it seems to work. Six weeks later something breaks, and nobody can remember what was actually verified before launch. Sound familiar?

Good QA documentation for email automations doesn't need to be a 20-page spec sheet. It just needs to capture enough that someone else (or future you) can repeat the test and know what to look for.

Here's a simple structure that works in a shared spreadsheet or doc.

For each test case, record five things:

• Trigger condition. What fires the automation (form submission, tag applied, purchase event, date field)
• Test data used. The specific contact record or data values you used to fire it
• Expected behavior. What should happen, in what order, with what timing
• Actual result. What actually happened when you ran it
• Pass / Fail + Notes. Status and any observations worth flagging

That's the core. Everything else is optional detail.

Worked example: welcome automation triggered by form signup

• Trigger condition: Contact submits signup form with tag "newsletter_optin" applied
• Test data: Test address captain@deepcurrent.io, tag applied manually via test contact
• Expected behavior: Email 1 sends immediately. 3-day delay. Email 2 sends. Contact moves to "active" segment. No email sends if contact already exists in suppression list.
• Actual result: Email 1 sent within 2 minutes. Email 2 sent on day 3. Suppression check passed (test suppressed address received nothing).
• Status: Pass. Note: merge field {{first_name}} fell back to "there" correctly for a contact with no first name on file.

A few things are worth testing in almost every email automation, regardless of type. Check that your suppressions and exclusions are actually working, not just assumed. Test what happens when a merge field has no data (does it fall back gracefully or send a broken subject line?). Verify timing accuracy on your delays, especially for time-zone-sensitive sends. And check every link in every email in the flow, not just the main CTA.

It's also worth noting what counts as a separate test case. A different trigger condition, a different branch in a conditional split, a different contact attribute (no phone number, no company name, already unsubscribed). Each of those deserves its own row in your doc. Don't bundle them together or you won't know which path actually failed when something goes wrong.

One practical habit: add a "Last Tested" date column and update it whenever the automation changes. Automations drift over time. Data fields get renamed, segments get restructured, integrations update. A test that passed eight months ago isn't evidence that the automation still works today.

Before launch, your doc should also capture who signed off and when. It doesn't need to be formal. A name and a date in a shared sheet is enough. That tiny step creates accountability and gives you a starting point when something breaks in production.

And if your list quality is part of what you're trying to QA (stale data, missing fields, addresses that could cause bounces), our RME Clean service flags exactly those issues before they trip up your automation. Worth running before you sign off on a new flow.