What to check in the week before your mini program launches

A week before a mini program launches, most features are already built. Testing at this point is not about discussing what to build, but confirming that what was built works in real conditions. We usually group this week's checks into five areas: real devices, poor networks, platform review, analytics tracking, and the plan for launch day.

Whether to build a mini program, H5 or an app is a question for the start of the project; see Mini program, H5 or app: which should come first. This article covers only the week before launch, once the format is settled.

1. Real devices: walk through the main flows on several real phones

The simulator in the developer tools differs from real phones in many ways. For testing, pick several common phones, including one with a small screen and one older model, covering both iOS and Android, and walk through the main flows from start to finish: open, log in or grant permissions, browse, order or book, pay, and view the result.

Look for three kinds of problem: whether layouts break on different screens, whether buttons are easy to tap accurately, and whether steps that call system features, such as permissions and payment, work on different OS versions.

2. Poor networks: how pages behave on a weak connection

Users won't always open the mini program on office Wi-Fi. Test on an ordinary mobile connection, in a spot with weak signal, or with the network throttling in the developer tools, and check a few things: how long the first screen takes to appear, whether images show placeholders while loading, whether failed requests show a clear message and a retry option, and whether repeated taps on submit actions cause duplicate submissions.

Also try cutting the network and restoring it, and see whether pages recover on their own.

3. Platform review: check against the rules first

A mini program has to pass platform review before it goes live, and one rejection often costs several more days. Before submitting, check against the platform's review guidelines: whether the category matches your business credentials, whether the privacy policy and permission explanations are complete, whether any pages contain test data, blank pages or broken entry points, and whether reviewers have a test account for content that requires login.

4. Analytics: make launch-day data usable

After launch, you'll want to see where users come from and at which step they leave, and that depends on analytics tracking. Before launch, trigger each key event once: opening the mini program, views of the main pages, taps on key buttons, and successful orders or submissions. Then confirm in the analytics dashboard that each event appears with the correct parameters. If you find a missing event only after launch, the data from your first users can't be recovered.

5. Launch day: write down roles and the rollback plan

One more task is to write down the launch-day plan: who submits for review, who watches for the result, who presses publish once it passes, and who walks through the main flows right after release. Also write down what to do if something goes wrong: which version you can roll back to, who has permission to do it, and who needs to be notified.

Summary

Testing in the week before launch comes down to five areas: real devices, poor networks, platform review, analytics, and the launch-day plan. Go through each before submitting for review, and you save a round of rework. For what to keep doing after launch, read What to keep doing after your website launches.

FIM has designed and developed mini programs for brands and for the automotive and finance industries, among others. See more projects on the Digital experience page.