Skip to main content

Common Mobile Testing Mistakes

Prerequisites: You should already understand every module in Sections 1–5 of this path. Leads to: After this, you'll be ready for the Capstone: AtlasBank Mobile End-to-End Verification.

Every module in this path named mistakes specific to its own concern. This module steps back and asks which mistakes recur across concerns, visible only once you've seen the whole path. These aren't new rules — they're the handful of underlying habits that, left unchecked, undermine almost any concern this path taught.

Pattern 1: Selecting Devices by Convenience Instead of a Systematic Method​

A team tests on whatever devices happen to be on hand, or "the two most popular models," with no explicit selection method.

How this leads to an escaped defect: Device Fragmentation's own opening example — a convenience-based selection provided no stated coverage guarantee, while a pairwise-generated set of similar size found a real manufacturer-and-OS-specific defect the convenience-based set had no systematic chance of catching.

Prevention: apply pairwise generation to the real device/OS/manufacturer landscape, and be able to state the specific coverage guarantee the resulting set provides.

Pattern 2: Testing Orientation States Instead of the Transition Between Them​

A team confirms a screen looks correct in portrait, then confirms it looks correct in landscape, and considers rotation fully tested.

How this leads to an escaped defect: Mobile UI and Navigation Testing's own opening example — a transfer form's partially-filled data was lost specifically during the rotation transition, a defect invisible to testing either orientation independently, since both looked correct once settled.

Prevention: deliberately test the act of rotating mid-interaction, not just the two resulting static states.

Pattern 3: Testing Connectivity Loss Without Testing the Reconnect Window​

A team confirms an app shows an appropriate error when offline, and considers connectivity interruption fully tested.

How this leads to an escaped defect: Network, Interruptions, and Offline Testing's own central risk — interrupting connectivity specifically between an action's send and its confirmation, then verifying the retry logic checks the actual outcome before resubmitting, is where this path's highest-stakes defect class concentrates, confirmed independently on both AtlasBank's transfer flow and AtlasShop's cart in the application modules.

Prevention: always test the specific send-to-confirmation timing window, and verify retry logic checks outcome before resubmitting, on every feature with a write action — never assume a pattern confirmed on one feature holds for another.

Pattern 4: Testing a Hardware Feature's Happy Path and Denial, But Not Runtime Change or Recovery​

A team tests that a hardware-dependent feature works when permission is granted, and fails gracefully when denied, and considers it fully tested.

How this leads to an escaped defect: Sensors, Permissions, and Hardware's own opening example — a recurring permission-recovery-detection defect went unnoticed across three unrelated hardware features precisely because runtime permission changes and recovery were never tested as their own explicit conditions.

Prevention: apply the full five-state framework — available/granted, denied, runtime change, hardware unavailable, recovery — to every hardware-dependent feature, not just the two states a checklist naturally covers.

Pattern 5: Trusting an Automated Pass Rate as Evidence of Real Layout Correctness​

A team reports 100% automated test pass rate across the device set and considers the UI fully verified.

How this leads to an escaped defect: Compatibility and Responsive Behavior's own opening example — an automated harness interacting with elements programmatically masked a critical confirmation button positioned entirely off-screen, invisible to any test that didn't specifically check genuine visibility.

Prevention: add a dedicated, human-perspective responsive-behavior pass distinct from functional/compatibility testing, specifically checking that critical actions are visible without requiring an unprompted scroll.

Pattern 6: Treating Device-Side Performance and Security as Optional Extensions of Server-Side Testing​

A team runs a full server-side performance and security suite and treats the mobile app as covered.

How this leads to an escaped defect: Mobile Performance Testing's and Mobile Security Testing's own opening examples — a battery-draining background process and an unencrypted authentication token were both entirely invisible to server-side metrics, since both defects lived exclusively on the device.

Prevention: treat device-side battery, memory, local storage, and certificate-pinning checks as required, not optional, parts of a mobile testing effort — never inferred from server-side results.

Every pattern above has the same underlying shape: a shortcut that feels reasonable in the specific moment it's taken — trusting a convenient device set because generating a pairwise one takes deliberate setup, testing static orientation states because they're easier to check than a live transition, closing out connectivity testing once an offline error message displays correctly. Recognizing the temptation itself as a signal worth pausing on, not just knowing the list of patterns, is what actually prevents them from recurring.

Key Takeaways​

  • Six recurring patterns cut across this path's individual modules: convenience-based device selection, testing orientation states instead of transitions, skipping the reconnect window, testing only permission grant/deny states, trusting automated pass rates for layout correctness, and treating device-side performance/security as optional.
  • Each pattern is a shortcut that feels reasonable in the specific moment it's taken — recognizing the moment of temptation is the actual skill, more than memorizing the list.
  • Every pattern traces back to a real, worked defect example from earlier in this path, several confirmed independently across both AtlasBank and AtlasShop's application modules.
  • Prevention in every case is a specific, learnable habit, not a vague call for more thoroughness.

What You Just Learned​

  • Six mistake patterns that recur across this path's individual concerns, not within any single one
  • How each pattern, left unchecked, produced a real, specific defect in this path's own worked examples
  • The specific prevention habit for each pattern
  • Why recognizing the moment of temptation to take a shortcut matters more than memorizing a list of mistakes

Next: Capstone: AtlasBank Mobile End-to-End Verification

Interview Questions​

Q1: What's a common mistake you've seen (or made) in mobile testing, and how would you prevent it?

What to look for: A specific, real pattern (not a generic "not testing enough") with a concrete prevention habit attached — ideally one of this module's six, explained in the candidate's own words, showing genuine understanding rather than a memorized list.

Q2: Why might a screen that looks correct in both portrait and landscape orientation still have a real bug?

What to look for: A candidate who directly names Pattern 2 — that the transition between orientations, not just the two resulting static states, is where data-loss defects specifically concentrate.

Glossary​

Escaped Defect: A defect that reached production despite testing having occurred, typically traceable to a specific gap in test design or execution rather than an absence of testing effort.

Quick Revision​

Remember these five points:

✓ Select devices via pairwise generation with a stated coverage guarantee, never by convenience alone.

✓ Test the rotation transition itself, not just the two resulting static orientation states.

✓ Always test the send-to-confirmation reconnect window on every feature with a write action.

✓ Apply the full five-state hardware framework — including runtime change and recovery — to every hardware-dependent feature.

✓ Treat device-side battery, memory, storage, and certificate checks as required, not inferred from server-side results.