Key checks
Work through the guide
Start with the section that matches your task, then follow the evidence and recovery steps before calling the test complete.
Gate 1: define the claim before testing it
“Changes location” is not a complete requirement. Write whether the test concerns a selected map place, a device location delivered to your own app, a network-derived region, a geofence result, a route, or a third-party service decision. Name the operating-system version, device, app build, account, and backend environment.
Then convert the claim into a visible or machine-readable outcome. Examples include the nearest store identifier, a geofence entry event, an address label, a delivery-availability response, or a route progress state. A map marker that moved inside the changer is not proof that the target app received or accepted the same input.
- One signal under test.
- One named app build and account.
- One expected product state.
- One tolerance for distance, timing, or boundary behavior.
Gate 2: require evidence from both sides
The changer should expose a current target, mode, and timestamp. The target app or owned backend should expose a separate result. Compare them during the same run. If the tool reports success but the app is unchanged, investigate permissions, cache, other location inputs, request matching, and server policy instead of repeating the same tap.
For WLOC, useful evidence includes the saved target, the newest compatible request and result timestamps, route state, and recovery or pass-through status. For an app you develop, add a test-only diagnostics screen or structured log that records the coordinate source, accuracy, timestamp, and product decision without retaining unnecessary personal location data.
- Tool evidence: target, active mode, request, result, timestamp.
- App evidence: location observation, product decision, cache age, account state.
- Backend evidence: test-safe request or event identifier when applicable.
- Privacy evidence: only the minimum data needed for the test.
Gate 3: challenge cache and boundary behavior
A single downtown coordinate is a demonstration, not coverage. Use a small matrix: a point well inside the intended region, one just outside, one near the edge, and a return point. If the feature uses time or movement, add a short route with a clear entry and exit. Keep the target spacing larger than the app's displayed accuracy so an ambiguous result does not look like a pass.
Repeat one case after a cold launch and one after the app has shown an old region. That exposes whether the screen is driven by a new observation, a persisted user choice, an account profile, an IP-derived region, or a cached backend response. Record what action legitimately refreshes each layer.
- Interior point for the happy path.
- Exterior point for the negative path.
- Edge pair for radius and rounding behavior.
- Return point for recovery and stale-state detection.
Gate 4: make recovery a release criterion
Location test state can outlive the moment that created it. A route may continue after a static target is cleared. A target app may retain its last city. A backend may cache regional eligibility. Recovery therefore needs its own acceptance criteria and evidence.
Stop any active route, remove static targets and fallback coordinates, confirm the test path is in pass-through or normal mode, refresh the target app through its supported flow, and obtain a new result. If the old state remains, identify whether it lives in the tool, iOS permission or cache, the target app, the account, or the server before declaring the changer unsafe or broken.
- No active route.
- No persistent target or hidden fallback.
- A fresh normal or pass-through result.
- The target app and backend no longer show the test-only state.
Decision table
A scorecard for GPS changer claims
Use pass, conditional, and fail results instead of a single “worked” checkbox.
| Claim to evaluate | Evidence required | Failure signal |
|---|---|---|
| Repeatable coordinates | Saved full-precision target and same parsed result on rerun | Only a rounded label or visually placed pin |
| Target app changed | Fresh app observation or owned-backend decision | Only the changer's own map moved |
| Works without jailbreak | Documented setup on an unmodified test device | Requires an undisclosed exploit or system modification |
| Supports routes | Ordered waypoint, timing, entry, exit, and stop evidence | Static jumps marketed as movement |
| Protects privacy | Clear retention boundary and minimal diagnostic payload | Searchable coordinate history with no user control |
| Restores normal behavior | Fresh pass-through result and cleared app state | Old target survives route stop, relaunch, or refresh |
| Universal app compatibility | Treat as unprovable | A universal guarantee ignores app and service controls |
Practical playbook
A 30-minute acceptance run
Use the same sequence for every candidate so product names and polished demos do not change the standard.
- 1Minutes 0–5: freeze the environmentRecord device, iOS version, app build, account, permissions, network client, backend, and the real starting state.
- 2Minutes 5–10: run the low-risk targetPaste a public map link or coordinate, verify parsing and current timestamps, then capture the target app's separate result.
- 3Minutes 10–18: test inside, outside, and edgeRun the smallest matrix that can expose radius, regional, rounding, and stale-cache errors.
- 4Minutes 18–23: interrupt one stepRelaunch the target app, refresh a profile, or temporarily deny permission to learn which failure state the diagnostics can distinguish.
- 5Minutes 23–30: restore and prove itStop motion, clear targets, confirm pass-through, obtain a fresh normal result, and save the evidence with the test record.
References
Verify the claims in this guide
Open the references below for the platform documentation, service policies, and product boundaries used in the guide.
Simulating location in tests
Why controlled inputs, GPX routes, and distinct UI-test handling improve reliability.
Open the source ↗isSimulatedBySoftware
That source information is one observable attribute, not a universal app decision.
Open the source ↗How WLOC works
The parsing, coordinate, compatible request, diagnostics, and recovery layers WLOC claims.
Open the source ↗Compatible setup and recovery guide
Current setup dependencies, troubleshooting order, and pass-through boundary.
Open the source ↗FAQ
GPS changer · QA evidence FAQ
What is the strongest proof that a location changer worked?
A current tool-side result plus an independent observation from the owned target app or test backend, both tied to the same input and time window.
Why is a moved map pin not enough?
It proves that the tool can display a selected place. It does not prove which location signal the target app used or whether the app accepted it.
Should a GPS changer promise every app?
No. Apps can use different permissions, caches, sensor inputs, account history, network signals, and server-side policies. Universal claims hide those independent controls.
How many locations should an acceptance test use?
Use the smallest meaningful matrix: one clear interior point, one exterior point, an edge pair when boundaries matter, and a return point. Add a route only for movement behavior.
What data should a QA report avoid?
Avoid unnecessary personal routes, home addresses, credentials, production account data, and long-lived raw location histories. Prefer public test points and scoped identifiers.