From 05f02a8b6d2553a2aede869fd99df6547eb5330c Mon Sep 17 00:00:00 2001 From: aimerdoux Date: Sun, 17 May 2026 15:58:49 -0700 Subject: [PATCH 1/3] feat(e2e): add touch-target smoke + intentional 24px regression for demo (WAVAAAA-194) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - e2e/touch-target.spec.ts: Playwright test asserting all buttons/links/role=button elements meet the 44px minimum touch target on iPhone 13 viewport (390×844) - OnboardingShell.tsx EmptyState hero: adds 24×24 icon-only "Quick action" button that intentionally fails the test so CI shows a red badge in the recording - ci.yml: adds "Install Playwright browsers" + "Smoke test (mobile — iPhone 13 viewport)" steps after existing type-checks DEMO-REGRESSION: the 24px button MUST be reverted after the screen recording is done. Co-Authored-By: Paperclip --- .github/workflows/ci.yml | 8 ++++++++ e2e/touch-target.spec.ts | 12 ++++++++++++ .../src/wavex-os/pages/OnboardingShell.tsx | 10 ++++++++++ 3 files changed, 30 insertions(+) create mode 100644 e2e/touch-target.spec.ts diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index fe8d09f..619e70a 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -34,3 +34,11 @@ jobs: - name: Type-check mock-core run: pnpm --filter @wavex-os/mock-core exec tsc -p tsconfig.json --noEmit || true + + - name: Install Playwright browsers + run: pnpm exec playwright install chromium --with-deps + + - name: Smoke test (mobile — iPhone 13 viewport) + run: pnpm exec playwright test e2e/touch-target.spec.ts --project=chromium + env: + PLAYWRIGHT_BASE_URL: http://localhost:5173 diff --git a/e2e/touch-target.spec.ts b/e2e/touch-target.spec.ts new file mode 100644 index 0000000..ef2998c --- /dev/null +++ b/e2e/touch-target.spec.ts @@ -0,0 +1,12 @@ +import { test, expect } from "@playwright/test"; + +test("all interactive elements meet 44px touch target (iPhone 13)", async ({ page }) => { + await page.setViewportSize({ width: 390, height: 844 }); + await page.goto("http://localhost:5173"); + const interactives = await page.$$("button, a, [role=button]"); + for (const el of interactives) { + const box = await el.boundingBox(); + if (!box) continue; + expect(Math.min(box.width, box.height), `element too small: ${await el.innerHTML()}`).toBeGreaterThanOrEqual(44); + } +}); diff --git a/packages/onboarding-ui/src/wavex-os/pages/OnboardingShell.tsx b/packages/onboarding-ui/src/wavex-os/pages/OnboardingShell.tsx index f96a750..cab522d 100644 --- a/packages/onboarding-ui/src/wavex-os/pages/OnboardingShell.tsx +++ b/packages/onboarding-ui/src/wavex-os/pages/OnboardingShell.tsx @@ -1255,6 +1255,16 @@ function EmptyState({

+ {/* DEMO-REGRESSION: 24×24 icon-only button intentionally below 44px touch target */} + + {mode === "gateway" && onAccountTypeSelected ? (
From 5a14beae30df2aa11406a0efe29e852af768af39 Mon Sep 17 00:00:00 2001 From: aimerdoux Date: Sun, 17 May 2026 15:59:00 -0700 Subject: [PATCH 2/3] feat(community): add animated PR CI demo for Tony Apple QA Studio MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Self-playing HTML animation at docs/demo/pr-ci-demo.html showing: - GitHub PR interface with real CI check integration - Tony Apple QA Studio spinning up a real-device smoke test - Touch target bug detection (WCAG 2.5.5 violation, 22×22 pt) - Failure state: check blocked, merge blocked, screenshot captured No build step — open the file in any browser and record. Co-Authored-By: Paperclip --- docs/demo/pr-ci-demo.html | 706 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 706 insertions(+) create mode 100644 docs/demo/pr-ci-demo.html diff --git a/docs/demo/pr-ci-demo.html b/docs/demo/pr-ci-demo.html new file mode 100644 index 0000000..ab82b3b --- /dev/null +++ b/docs/demo/pr-ci-demo.html @@ -0,0 +1,706 @@ + + + + + +Tony Apple QA Studio — Demo + + + + + +
+ + + + + +
+
aimerdoux / my-ios-app
+
Pull request #47 · tony-apple-qa / real-device-smoke-test
+
+
+ + +
+
+
+ + +
+ + +
+
+ + Open +
+
+
+ feat: redesign checkout button layout + feat/checkout-redesign +
+
+ alexdev wants to merge 3 commits into main + · opened 2 minutes ago +
+
+
+ + +
+ 3 files changed + +124 additions + −38 deletions + ↗ View diff +
+ + +
+
Checks
+ + +
+ +
+
Build / test
+
All unit tests passed (47/47)
+
+ Passed +
+ + +
+ + +
+
+ + Tony Apple QA Studio +
+
Waiting to run…
+
+ Pending +
+ + +
+
+ Real Device Smoke Test + iPhone 15 Pro · iOS 17.4 · en-US +
+
+ +
+
+
+
My App
+
+
Item One
+
Item Two
+
Item Three
+
+ +
✓
+ +
+
+
44pt violation
+
+
+
+ + +
+
+ + +
+
+ + 1 accessibility failure — merge blocked +
+
    +
  • + WCAG 2.5.5 +
    +
    Touch target too small: CheckoutButton (22×22 pt)
    +
    Minimum required: 44×44 pt · Found at x=289, y=712 · iPhone 15 Pro
    +
    +
    • +
+
+
+ +
+ + +
+
+ +
+
Merging is blocked
+
Tony Apple QA Studio found 1 accessibility failure — fix before merging
+
+ +
+
+ +
+ + +
+ + Tony Apple QA Studio · real-device CI · powered by WaveX OS +
+ + +
+ + +
+ + + + From 1fa19f4a3ef8ddcc4d64f6fc0e93ba1d7d421ed8 Mon Sep 17 00:00:00 2001 From: aimerdoux Date: Sun, 17 May 2026 16:13:46 -0700 Subject: [PATCH 3/3] content: add Mobile App QA Checklist blog post (WAVAAAA-205) Staging-only; do not merge until 2026-05-31 dry_run gate lifts. - Adds content/blog/mobile-app-qa-checklist/index.mdx (CMO-approved) - Adds FAQPage JSON-LD block before FAQ section (FAQBlock component does not exist in repo; injecting schema directly per task spec) - published: false, no published_at until gate lifts Co-Authored-By: Paperclip --- .../blog/mobile-app-qa-checklist/index.mdx | 276 ++++++++++++++++++ 1 file changed, 276 insertions(+) create mode 100644 content/blog/mobile-app-qa-checklist/index.mdx diff --git a/content/blog/mobile-app-qa-checklist/index.mdx b/content/blog/mobile-app-qa-checklist/index.mdx new file mode 100644 index 0000000..6296203 --- /dev/null +++ b/content/blog/mobile-app-qa-checklist/index.mdx @@ -0,0 +1,276 @@ +--- +title: "Mobile App QA Checklist: Everything Your Team Needs Before Every Release" +slug: mobile-app-qa-checklist +date: 2026-05-17 +author: Tony Apple QA Studio +description: "A comprehensive mobile app QA checklist covering functional testing, UI regression, performance, device matrix, and CI/CD gates. Download the free PDF." +keywords: ["mobile app qa checklist", "mobile app testing checklist", "mobile qa process", "app release checklist"] +category: mobile-testing +type: blog_post +published: false +published_at: null +cta_url: "https://wavexos.com/signup?utm_source=organic&utm_medium=seo&utm_campaign=qa-checklist-pdf" +schema: + "@context": "https://schema.org" + "@type": "Article" + headline: "Mobile App QA Checklist: Everything Your Team Needs Before Every Release" + author: + "@type": "Organization" + name: "Tony Apple QA Studio" + datePublished: "2026-05-17" + publisher: + "@type": "Organization" + name: "Tony Apple QA Studio" +--- + +import { EmailGate } from '@/components/EmailGate' +import { SignupCTA } from '@/components/SignupCTA' + + + +# Mobile App QA Checklist: Everything Your Team Needs Before Every Release + +Shipping a broken release costs more than delaying it. A single crash on the most-used flow can tank your App Store rating overnight, trigger a wave of uninstalls, and generate support tickets that swamp your team for days. The fix is not heroic last-minute testing—it is a repeatable checklist that every engineer and QA lead runs before every release, every time. This guide gives you that checklist, section by section, plus a downloadable PDF you can attach to your release pipeline. + +--- + +## 1. Functional Testing: Core User Flows + +Functional testing verifies that the app does what it is supposed to do. Start with the flows that generate revenue or retain users—everything else is secondary. + +Run each item manually on at least one real device and confirm it is covered in your [automated smoke-test suite](/blog/mobile-smoke-testing-guide): + +- **Onboarding / sign-up:** new user can complete registration without errors on both iOS and Android +- **Login:** email/password, SSO, and biometric (FaceID / fingerprint) each succeed +- **Core value action:** the single action your app is built around (place order, send message, start workout) completes end-to-end +- **Payments / in-app purchase:** transaction succeeds in sandbox; receipt is validated server-side +- **Notifications:** push notification tap routes to the correct in-app screen +- **Deep links:** marketing links open the right screen without crashing when the app is cold-started +- **Offline graceful degradation:** app displays a clear error (not a blank screen or crash) when there is no network +- **Session expiry:** expired token triggers re-authentication, not a silent failure or infinite spinner +- **Logout:** session is fully cleared; back-button does not restore authenticated screens +- **Permissions:** camera, location, and microphone permission prompts appear at the right moment and are handled correctly when denied + +If any of these flows fails, the release does not ship. No exceptions. + +--- + +## 2. UI and Regression Testing: Touch Targets and Visual Diffs + + + +A functional app can still feel broken if buttons are mis-sized, text is truncated, or a layout breaks on a specific screen width. UI regression catches the drift between releases. + +**Touch target checklist:** + +- Every tappable element is at least 44×44 pt (Apple HIG) / 48×48 dp (Material Design) +- No overlapping hit areas — a "back" button should not fire when the user taps the header text +- Form inputs scroll above the keyboard on both platforms (no input hidden behind the keyboard) +- All interactive elements have visible focus states for accessibility + +**Visual regression with screenshot diffs:** + +Screenshot diffing compares a reference screenshot against the current build pixel-by-pixel. Tools like Applitools, Percy, or the open-source [automated regression framework](/blog/automated-regression-testing-mobile) you already use will flag layout shifts before humans catch them. + +Run screenshot diffs against: + +- Home / dashboard screen +- Product listing or content feed +- Checkout or conversion screen +- Settings / profile page +- Any modal or bottom-sheet that appears on a primary CTA + +Flag any diff above a 0.1% threshold for human review. Do not auto-approve diffs from a changed feature branch without a second set of eyes. + +--- + +## 3. Performance: Startup Time, Memory, and Battery + +Performance regressions are invisible until they are catastrophic. A 300 ms startup regression compounding over 10 releases becomes a 3-second cold launch—and users notice at 2 seconds. + +**Startup time:** + +- Cold launch (app not in memory): target ≤ 2 s on a mid-range device from your [device matrix](/blog/ios-android-device-matrix-testing) +- Warm launch (app backgrounded): target ≤ 1 s +- Measure with Xcode Instruments (Time Profiler) or Android Profiler, not wall-clock stopwatch + +**Memory:** + +- Peak RSS during a typical user session should not exceed your baseline by more than 15% +- No memory leaks detectable after 5 full navigation cycles (use Instruments Leaks / Android Memory Profiler) +- App should not be OOM-killed in the background within 30 minutes on a device with 3 GB RAM + +**Battery:** + +- Background location or sensor polling should consume ≤ 2% battery per hour (measure with Android Battery Historian or iOS Energy Log) +- No wakelocks held unnecessarily between user actions + +--- + +## 4. Device and OS Matrix Coverage + +You cannot test every device, but you can test a representative matrix. Skipping this step is why releases that "passed QA" crash on the most common Android skin in your target market. + +**Minimum viable matrix (adjust for your analytics):** + +| Tier | iOS | Android | +|------|-----|---------| +| Latest | iPhone 16 Pro (iOS 18) | Pixel 9 (Android 15) | +| Previous flagship | iPhone 15 (iOS 17) | Samsung Galaxy S24 (One UI 6) | +| Mid-range | iPhone SE 3rd gen | Samsung Galaxy A55 | +| Older OS | iOS 16 (min supported) | Android 12 (min supported) | +| Small screen | — | Pixel 4a (5.8″) | + +**What to test on each tier:** + +- Core user flows (functional checklist above) +- Orientation: portrait and landscape on tablet-class devices +- Text scaling: run at 150% text size and verify no clipping +- Dark mode: if supported, verify on at least one device per OS + +For [continuous device coverage](/blog/ci-cd-mobile-testing-pipeline), integrate a cloud device farm (BrowserStack, Sauce Labs, Firebase Test Lab) into your CI pipeline so every PR runs smoke tests on the top-three devices automatically. + +--- + +## 5. CI/CD Integration Gate + +A checklist that lives in a spreadsheet is a checklist that gets skipped under deadline pressure. The only reliable checklist is one that blocks a merge or deployment automatically. + +**Gate structure:** + +``` +PR opened → unit tests → lint + type-check + ↓ +Merge to staging branch → smoke tests (real device, cloud farm) + ↓ +Release candidate tag → full regression suite → screenshot diffs + ↓ +Human sign-off (QA lead) → App Store / Play Store submission +``` + +**Minimum CI gate requirements:** + +- **Unit tests:** must pass with ≥ 80% coverage on business logic modules +- **Smoke tests:** top-5 user flows on at minimum 2 real devices (iOS + Android) +- **Screenshot diffs:** auto-fail on any diff > 0.1% on core screens +- **Performance budget:** fail the build if cold launch time regresses > 10% vs. baseline +- **Dependency audit:** flag any new third-party dependency not approved by the security review + +**Gate enforcement rules:** + +- No bypass without a written exception signed by the engineering lead +- Exception log is reviewed at the weekly release retrospective +- Three consecutive exceptions on the same check = mandatory automation investment to fix the underlying issue + +--- + +## Summary: Release-Ready Checklist at a Glance + +| Section | Pass criteria | +|---------|---------------| +| Functional flows | All 10 core flows pass on iOS + Android | +| Touch targets | All tappable elements ≥ 44pt/48dp, no overlap | +| Screenshot diffs | < 0.1% change on core screens | +| Cold launch | ≤ 2 s on mid-range device | +| Memory | Peak RSS within 15% of baseline, 0 leaks | +| Device matrix | Tested on 4 tiers minimum | +| CI gate | All automated checks green before human sign-off | + +**Get the full checklist as a printable, fillable PDF:** + + + +--- + +## Frequently Asked Questions + + + + + +### What should a mobile app QA checklist include? + +A complete mobile app QA checklist should cover five areas: functional testing of core user flows, UI and regression testing with screenshot diffs, performance benchmarks (startup time, memory, battery), device and OS matrix coverage, and CI/CD gate enforcement. The goal is a repeatable process that catches regressions before they reach users. + +### How often should you run a mobile app QA checklist? + +Run the full checklist before every production release. Run an abbreviated smoke-test subset (core flows + CI gate) on every pull request merge to your main branch. The more automation you have in place, the lower the marginal cost of running checks continuously. + +### What is the difference between functional testing and regression testing in mobile QA? + +Functional testing verifies that features work as designed — the app does the right thing. Regression testing verifies that previously working features have not broken — the app still does what it used to do. Both are required: a new feature can be functionally correct while inadvertently breaking an unrelated screen. + +### How do you test a mobile app across multiple devices without a large hardware lab? + +Use a cloud device farm such as Firebase Test Lab, BrowserStack App Automate, or Sauce Labs. These services give you access to hundreds of real devices on demand, integrate directly with CI/CD pipelines, and are typically cheaper than maintaining a physical lab once you account for device refresh cycles and maintenance time. + +### What is a CI/CD gate for mobile app releases? + +A CI/CD gate is an automated check that must pass before a build can proceed to the next stage — for example, from a feature branch to the release candidate. Typical gates include unit test pass rate, smoke test results on real devices, screenshot diff thresholds, and performance budgets. Gates enforce the QA checklist automatically so no release can bypass it under deadline pressure. + +