How to Automate Maps Integration Testing (Step-by-Step)

How to Automate Maps Integration Testing (Step-by-Step)

How to Automate Maps Integration Testing (Step-by-Step)

Maps are no longer static images; they are interactive, data‑rich components that power navigation, location‑based services, and geospatial analytics. When a map is embedded in a mobile or web application, its behavior depends on SDK calls, tile loading, gesture handling, and external services such as geocoding or routing APIs. A failure in any of these layers can break core user flows—think of a ride‑hailing app that cannot drop a pin or a delivery app that shows the wrong route. Manual verification of map behavior is tedious, error‑prone, and does not scale across the many device configurations, screen sizes, and network conditions that users encounter. Automating maps integration testing gives teams a repeatable way to validate that the map loads correctly, responds to user interactions, displays the expected data layers, and remains performant under varying conditions. This guide walks you through a complete, step‑by‑step process: from deciding when automation is worthwhile, through framework selection, locator design, synchronization, data management, CI integration, reporting, and finally how autonomous exploration can bootstrap the effort without writing a single test script.

How to Automate Maps Integration Testing (Step-by-Step): Understanding the Challenges

Maps introduce several testing complexities that differ from typical UI elements. First, map rendering is asynchronous; tiles are fetched over HTTP, often with caching layers that depend on previous requests. Second, user gestures (pinch‑zoom, rotate, drag) generate continuous streams of touch or mouse events that the map SDK interprets in real time. Third, many map features rely on external services—geocoding, reverse‑geocoding, routing, traffic—that may return different results based on location, time, or API quotas. Fourth, maps are highly sensitive to device performance; a low‑end Android device may drop frames during heavy tile loading, leading to perceived unresponsiveness even when the underlying code is correct. Finally, accessibility considerations (WCAG) require that map controls be operable via keyboard or screen readers, and that alternative text be provided for non‑visual users.

Because of these factors, a naïve record‑and‑playback approach quickly becomes fragile. A test that passes on a high‑end emulator may fail on a real device due to tile‑loading timing differences. Similarly, a test that asserts a specific pixel color after a zoom operation can break when the map provider updates its tile set. Effective automation therefore focuses on *behavioral* contracts rather than pixel‑perfect comparisons: does the map receive the correct camera update, does it fire the expected callbacks, and does it render the expected annotation data‑driven overlays appear at the right coordinates?

How to Automate Maps Integration Testing (Step-by-Step): When Automation Pays Off

Automation is not always the best investment for every map‑related feature. Consider automating when:

If your map usage is limited to a static image with a single marker, manual spot checks may suffice. However, once the map drives user‑generated content, offline caching, or real‑time updates, the ROI of automation becomes clear.

How to Automate Maps Integration Testing (Step-by-Step): Choosing the Right Test Framework

Selecting a framework depends on the platform (native Android/iOS, hybrid, or web), the language preferences of your team, and the level of control you need over the map SDK. Below is a comparison of the most popular options for maps integration testing.

For most teams, the decision boils down to whether the map is rendered via a native SDK (choose Appium, Espresso, or XCUITest) or via a web map library (Leaflet, Mapbox GL JS, Google Maps JavaScript API) where Playwright or Selenium shines. If you need to test both native and web views in a single flow (e.g., a hybrid app that opens a webview for place details), Appium remains the most versatile because it can context‑switch between native and web views.

How to Automate Maps Integration Testing (Step-by-Step): Setting Up the Test Environment

A reliable test environment mirrors production as closely as possible while allowing controllability. The key components are:

1. Device or emulator farm – Use a mix of real devices (different screen densities, GPU capabilities) and emulators for rapid iteration. Services like Firebase Test Lab, AWS Device Farm, or a local Kubernetes‑based device cloud give you scalability.
2. Network simulation – Map tile loading is sensitive to latency and bandwidth. Tools such as tc (Linux traffic control), Facebook’s Network Link Conditioner, or built‑in throttling in Appium/Playwright let you emulate 3G, 4G, or offline conditions.
3. Mock tile server – Instead of hitting the real map provider (which may incur costs or rate limits), run a local HTTP server that serves pre‑canned tile images (PNG or WebP). You can generate tiles from a static MBTiles file using tilelive or tippecanoe.
4. Geolocation override – Most frameworks allow you to set the device latitude/longitude programmatically. In Appium you use driver.setLocation(location), in Playwright you use context.setGeolocation({ latitude, longitude }).
5. API mocking – For geocoding, routing, or traffic endpoints, use a tool like WireMock, MockServer, or the built‑in network interception in Playwright to return deterministic JSON payloads.
6. Test data management – Store test fixtures (tile sets, mock responses, expected annotation coordinates) in a version‑controlled fixtures/ directory. Use a naming convention that encodes the scenario, e.g., route_downtown_to_airport.json.

A minimal docker‑compose.yml for a local test stack might look like:

version: "3.8"
services:
  appium:
    image: appium/appium:2.0.0
    ports:
      - "4723:4723"
    volumes:
      - ./app:/app
  mock-tiles:
    image: nginx:alpine
    volumes:
      - ./tiles:/usr/share/nginx/html:ro
    ports:
      - "8080:80"
  wiremock:
    image: wiremock/wiremock:3.4.2
    ports:
      - "8081:8080"
    volumes:
      - ./mappings:/home/wiremock

Start the stack with docker compose up -d, then point your test runner at http://localhost:4723/wd/hub for Appium, http://localhost:8080 for tiles, and http://localhost:8081/__admin for WireMock.

How to Automate Maps Integration Testing (Step-by-Step): Designing a Stable Locator Strategy for Map Elements

Locators are the Achilles’ heel of UI automation, and maps exacerbate the problem because many visual elements are rendered inside a canvas or WebGL layer that does not expose traditional DOM nodes. The strategy therefore splits into two parts: *SDK‑exposed* elements and *visual* elements that must be inferred indirectly.

SDK‑Exposed Elements

When using a native map SDK (Google Maps Android SDK, Mapbox SDK, Apple MapKit), the framework often provides callbacks or listener interfaces for camera changes, marker clicks, and info‑window events. Your test can register a test listener (via dependency injection or a test‑only subclass) that records these events. For example, in an Android Espresso test you might create a custom MapFragment:

public class TestMapFragment extends SupportMapFragment {
    private final MutableLiveData<LatLng> cameraChange = new MutableLiveData<>();

    @Override
    public void onMapReady(GoogleMap googleMap) {
        super.onMapReady(googleMap);
        googleMap.setOnCameraMoveListener(() ->
            cameraChange.postValue(googleMap.getCameraPosition().target));
        googleMap.setOnMarkerClickListener(marker -> {
            // expose marker id via LiveData or similar
            return false;
        });
    }

    public LiveData<LatLng> getCameraChange() { return cameraChange; }
}

Your test then observes cameraChange to assert that a pan operation moved the map to the expected coordinate range.

Visual Elements (Annotations, Popups, Controls)

If you cannot hook into SDK callbacks (e.g., testing a third‑party hybrid component), you must rely on visual verification. Two approaches work well:

1. Accessibility IDs – Most map SDKs expose accessibility labels for markers, info windows, and control buttons. Set a unique contentDescription (Android) or accessibilityLabel (iOS) when you add an annotation, then locate it with Appium’s MobileBy.AccessibilityId.
2. Image‑based template matching – Capture a screenshot of the expected marker icon (or a cropped region) and use a tool like OpenCV or SikuliX to find it within the device screenshot. This is slower but works when no accessibility hook exists.

A practical example using Appium and Java to verify a marker appears after a search:

WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(15));
WebElement searchBox = driver.findElement(By.id("search_input"));
searchBox.sendKeys("Eiffel Tower");
searchBox.sendKeys(Keys.ENTER);

// Wait for the marker to have accessibility id "marker_EiffelTower"
WebElement marker = wait.until(
    ExpectedConditions.visibilityOfElementLocated(
        MobileBy.AccessibilityId("marker_EiffelTower")));

assertTrue(marker.isDisplayed());

When using Playwright for a web map, you can leverage the page.waitForFunction API to poll the map’s internal state:

await page.goto('https://example.com/map');
await page.fill('#search', 'Eiffel Tower');
await page.press('#search', 'Enter');

await page.waitForFunction(() => {
  const map = window.map; // exposed by the app for testing
  const marker = map.getSource('markers')._data.features.find(f => f.properties.name === 'Eiffel Tower');
  return marker !== null;
});

By combining SDK listeners where possible and falling back to accessibility IDs or image matching only when necessary, you achieve a locator strategy that is both stable and maintainable.

How to Automate Maps Integration Testing (Step-by‑Step): Handling Waits, Synchronization, and Flakiness

Maps are inherently asynchronous, so static Thread.sleep calls are a recipe for flaky tests. Instead, use explicit waits tied to observable map state changes in the map’s internal state.

Common Wait Conditions

Implementing a Custom Wait in Appium (Java)

public static LatLng waitForCameraMove(AppiumDriver driver,
                                       LatLng target,
                                       double latitudeDelta,
                                       double longitudeDelta,
                                       Duration timeout) {
    new WebDriverWait(driver, timeout).until(d -> {
        LatLng current = ((AndroidDriver) d)
                .findElement(By.id("map"))
                .getAttribute("cameraTarget"); // assume we exposed via JS bridge
        return Math.abs(current.latitude - target.latitude) <= latitudeDelta &&
               Math.abs(current.longitude - target.longitude) <= longitudeDelta;
    });
    return target; // or return actual current position
}

If you cannot expose the camera target directly, fall back to checking that a known marker’s screen coordinates have changed beyond a threshold using getLocationOnScreen.

Mitigating Flakiness from Tile Caching

Tile caches can cause a test to pass on the first run (tiles already cached) and fail on subsequent runs (cache miss leads to network delay). To neutralize this:

• Clear the cache before each test: On Android, adb shell pm clear removes the app’s data folder, including the map SDK’s cache. On iOS, uninstall/reinstall the app or call MKMapView.removeOverlay equivalents.
• Use a deterministic tile server: Serve static tiles with far‑future Expires headers so the client treats them as immutable; then you can safely rely on cached versions.
• Force network conditions: Throttle the connection to a constant speed (e.g., 5 Mbps) and disable caching via Chrome DevTools Protocol (Network.setCacheDisabled) when using Playwright.

Reducing False Positives from Animation

Map animations (e.g., smooth zoom) can cause intermediate states that momentarily mismatch expectations. Instead of asserting on a single frame, assert on a *stable* state after the animation completes. Most SDKs expose an onCameraIdle listener (Android) or map.on('moveend', ...) (Mapbox GL JS). Wait for that event before checking marker positions or UI text.

How to Automate Maps Integration Testing (Step‑by‑Step): Data Setup, Teardown, and Mocking Strategies

A map test often needs specific geographic data: a set of coordinates for a route, a list of POIs for clustering, or a polygonal GeoJSON for a heatmap layer. Managing this data reliably is crucial.

Test Data Sources

1. Static GeoJSON fixtures – Store small, well‑known GeoJSON files (e.g., a square covering downtown San Francisco) in src/test/resources/geojson/. Load them with Files.readString.
2. Procedural generators – For tests that need many random points (stress‑testing clustering), use a library like GeoJSON-Generator (npm) or java-faker with a geographic provider to create points within a bounding box.
3. External APIs with mocking – When testing reverse‑geocoding, point the app at a WireMock instance that returns a predefined address for a given lat/long. Example mapping:

{
  "request": {
    "method": "GET",
    "urlPattern": "/geocode/json\\?latlng=([-\\d.]+),([-\\d.]+)"
  },
  "response": {
    "status": 200,
    "jsonBody": {
      "results": [{ "address_components": [{ "long_name": "Eiffel Tower", "types": ["street_address"] }] }],
      "status": "OK"
    },
    "headers": { "Content-Type": "application/json" }
  }
}

Teardown Considerations

• Reset map state: Remove all markers, polylines, and polygons added during the test. Most SDKs provide a clear() method on the map object.
• Clear location mocks: After a test that used driver.setLocation, call driver.resetLocation() or set it to a neutral value (0,0) to avoid leaking into subsequent tests.
• Dispose of mock servers: If you spun up a WireMock or tile server per test class, shut it down in @AfterAll (JUnit) or afterAll (Mocha) to free ports.
• Log artifacts: On failure, automatically pull a screenshot, device logcat, and network HAR file. This accelerates triage.

Example: JUnit 5 Test with Setup/TearDown

public class MapsIntegrationTest {

    private AppiumDriver driver;
    private WireMockServer wireMock;

    @BeforeEach
    void setUp() throws Exception {
        // Start WireMock
        wireMock = new WireMockServer(options().port(8081));
        wireMock.start();
        wireMock.stubFor(get(urlEqualTo("/geocode/json"))
                .willReturn(aResponse()
                        .withHeader("Content-Type", "application/json")
                        .withBodyFile("geocode_eiffel.json")));

        // Start Appium session
        DesiredCapabilities caps = new DesiredCapabilities();
        caps.setCapability("platformName", "Android");
        caps.setCapability("deviceName", "Pixel_4_API_33");
        caps.setCapability("app", System.getProperty("user.dir") + "/app/app-debug.apk");
        caps.setCapability("automationName", "UiAutomator2");
        driver = new AndroidDriver(new URL("http://localhost:4723/wd/hub"), caps);
        driver.manage().timeouts().implicitWait(Duration.ofSeconds(2));
    }

    @AfterEach
    void tearDown() {
        if (driver != null) {
            driver.quit();
        }
        if (wireMock != null) {
            wireMock.stop();
        }
    }

    @Test
    void testReverseGeocodeShowsCorrectAddress() {
        // Open screen with search bar
        driver.findElement(By.id("action_search")).click();
        driver.findElement(By.id("search_input")).sendKeys("48.8584,2.2945"); // Eiffel Tower lat/lng
        driver.findElement(By.id("search_btn")).click();

        // Wait for result text
        WebElement result = new WebDriverWait(driver, Duration.ofSeconds(10))
                .until(ExpectedConditions.visibilityOfElementLocated(By.id("address_text")));

        assertEquals("Eiffel Tower, Champ de Mars, 5 Avenue Anatole France, 75007 Paris, France",
                result.getText().trim());
    }
}

This pattern guarantees that each test starts with a clean mock server and a fresh app instance, eliminating cross‑test contamination.

How to Automate Maps Integration Testing (Step‑by‑Step): Writing Maintainable Test Scripts

Maintainability stems from three pillars: page‑object‑like abstractions, parameterized test data, and clear assertion semantics.

Map‑Specific Page Object

Encapsulate map interactions in a reusable class. For Android with Espresso, a MapScreen object could look like:

public class MapScreen {
    private final ActivityTestRule<MainActivity> activityRule;

    public MapScreen(ActivityTestRule<MainActivity> activityRule) {
        this.activityRule = activityRule;
    }

    public void setMapType(MapType type) {
        onView(withId(R.id.map_type_spinner))
                .perform(click());
        onView(withText(type.name()))
                .perform(click());
    }

    public void moveCameraTo(LatLng latLng) {
        // Use a UIAutomator gesture to drag the map to center on latLng
        // Simplified: use platform channel to send a command to the app
        activityRule.getActivity().runOnUiThread(() -> {
            ((MapsActivity) activityRule.getActivity())
                    .getMap()
                    .animateCamera(CameraUpdateFactory.newLatLng(latLng));
        });
    }

    public LatLng getCameraTarget() {
        return activityRule.getActivity()
                .getMap()
                .getCameraPosition()
                .target;
    }

    public boolean isMarkerVisible(String accessibilityId) {
        return Espresso.onView(
                Matchers.allOf(
                        withContentDescription(accessibilityId),
                        isDisplayed()))
                .matches(isDisplayed());
    }
}

Your test then reads like a specification:

@Test
void userCanSearchAndSeeMarker() {
    MapScreen map = new MapScreen(activityRule);
    map.setMapType(MapType.NORMAL);
    map.moveCameraTo(new LatLng(48.8584, 2.2945));
    assertTrue(map.isMarkerVisible("marker_EiffelTower"));
}

Parameterized Tests with CSV or JSON

Use JUnit 5’s @ParameterizedTest with a @CsvSource or @EnumSource to run the same scenario across multiple locations, map types, or network conditions.

@ParameterizedTest
@CsvSource({
    "48.8584,2.2945,Eiffel Tower",
    "51.5074,-0.1278,London Eye",
    "35.6895,139.6917,Tokyo Tower"
})
void testReverseGeocode(double lat, double lng, String expectedName) {
    // ... same body omitted for brevity
}

Assertion Libraries that Improve Readability

• AssertJ (assertThat(mapScreen.getCameraTarget()).isCloseTo(expected, within(0.0001)))
• Hamcrest (assertThat(resultText, containsStringIgnoringCase("Eiffel Tower")))
• Chai for JavaScript (expect(marker.getAttribute('aria-label')).to.equal('Eiffel Tower'))

Keep assertions focused on *behavior* (camera moved, marker clickable, info‑window text correct) rather than on internal implementation details (specific tile URL, exact pixel color). This makes tests resilient to SDK updates that change internal rendering while preserving the contract.

How to Automate Maps Integration Testing (Step‑by‑Step): Running in CI/CD Pipelines

Integrating map tests into CI requires attention to resource consumption, test isolation, and feedback speed.

CI Pipeline Stages

1. Build – Compile the app, run unit tests, produce APK/IPA or web bundle.
2. Device Provisioning – Spin up emulators/simulators or allocate real devices via a device farm. Use a matrix to cover:

• API levels: 21, 28, 33 (Android)
• iOS versions: 13, 15, 17
• Screen sizes: small, normal, large, xlarge
• Orientation: portrait, landscape

1. Environment Setup – Launch mock tile server, WireMock, and any service dependencies. Use Docker Compose or a dedicated init container.
2. Test Execution – Run your test suite in parallel where possible. Tools like Gradle’s maxParallelForks, Maven Surefire’s parallel, or pytest‑xdist distribute tests across workers.
3. Artifact Collection – On failure, capture screenshots, logcat, and HAR. Upload them as build artifacts (GitHub Actions, GitLab CI, Azure Pipelines).
4. Cleanup – Shut down device instances, delete Docker containers, and release any allocated ports.

Sample GitHub Actions Workflow (Android + Appium)

name: Maps Integration Tests

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        apiLevel: [21, 28, 33]
        device: [Pixel_4, Pixel_5]
    steps:
      - uses: actions/checkout@v3
      - name: Set up JDK
        uses: actions/setup-java@v3
        with:
          distribution: temurin
          java-version: '11'
      - name: Start Emulator
        run: |
          echo "no" | avdmanager create avd -n test -k "system-images;android-${{ matrix.apiLevel }};google_apis;x86_64"
          emulator -avd test -no-window -no-audio &
          # wait for emulator to boot
          adb wait-for-device
          adb shell getprop sys.boot_completed | while read line; do if [[ $line == "1" ]]; then break; fi; sleep 1; done
      - name: Start Mock Services
        run: |
          docker compose -f docker-compose.test.yml up -d
      - name: Install Appium
        run: npm install -g appium
      - name: Start Appium Server
        run: appium & sleep 5
      - name: Run Tests
        run: |
          ./gradlew connectedAndroidTest -PapiLevel=${{ matrix.apiLevel }} -PdeviceName=${{ matrix.device }}
      - name: Collect Artifacts
        if: failure()
        uses: actions/upload-artifact@v3
        with:
          name: test-artifacts-${{ matrix.apiLevel }}-${{ matrix.device }}
          path: |
            **/build/outputs/androidTest-*/connected/
            **/screenshots/**
            **/logs/*
      - name: Tear Down
        if: always()
        run: |
          docker compose -f docker-compose.test.yml down
          adb -s emulator-5554 emu kill

Key points:

• The matrix runs the same test suite across multiple API levels and device models, catching device‑specific issues (e.g., GPU driver bugs affecting map rendering).
• Mock services are started via Docker Compose; they are torn down regardless of test outcome.
• Artifacts are only collected on failure to keep the workflow fast.

If you use a cloud device farm (Firebase Test Lab, AWS Device Farm), replace the emulator steps with a call to the farm’s CLI, passing the same test APK and a list of device models.

Parallelization Tips

• Test sharding – Split your test classes into groups and run each group on a separate device or emulator instance. Gradle’s testOptions { instrumentation { annotationInstrumentationOptions ... } } or JUnit Platform’s @Execution(CONCURRENT) can help.
• Avoid shared state – Ensure that mock servers are either per‑test or cleared between tests; otherwise a test that modifies a WireMock stub can affect another running on the same worker.
• Monitor resource usage – Map tests can be CPU‑intensive due to GPU emulation. Keep an eye on emulator CPU usage; if it spikes above 80 %, reduce the number of concurrent emulators.

How to Automate Maps Integration Testing (Step‑by‑Step): Reporting, Metrics, and Continuous Improvement

Raw pass/fail counts are insufficient for a complex subsystem like maps. You need richer telemetry to spot trends and prioritize fixes.

Test Result Enrichment

• Custom TestListener – In JUnit 5, implement org.junit.platform.launcher.TestExecutionListener to record:
• Start/end timestamps per test
• Device model and OS version
• Network profile used (3G, LTE, Wi‑Fi)
• Any mocked tile server latency injected
• Screenshot paths on failure
• Metrics Export – Push the collected data to a time‑series database (Prometheus) or a BI tool (Grafana, DataDog). Example metric: map_test_duration_seconds{test="reverse_geocode",device="Pixel_4",api="33"} 7.42.
• Trend Dashboards – Plot:
• Average test duration over time (detect performance regressions)
• Flakiness rate (percentage of tests that changed result across retries)
• Tile load time vs. network throttling level
• Number of accessibility violations per run (if you integrate an axe‑core or Android Accessibility Test Framework step)

Example: Publishing Metrics from a Gradle Test Task

test {
    useJUnitPlatform()
    testLogging {
        events "passed", "failed", "skipped"
    }
    afterTest { desc, result ->
        def duration = System.currentTimeMillis() - desc.time
        def metrics = [
                test: desc.name,
                device: System.getProperty('deviceName', 'unknown'),
                api: System.getProperty('apiLevel', 'unknown'),
                durationSec: duration / 1000.0,
                outcome: result.resultType.toString()
        ]
        // Send to Pushgateway or similar
        def payload = metrics.collect { k, v -> "${k}=${v}" }.join('&')
        "http://pushgateway:9091/metrics/job/map_tests".execute([], payload.bytes)
    }
}

Using Reports to Guide Improvements

• High flakiness on a specific device – Investigate GPU driver differences; consider adding a device‑specific skip or a tolerance in timing assertions.
• Increasing test duration – Profile tile loading; maybe enable a more aggressive tile cache or reduce the zoom level in tests.
• Accessibility failures – Prioritize fixing missing content descriptions on markers or ensuring that map controls are reachable via TalkBack/VoiceOver.
• Network‑related failures – If tests start failing under 3G but pass on Wi‑Fi, check whether the app handles timeouts gracefully or whether it needs to show a placeholder UI.

Integrate these insights back into your sprint planning: treat a rising flakiness rate as a technical debt item that warrants a dedicated spike.

How to Automate Maps Integration Testing (Step‑by‑Step): Leveraging Autonomous Exploration to Bootstrap Maps Automation

Writing the first set of map tests can be daunting because you need to identify the right user flows, define assertions, and craft locators. Autonomous exploration tools can dramatically reduce this overhead by *discovering* the app’s behavior and generating starter test scripts without manual scripting.

How Autonomous Exploration Works

1. App ingestion – You upload an APK (or point the tool at a web URL). The tool launches the app on a device/emulator.
2. Guided navigation – Using a set of persona‑driven policies (curious, impatient, power user, etc.), the tool performs taps, scrolls, text entry, and handles dialogs. It treats the map as any other UI component but records every interaction that changes the UI state.
3. State graph construction – Each distinct screen (activity/fragment or web view state) becomes a node; edges represent gestures or navigation actions that lead from one node to another. The tool also logs any exceptions, ANRs, or widget‑level issues (dead button, missing accessibility label).
4. Test generation – From the explored graph, the tool extracts common user flows (login → search → place marker → directions) and emits executable test scripts in the target framework (Appium/Java, Playwright/JavaScript, etc.). The generated code includes:

• Boilerplate setup (driver initialization, mock server configuration)
• Parameterized test methods with placeholder data
• Basic assertions (e.g., “element with accessibility id X is displayed”)
• Hooks for tearing down mock services

1. Cross‑session learning – Subsequent runs reuse the previously explored graph, skipping already known as a “knowledge base”. The tool avoids re‑exploring dead ends and focuses on new or modified paths, making each execution faster and more accurate.

Practical Example with SUSA

Suppose you have an Android delivery‑driver app that integrates the Google Maps SDK for route visualization. You upload the latest APK to SUSA’s cloud. After a 10‑minute exploration session, SUSA reports:

• 3 crashes related to map tile loading when the device switches from Wi‑Fi to cellular.
• 2 ANRs occurring when the user rapidly zooms while a directions request is in flight.
• A dead button in the “Report Issue” overlay that lacks a content description.
• 4 accessibility violations: map zoom controls not reachable via TalkBack,