Martech QA Checklist: 12 Tests Before a Launch

A martech release is ready when the intended customer journey works across tracking, CRM, data models and messaging, with evidence for both success and failure cases. Builder QA checks the implementation against the agreement. User acceptance testing checks whether the business can operate it. Record the tested versions, unresolved issues, recovery path and accountable sign-off before widening production use.

Jafrin Akter AloLast updated 25 October 202614 min read

On this page

What is the difference between QA and UAT?

Quality assurance asks whether the build behaves as specified; user acceptance testing asks whether the intended users can complete the real job. Both need explicit expected outcomes, and neither is replaced by a successful connection screen.

Microsoft's implementation guidance likewise distinguishes unit, functional, process, end-to-end, user-acceptance and regression testing. Use that separation to organize the evidence; a martech release needs the connected customer journey rather than isolated green checks in every tool. Microsoft test-strategy checklist

The martech RACI names the accountable signer and operator. Our tracking implementation work should supply testable definitions and evidence while the business retains acceptance of the intended customer treatment and reporting meaning.

What belongs in the test plan before implementation starts?

Define scope by journey and outcome, then name the systems and versions that must support it. “Test HubSpot” is too broad; “an accepted demo request reaches the correct sales owner and appears once in the weekly request report” is testable.

Entry criteria should include a tracking contract, CRM property-ownership rules and the relevant metric definition. Where those are unresolved, record the missing decision before asking a tester to infer what success means.

Use a case record such as this original template:

case_id: demo-existing-contact
journey: accepted_demo_request
fixture: controlled_existing_contact
versions: candidate_release_reference
expected:
  source: one_accepted_submission
  crm: existing_contact_preserved_and_request_routed
  warehouse: one_row_for_the_submission_id
evidence_required:
  - source_acceptance_record
  - destination_record_and_property_history
  - model_row_and_reconciliation_result
tester_role: sales_representative
result: not_run
blocking_if_failed: true

The template is deliberately not marked passed. Record the actual result after execution and link the evidence for the candidate version. A screenshot from an earlier build is not proof that the current one works.

Use controlled identities and a test marker, with a plan to exclude synthetic activity from business reports and remove temporary access. Keep the permitted retention of test evidence separate from deleting operational test records. Do not copy sensitive production data into a test environment simply because a sandbox supports it.

Where can you test without changing the live workflow?

Use an environment appropriate to each system, and verify its outbound connections. A staging website or CRM sandbox is not isolated if its tags, credentials or message destinations still point at production.

Tracking environments and DebugView

GTM custom environments can publish a candidate container version to Dev or QA without changing Live. Live always points to the published container version. Shared preview is another way to inspect a candidate, but inspect its destination IDs and outgoing requests too. GTM environments

GA4 DebugView requires debug mode. Google says to remove the debug_mode field to disable it; setting it to false is insufficient. Events can be invisible in DebugView when client privacy controls apply or analytics consent is denied under Consent Mode. GA4 DebugView behavior

For denied-permission tests, inspect the actual consent state and network behavior against the approved design. Absence from DebugView is not proof that no request left the browser. Basic and advanced Consent Mode can have different expected requests; use the Consent Mode guide rather than a universal “zero Google requests” assumption.

CRM sandboxes

HubSpot's standard sandbox capability requires an eligible Enterprise subscription, with Super Admin access to create and deploy. Production integrations are not connected automatically, record IDs differ, and test email is limited to records sharing the email address of sandbox users. Its optional initial copy includes the most recently updated 5,000 contacts and associated records. HubSpot sandbox requirements

Connect test versions of integrations deliberately. A test that writes to a real Salesforce organization or production email audience has crossed the boundary even if HubSpot displays a sandbox banner.

Confirm the available licences and storage for the actual organization. Refresh intervals describe platform capability, not a recommendation to copy production data unnecessarily. Salesforce sandbox types

Warehouse models and CI

Build candidate models in a separate schema and run the cases that exercise their real business logic. dbt platform CI builds and tests changed assets and downstream dependencies in a PR-specific schema. It normally removes that schema on closure or merge, but custom schema-name behavior can affect cleanup. dbt continuous integration

dbt unit tests use static inputs to test SQL-model logic before full materialization and are intended for development or CI. They are available from dbt v1.8, with current engine and adapter requirements to check. Data tests query actual resources for failing rows. Neither type proves that an incomplete source extract contains every expected business record. dbt unit tests, dbt data tests

Teams operating their own dbt runtime need an equivalent isolated workflow rather than assuming the platform's PR automation exists automatically. Use the dbt implementation checks for incremental and full-refresh comparisons.

When no full sandbox exists

Use a deliberately restricted pilot only where the proposed change can be bounded safely: controlled records, suppressed outbound messaging, an isolated model and a tested recovery path. A low-volume test is still a real action if it reaches customers or overwrites production fields.

If a mass workflow, migration or integration cannot be isolated sufficiently, establish the needed test environment before release. A missing sandbox is not evidence that a risky change is acceptable to test broadly in production.

Which twelve cases catch failures across the whole journey?

Use the cases below for a hypothetical demo-request launch, adapting the expected behavior to the actual contract. They test a thirty-person B2B SaaS workflow from accepted form submission to CRM handoff, warehouse model and reporting.

The candidate path sends permitted acquisition events, creates or updates a HubSpot contact, routes the request, loads the relevant data into BigQuery and builds a dbt request model. Customer permissions and business-record processing have separate purposes; not every valid request must be sent to every advertising destination.

Source, tracking and delivery cases

Do not assume adding event_id gives every destination universal deduplication. The application and integration must implement the business occurrence rule, and the destination's own semantics still apply. Use common GTM failures and automated tracking QA for the tracking-specific detail.

CRM, model and customer-treatment cases

The HubSpot rollout checklist covers its platform gates, while Salesforce implementation mistakes explains why admin-only tests hide permission failures. For messaging, use the frequency and suppression guide.

Make every expected result observable. If the evidence is unavailable, mark the case blocked or incomplete; do not mark it passed because the report total looks plausible.

How can equal totals hide a failed release?

Equal totals can conceal a missing record and a duplicate. Reconcile the expected business keys before accepting a count.

For an original synthetic example, the source accepted demo-A, demo-B and demo-C. The candidate model contains demo-A, demo-A and demo-C.

The candidate has two of three expected IDs, or 66.7% observed coverage. A row-count-only assertion passes even though the business outcome fails. Keep source-only, destination-only and repeated-ID exceptions visible.

For the CRM, distinguish contacts from requests. Two requests from one existing person may correctly correspond to one contact and two request records. Comparing those counts without their grain creates a false defect.

In the hypothetical twelve-case release, suppose the double-submit case emits two generate_lead occurrences and the blank-source case overwrites an existing value. Both violate agreed requirements. Repair the occurrence control and field rule, then rerun the original cases and the related retry, existing-contact and reporting checks.

A sales request to add a required product-interest field is a different matter if it was absent from the agreed scope. Record it as a change request for the accountable owner. Do not quietly change the form during retesting and keep using the old acceptance evidence.

How should defects and change requests affect the launch decision?

Tie severity to business consequence and the agreed acceptance criteria. A defect breaks the agreement; a change request asks to alter it. Both need an owner, but they do not automatically have the same commercial or release treatment.

A reporting label can be material if it causes users to mistake revenue for cash or contacts for accounts. Do not label every presentation issue harmless merely because the code runs.

Keep a known-issues list with the tested version, impact, owner, accepted scope and review trigger. Acceptance of a bounded nonblocking issue is not permission to ignore a prohibited data flow or conceal an untested critical case.

After a repair, rerun the cases that could be affected. Avoid repeating the entire test suite without a reason, but do not test only the changed line when the fix alters identifiers, permissions or shared field behavior.

How should business users run UAT?

Have representative users perform their real tasks with their actual role permissions. The builder can prepare the script and data, but the business user must determine whether the workflow is usable and the outcome is understood.

For the demo-request journey, ask a salesperson to find the new request, identify its account and source, understand the priority, take ownership and record the next step. Ask the reporting owner to explain which requests the report includes and reconcile a sample to the source.

Record questions as well as failures. If the user cannot tell whether a field is current or whether another team owns the next action, the issue may be missing context rather than a broken API. Resolve it against the intended operating job.

Use a small representative group per role, sized to the workflow's variation. A single administrator cannot represent several permission profiles, regions or business units. Schedule users early enough that availability does not become pressure to approve an untested release.

What should the sign-off record contain?

Tie acceptance to the exact scope and version that was tested, with evidence and a recovery plan for each affected system. A generic email saying “looks good” leaves too much unspecified for a connected release.

Record:

• Journeys and destinations included in the release.
• Candidate GTM version, application commit, CRM configuration and model/job reference.
• Required cases and their actual results, including blocked or inapplicable cases.
• Evidence locations and the people who executed and reviewed the work.
• Known issues accepted by the appropriate owner, with bounded consequences.
• Pause, rollback and data-reconciliation procedures for each affected path.
• Accountable signer, authorized publisher and operating owner.
• The first production-check window and escalation conditions.

HubSpot's deployment guide limits a standard-sandbox deployment to 300 changes and says a started deployment cannot be canceled. Confirm the supported assets and recovery arrangement before treating Deploy as a reversible preview action. HubSpot deployment limits

Rollback has limits in every system. Restoring a container version cannot recall a sent message or undo a CRM write automatically. Reconcile in-flight queues and actual destination state, then perform any separately authorized repair. Keep the old and new writers from running in conflict during the switch.

The tracking-governance guide handles subsequent changes, and the ownership handoff transfers the operating responsibility. A CRM and warehouse implementation should include this evidence and acceptance record as a deliverable.

What must be checked after go-live?

Verify the released configuration and a controlled production sample promptly, then compare the first useful reporting period against the agreed source population. Production can differ from staging in credentials, permissions, traffic and connected versions.

Check the first day for missing outcomes, unexpected duplicates, rejected fields, unowned work and disallowed message paths. During the first relevant reporting week, inspect freshness and reconciliation using the output's freshness agreement. The appropriate window depends on the workflow; a weekly report does not justify waiting a week to detect a customer-message defect.

Remove temporary debug settings and access, and reconcile the cleanup of synthetic records with retained test evidence. Then hand ongoing checks to the marketing data-quality monitoring process, with a named operator who can act on the alert.

Read diagram as text

• Agree journey scope definitions and acceptance cases to Run builder QA in controlled environments.
• Run builder QA in controlled environments to All blocking cases have passing evidence?.
• All blocking cases have passing evidence? to Repair defects or resolve changed scope: No.
• Repair defects or resolve changed scope to Agree journey scope definitions and acceptance cases.
• All blocking cases have passing evidence? to Users perform UAT with their own permissions: Yes.
• Users perform UAT with their own permissions to The business owner accepts the tested outcome?.
• The business owner accepts the tested outcome? to Repair defects or resolve changed scope: No.
• The business owner accepts the tested outcome? to Record exact versions known issues and recovery authority: Yes.
• Record exact versions known issues and recovery authority to Release bounded scope and inspect production evidence.
• Release bounded scope and inspect production evidence to Production matches the approved contract?.
• Production matches the approved contract? to Pause affected paths and reconcile before recovery: No.
• Pause affected paths and reconcile before recovery to Agree journey scope definitions and acceptance cases.
• Production matches the approved contract? to Hand over the monitored workflow: Yes

Open full diagram

Bring the candidate workflow and failing cases to the $99 martech audit, or request a detailed implementation scope that includes cross-system QA, user acceptance and handover evidence.

Written by

Jafrin Akter Alo

Data Engineer and Co-founder at Martechdevs and Growth and Analytics Partners

Jafrin writes practical guides to marketing technology, customer data, analytics and AI workflows. Martechdevs is a Growth and Analytics Partners company.

View LinkedIn profile