A rendered preview tells you the template compiled. It says nothing about whether the journey fires, the data resolves, or the right person receives anything at all.
Marketing platforms make previewing easy and testing hard. The preview pane renders in a second. A genuine end-to-end test needs representative data, real timing and somebody willing to give up an inbox.
A preview confirms the template parses, the layout holds, and personalisation resolves against whichever sample record the platform picked. That is worth having. It is also a small fraction of what can go wrong.
It does not exercise entry criteria, decision splits, wait steps, exit conditions, suppression logic, send-time rules, link tracking, or how the message behaves when the data is not tidy.
The gap matters because previews are reassuring. A stakeholder who has seen a preview believes they have seen the campaign.
Sample records are usually clean: every field populated, sensible names, one segment each. Production data is not like that, and the failures that reach customers come from the difference.
Build a test set deliberately: empty optional fields, apostrophes and non-ASCII characters in names, duplicate records for the same person, someone who qualifies for two journeys at once, someone who unsubscribed yesterday.
A test set assembled from real edge cases finds more in an afternoon than weeks of previewing clean records.
Most production surprises come from journey mechanics rather than content: re-entry rules, overlapping entry criteria, what happens when someone meets an exit condition mid-wait.
Waits are where testing quietly gets skipped, because nobody wants to sit through a three-day delay. Shortening waits for testing is reasonable, but it means the timing logic itself went untested — worth noting rather than pretending otherwise.
Test at least one journey end to end at real durations before go-live, even if only one.
Link tracking rewrites URLs, and a link that works in preview can break once the tracking wrapper is applied. The unsubscribe path often behaves differently from a real send than from a test send.
Send at least one message from the new platform to a real inbox you control, then click every link in it, including the unsubscribe. It is a fifteen-minute check that finds problems no amount of previewing will.
Without written acceptance criteria per journey, “tested” degrades into “somebody looked at it and it seemed fine”, and nobody can say afterwards what was actually verified.
The criteria do not need to be elaborate. Which paths were exercised, with what data, and what the expected outcome was. The value is that it is answerable months later, when something goes wrong and the question is whether this case was ever covered.
Write acceptance criteria per journey before the build starts, and make sure at least one real message reaches a real inbox from the real platform before go-live. Preview is a spell-check. It is not a QA process.