Regression before a promotion: the checklist that saves the launch

A promotion is a release with a deadline that cannot move and traffic that cannot be predicted. Regression before it differs from the usual kind: the suite is shorter, priorities are stricter, and the run ends not with a report but with a ship / no-ship decision.

What goes into the promotion regression suite

A full regression before every promotion is neither needed nor possible on the timeline. What is needed is a suite built from the money: flows where the user pays, receives a bonus or reads the terms. Everything else is on a best-effort basis.

• Sign-in and sign-up: a new user, a returning one, account recovery, geography and age restrictions if any.
• Promotion mechanics: applying a promo code or bonus, activation conditions, validity period, no repeat use, display in the cart and in history.
• Payment: every connected method, cancellation, gateway timeout, repeated payment, refund.
• Promo page and banners: links, buttons, copy in every language, mandatory disclaimers, correct rendering on narrow screens.
• Notifications: emails and pushes about the start, reminders, confirmations — content and links.
• Account: the credited bonus, participation status, transaction history.

When to run

1. A week before: get the promotion plan, update the suite for its mechanics and languages, prepare test accounts and promo codes.
2. Three days before: a run on the test environment, LQA of promo materials in the interface, creative checks against the requirements checklist.
3. A day before: regression on pre-production with live settings on iOS, Android and major browsers; a report with prioritized defects.
4. Launch day: a quick check of the hot flows right after the promotion goes live and after every hotfix.

How to prioritize defects

Before a promotion a simple scale applies. Blocker — the user cannot pay, receive the bonus or see the terms: fixed before launch. Critical — the flow works but with an error in the amount, the terms copy or a notification: fixed before launch if there is time, otherwise closed with a workaround and an announcement. Everything else goes to the backlog after the promotion. Priority disputes are settled by one person — the promotion owner, not the chat.

Typical mistakes

• A run on the test environment with test settings: limits, dates and promo codes are different in production.
• Checking only on a flagship device: half the audience is on budget Android and narrow screens.
• Promo copy checked in a spreadsheet, not in the interface: clipped terms and wrong amounts.
• Nobody on duty in the first hours: users find the defect, not the team.
• Fixes to production without re-checking: one thing fixed, payment broken.