What a smoke-test suite should cover
A smoke-test suite is not a full test automation project — it’s a tiny, repeatable check that tells you whether the integration is alive and doing the obvious job. For most small teams that means: can you create/update a record, does it appear in the target, are key fields correct, and do expected status transitions happen.
Cover three quick endpoints: write (create), read (exists and fields match) and a simple status or delete path. Platform examples: a HubSpot webhook that creates a contact, a Salesforce Flow that receives data, a Marketo/Pardot scheduled push — the principle is the same across tools.
Also add one failure-mode check: authentication/permission errors, schema mismatch (missing required field) or long queueing/delay. These are the things that surface customer impact fast and are cheap to test.
Build it in a day — practical step‑by‑step
- Morning (1 hour): Create a single Google Sheet (or Excel Online) as your control centre. Columns: canary_id, system_of_origin, expected_target_id, last_run, last_result, ttl (expire date), owner, notes. Keep it shared with the team and protected so only authorised staff can edit canary rows.
- Midday (2–3 hours): Create 3–5 canary records. Use a clear naming convention (e.g. canary-20260715-sales-01) and short lifetimes (24–72 hours). Enter their source IDs and expected values in the sheet. Where possible create them using the same channels as real data (HubSpot form, Salesforce create action, Marketo Smart Campaign) so you exercise the same path.
- Afternoon (1–2 hours): Schedule the checks. Use native schedulers in your platforms where available (HubSpot workflows with webhook actions, Salesforce Scheduled Flow, Marketo/Pardot recurring campaign webhooks). Each scheduled job should: 1) hit the target system to read the canary, 2) write the result back to the spreadsheet (or set a status field in the originating system), and 3) send an alert on failure. If you don’t have a native webhook action, update a single cell in the sheet manually as a heartbeat and let an already-running integration pick it up.
What to assert, how to alert, and a lightweight rollback checklist
Assert only what matters operationally: existence, 2–3 critical fields (email/status/product-code), and that timestamps advance or transitions occur within acceptable time. Keep assertions simple so false positives are rare.
Surface failures in the tools your team uses: a Slack message to an ops channel, an email to the integration owner, and a flagged row in the control sheet with a short human-readable error. Platforms like HubSpot, Salesforce, Marketo and Pardot can send the alert natively; otherwise use the sheet as the single source of truth and enable its notification rules.
If a smoke test fails, follow a short rollback/checklist: 1) Pause the problematic scheduled job (or disable the integration), 2) check auth keys and last deploy notes, 3) run the canary manually to capture error messages, 4) if the change was a deploy, roll back the last release or feature toggle, and 5) communicate to the team with a brief status update and next steps. Keep that checklist one page and practised once so everyone knows the first three actions to take.
If you’d like a quick review of your sheet and alerts, Optira can give a short, practical checklist to tighten the first-day setup without adding new paid tools.