Comprehensive Testing Strategy (Unit, Integration, UI, E2E) Questions

Comprehensive testing strategy for production mobile apps. Unit testing: testing business logic in isolation, mocking dependencies. Integration testing: testing interactions between layers and components. UI testing: testing user-facing features with appropriate frameworks. E2E testing: full user flow testing. Tools: XCTest (iOS), JUnit/Espresso (Android), Detox for cross-platform. Test coverage goals and test pyramid principles. Avoiding flaky tests, managing test data, CI/CD integration. Different testing strategies for different components.

HardTechnical

37 practiced

You join a team with a legacy mobile app that has almost no unit tests and tightly coupled UI and business logic. Provide an incremental refactor plan to enable unit and integration testing with minimal risk: identify refactor targets, introduce seams such as dependency injection and adaptor patterns, write characterization tests, and get incremental CI feedback.

Sample Answer

**Plan overview (goal: make code testable with minimal risk, incremental CI feedback)**

**1) Clarify scope & safety nets**- Add CI job that runs current smoke UI tests and records crash/error rates before changes.- Create a backup branch and enforce small PRs (<200 LOC) with CI gating.

**2) Characterization tests (risk control)**- Write black-box tests that capture current behavior: key flows (login, data sync, settings). Use XCTest/UI Tests for iOS, Espresso/AndroidX for Android, or integration tests for cross-platform.- Use recording/asserting of API calls, DB state, and visible UI outputs. These protect refactor changes.

**3) Identify refactor targets (high ROI first)**- Business logic in Activities/UIViewControllers- Network/db/storage code in-line in UI- Global singletons and static helpers

Prioritize small, high-impact classes with few dependencies.

**4) Introduce seams & DI incrementally**- Wrap singletons with interfaces (protocols in Swift / interfaces in Kotlin). Example: replace direct calls to Networking.shared with a NetworkClient protocol and a concrete adapter.- Add constructor injection to presenters/ViewModels first (easy to unit test) — keep adapters that translate existing static calls to the new interface to avoid wide changes.- Use a lightweight DI container or manual composition in app bootstrap. Keep changes local: for an Activity/VC, add an init that accepts dependencies with default production implementations for runtime.

**5) Adapter pattern to isolate platform/static APIs**- Create adapter for system APIs (Battery, Location, Preferences) implementing small interfaces. Unit tests can inject fakes/mocks.

**6) Write unit tests & expand coverage**- Start with newly created ViewModels/use-case classes. Use XCTest + Nimble/Quick or JUnit + Mockito/MockK.- Convert characterization tests into focused unit/integration tests as seams are available.

**7) CI & feedback loop**- Add fast unit test job to CI first; then run instrumentation/emulator tests in parallel stages.- Fail fast on regressions. Use code coverage thresholds per module, not global.

**8) Iterate**- Repeat: pick next tightly-coupled class, introduce interface/adaptor, add unit tests, remove old static usage when safe.

Tools & examples:- iOS: Extract Presenter/ViewModel from UIViewController; inject URLSession via protocol.- Android: Move logic out of Activity to ViewModel (Jetpack), inject Retrofit via interface, use Hilt later when seams stabilized.

Outcome: small safe PRs, preserved behavior via characterization tests, growing unit test surface, and CI that gives quick feedback.

HardTechnical

30 practiced

Design a release validation and rollback mechanism for mobile apps that combines automated tests, staged rollouts (canary), monitoring SLOs (for example crash rate and onboarding success), and automated rollback triggers. Define thresholds, which tests to run pre- and post-release, and how to coordinate with app store constraints.

Sample Answer

**Clarify goals & constraints**- Goal: Catch regressions quickly, minimize user impact, automate rollback when SLOs break, respect App Store/Play Store release semantics (review delays, staged rollout APIs).- Constraints: App stores limit immediate full rollouts and instant removals; use feature flags + server-side switches for fastest mitigation.

**High-level flow**1. Pre-release: CI + QA -> Private beta (TestFlight / Firebase App Distribution)2. Canary/staged rollout: 1% -> 5% -> 25% -> 100% with monitoring windows3. Post-release: automated health checks + RUM + crash analytics drive automated rollback triggers and human review

**Pre-release tests**- Unit tests + linting, static analysis- Integration tests for network + DB- UI E2E on representative device matrix (low/med/high-end, Android API levels, iOS versions) via Detox/Espresso/XCUITest or cloud device farms- Performance & memory regression tests (startup time, FPS, memory)- Security & permission checks- Beta user cohort (TestFlight / Internal Play) for behavioral metrics

**Post-release tests / monitoring**- Smoke synthetic transactions (login, onboarding, purchase) executed from multiple regions- RUM instrumentation for session success paths (onboarding success)- Crash reporting (Crashlytics/Sentry) and ANR detection- Backend error-rate and latency alerts correlated to release- Device/os-segmented metrics

**SLOs / thresholds & actions (example)**- Crash-free rate SLO: >= 99.5% (crash rate <= 0.5%) over rolling 1-hour window for canary - If crash rate > 1.0% for 30 mins → automatic rollback to prior version for canary cohort + pager - If crash rate between 0.5%–1.0% for 60 mins → pause rollout, notify on-call- Onboarding success: >= 95% success within first-run flow per cohort - If onboarding success drops >5 percentage points vs baseline over 1 hour → pause and investigate- Error rate (API errors impacting UX): increase >200% vs baseline for 15 mins → rollback- Performance regressions: startup time increase >20% or ANR increase >100% → pause/rollback

**Automated rollback triggers**- Use alerting engine (Prometheus/Datadog) with anomaly detection + rules above- When trigger fires: - For Play Store: reduce staged rollout percentage via API to prior stable version (or halt further percentage increases) - For iOS: use phased release control (if phased unavailable) rely on server-side feature flag to disable new code paths and push hotfix; prepare expedited app review if removal required - Notify on-call, create incident with telemetry snapshot, and optionally promote previous APK/IPA via store consoles

**Coordination with app stores**- Use Play Store phased rollout APIs to programmatically adjust percentages- Use TestFlight phased releases and internal testers to catch before public release- Always include server-side feature flags for critical switches because app binary rollback via App Store can be slow- Prepare an expedited review plan and pre-drafted communications for App Store expedited reviews and customer support

**Operational details**- Canary cohorts: 1% (30–60m) → 5% (1–2h) → 25% (4–6h) → 100% (24–48h)- Monitoring windows: shorter for earlier cohorts, extend as % grows- Device segmentation: enforce SLOs per major OS version and device class- Post-mortem & automated learnings: record triggers, root causes, and tighten tests that missed issue

This plan combines robust pre-release testing, gradual exposure through canaries, clear SLOs and automated rollback rules, and practical mitigations for app-store delays (feature flags, expedited review paths).

EasyTechnical

30 practiced

List the common causes of flaky tests in mobile automated suites across unit/integration/UI/E2E. For each cause give at least one concrete mitigation technique you would implement immediately in the test suite or app code to reduce flakiness.

Sample Answer

**Brief intro**Common flaky-test causes span timing, environment, state, and test design. Below are causes with concrete mitigations you can implement immediately in mobile unit/integration/UI/E2E suites.

**1. Timing / race conditions**- Cause: Tests assert before async work (network, animations, background threads) completes.- Mitigation: Use explicit synchronization — on Android register IdlingResources (Espresso) or wait-for-network hooks; on iOS use XCTestExpectation or XCUIElement.waitForExistence(timeout:). Replace fixed sleeps with waits.

**2. Unstable test data / external dependencies**- Cause: Tests depend on live APIs or changing backend state.- Mitigation: Mock network responses (MockWebServer, VCR, dependency injection). Use deterministic fixtures and feature flags to point app to test backends.

**3. Shared/global state and test order dependency**- Cause: Tests leak state (DB, prefs, cache) between runs.- Mitigation: Reset storage before each test (clear SharedPreferences/UserDefaults, reset Realm/SQLite), or run tests in isolated containers/emulators. Use test-only hooks to seed/tear-down.

**4. Device/environment variability**- Cause: Device performance, OS versions, screen sizes, locale, or flakiness from CI.- Mitigation: Run critical suites on stable pool (specific emulator images), pin device OS versions in CI, and normalize locale/timezone in test setup.

**5. UI fragility (selectors, animations)**- Cause: Tests rely on brittle selectors or UI positions; animations change timing.- Mitigation: Use stable accessibility IDs, avoid pixel-based asserts, disable animations in test build (Android: animator/transition/animateOff; iOS: UIAnimations off), and wait for UI idle.

**6. Resource constraints / timeouts**- Cause: Short timeouts cause intermittent failures under load.- Mitigation: Increase sensible timeouts and make them configurable. Add retries only for known transient actions and log retries.

**7. Flaky third-party libs / flaky hardware features**- Cause: Flaky camera, GPS, or vendor SDKs.- Mitigation: Abstract hardware behind interfaces and stub them in tests; use emulator-provided simulated sensors.

Implementing these—IdlingResources, mocks for network, clearing persistence, disabling animations, and stable selectors—reduces the majority of mobile test flakiness immediately.

MediumSystem Design

34 practiced

Design a CI pipeline to run unit tests, integration tests, and E2E tests for both iOS and Android apps. Include stages, caching strategies, parallelization, artifact reuse (builds), where to run each test type (runner vs emulator vs real device), and how to handle flaky E2E retries and failure triage.

Sample Answer

**High-level pipeline (stages)**

- Checkout → Install deps → Build artifacts → Unit tests → Integration tests → E2E tests → Publish results/artifacts.

**Details by stage**- Install deps: cache Gradle/ Maven, CocoaPods, npm/yarn, Carthage, Xcode toolchains, derived data.- Build artifacts: produce signed/unsigned APK / IPA once per commit/branch; store as reusable build artifact.- Unit tests: run on CI runners (macOS runner for iOS, Linux/Android runner for Android) using JVM/Swift test frameworks; fast, run against compiled code.- Integration tests: run on emulators/simulators when native integrations (DB, network mocks) required.- E2E tests: run on real devices or device-farm (Firebase Test Lab / AWS Device Farm / Bitrise) for coverage of OEM/OS quirks.

**Caching strategies**- Gradle caches (.gradle, build cache), CocoaPods cache (~/.cocoapods), npm/yarn, Carthage, derived data. Persist between jobs/agents; warm caches on new runners.

**Parallelization & sharding**- Split test suites into shards (by package, test file, or timing history) and run in parallel across multiple runners/emulators or device-farm workers.- Matrix by OS/version/device profile for E2E (e.g., Pixel 4 / Pixel 7 / iPhone 12 / iPhone 14).

**Artifact reuse**- Reuse the APK/IPA produced in Build stage for all test stages; tests download artifact from artifact store (S3 or CI artifact storage) to guarantee identical binary.- Keep debug/symbol files for crash symbolication.

**Where to run each test**- Unit: local CI runners (fast).- Integration: simulators/emulators on CI or dedicated VM images.- E2E: real devices on device-farm; reserve small runs on simulators for pre-merge smoke.

**Flaky E2E retries & triage**- First-run failure: automatically retry failed tests up to N times (e.g., 2) with exponential backoff but only rerun failed tests, not whole suite.- If flaky threshold exceeded (failure rate > X%): quarantine test, mark flaky, create ticket with reproducible data.- Triage artifacts: collect logs, device logs (adb/idevicesyslog), screenshots, video, network traces, crash reports, and test metadata (device, OS, app build hash). Attach to CI failure and to bug tracker.- Maintain a flakiness dashboard (per-test history) and enforce SLAs to reduce flakes.

**Trade-offs / best practices**- Use simulators for quick feedback; reserve device-farm for pre-release/regression. Cache aggressively but invalidate on dependency changes. Prioritize failing-fast: run lint/unit/instrumentation smoke before long E2E farms.

HardBehavioral

40 practiced

Tell me about a time you advocated for improving testing practices on a mobile engineering team. Describe the problems you observed, the changes you proposed (tools, process, or refactor), how you prioritized and implemented them, metrics you used to measure success, and how you handled resistance from teammates or product managers.

Unlock Full Question Bank

Get access to hundreds of Comprehensive Testing Strategy (Unit, Integration, UI, E2E) interview questions and detailed answers.

Join thousands of developers preparing for their dream job.