Lesson 04 — Release Readiness and Mobile QA Checklists

Title: From test ideas to release confidence
Description: Learn how to turn mobile testing knowledge into a practical release process. This lesson covers release checklists, smoke vs regression scope, bug reports, crash and analytics signals, accessibility checks, localization risks, and the final go/no-go decision before submitting to app stores.

Why it matters for QA: Mobile releases are expensive to fix after they reach users. A good QA engineer does more than execute test cases: they help the team understand release risk and make confident decisions.

1. Release testing is risk management

You cannot test everything on every device. The goal is to reduce the biggest risks before users see the build.

Ask:

• What changed in this release?
• Which user flows make money or protect trust?
• Which devices and OS versions do our users actually use?
• Which areas broke recently?
• What is hard to fix after app store submission?

This mindset helps you choose the right tests instead of blindly running a huge checklist.

2. Smoke vs regression vs exploratory testing

Example smoke set for a shopping app:

1. App launches without crash.
2. User can log in.
3. Product list loads.
4. User can add item to cart.
5. User can reach checkout.

Keep smoke small. If smoke takes hours, it is no longer smoke.

3. Mobile release checklist

Use this as a starting point and adapt it to your product.

Build and install

• Correct build number and version are visible.
• Fresh install works.
• Upgrade from previous production version works.
• App can be installed from the expected distribution channel.
• App launches after device restart.

Core flows

• Login / logout.
• Registration or onboarding.
• Main business flow.
• Payment or subscription flow if applicable.
• Settings and profile updates.
• Error states for failed API calls.

Mobile-specific behavior

• Permission grant and deny paths.
• Background and foreground transitions.
• Offline and slow network behavior.
• Push notification receive and tap behavior.
• Deep links open the correct screens.
• Orientation changes if supported.

Device coverage

• Latest iOS and one older supported iOS.
• Latest Android and one older supported Android.
• At least one budget Android device.
• Tablet if the app supports tablet layout.
• Real device for hardware features.

4. Accessibility basics

Mobile accessibility is not optional quality. It affects real users and often improves automation too.

Check:

• Buttons and inputs have readable accessibility labels.
• Text is readable with larger font settings.
• Tap targets are large enough for fingers.
• Color is not the only way to communicate status.
• Screen reader order follows the visual order.
• Important images have meaningful descriptions or are marked decorative.

Automation benefit: good accessibility labels often become stable Appium locators.

5. Localization and content edge cases

Even if your first release is English-only, test content variation.

Examples:

• Very long names.
• Non-Latin scripts such as Arabic, Armenian, Chinese, or Hindi.
• Right-to-left layout if supported.
• Emoji in profile names or messages.
• Different date and number formats.
• Small screens with large font settings.

Mobile screens have limited space. Text that looks fine in English may break in German or Arabic.

6. Crash and analytics signals

A QA engineer should know where production quality signals come from.

Common tools:

• Firebase Crashlytics.
• Sentry.
• Datadog RUM.
• App Store Connect crash reports.
• Google Play Console Android vitals.

Before release, check:

• No new high-volume crash appears in internal testing.
• Startup crash rate is acceptable.
• ANR rate on Android is not increasing.
• Critical screens have analytics events firing.
• Logs do not expose secrets or personal data.

7. Writing a strong mobile bug report

A good bug report lets a developer reproduce the issue quickly.

Include:

• Build version and environment.
• Device model and OS version.
• App install type: fresh install or upgrade.
• Network state: WiFi, cellular, offline, throttled.
• Preconditions.
• Exact steps.
• Actual result.
• Expected result.
• Screenshot or video.
• Logs or crash ID if available.

Example:

Title: Android login screen loses typed email after rotation

Build: 2.4.0-beta.3
Device: Samsung Galaxy A52, Android 12
Install type: fresh install
Network: WiFi

Steps:
1. Open the app.
2. Go to Login.
3. Type qa@example.com into Email.
4. Rotate device to landscape.
5. Rotate back to portrait.

Actual:
Email field is empty.

Expected:
Email field keeps qa@example.com after rotation.

Attachments:
video, logcat excerpt

8. Go / no-go recommendation

At the end of release testing, avoid vague status like "looks okay." Give a clear recommendation.

Example:

QA recommendation: No-go

Reason:
P1 checkout regression on Android 12 blocks payment completion.

Tested:
Smoke passed on iPhone 14 iOS 17 and Pixel 7 Android 14.
Regression partially completed: 42/50 passed, 1 P1 failed, 7 not run.

Risk:
Users on Android 12 cannot complete purchase after adding a discount code.

This helps product and engineering make decisions with context.

Official references

• Google Play Console — Android vitals
• Apple — App Review Guidelines
• WCAG Mobile Accessibility

Quick recap

Practice exercises

1. Create a 10-item smoke checklist for a notes app.
2. Write a bug report for a login issue that happens only after rotation.
3. Design a release device matrix for a banking app with six devices.
4. Test one app with large font size enabled and write down layout issues.
5. Pick any mobile app and identify three analytics events you would expect on its main flow.

Homework

Create a release readiness package for a simple mobile app:

1. Smoke checklist with 8-12 items.
2. Regression checklist with at least 20 items.
3. Device matrix with priorities and reasons.
4. Bug report template.
5. Go/no-go status template.

Next: continue to the Appium track to automate the highest-value mobile scenarios.