A reusable test phone remembers things. Our view: the useful question is whether the next test should remember them too. Treat persistent state as a deliberate test input, rather than assuming that the same device means the same starting conditions.
Name the lifecycle you need
Our recommended QA plan separates a clean-start path from a returning-user path. The clean-start path begins with an agreed fixture and known permissions. The returning-user path preserves relevant history, such as a draft or an existing login. Record which path a result belongs to before comparing two runs.
Android's virtual-device documentation describes controls for configurations and stored user data, including wiping a virtual device's data. The Create and manage virtual devices guide is useful when defining an emulator baseline. Those virtual-device controls are not evidence that a remotely rented physical phone offers the same reset or snapshot mechanism.
| State to record | Why our workflow records it |
|---|---|
| Installed build and install route | Distinguish the release under test |
| Account fixture and login state | Separate onboarding from returning-user behavior |
| Permissions and local drafts | Make relevant starting conditions explicit |
| Locale, font settings, and time zone | Explain visible or formatting differences |
| Cleanup performed | Show what the next run can safely assume |
Use a before-and-after note
For a manual test session, write the starting fixture before interacting with the app. At the end, record the result, state changes, and cleanup actually performed. If a cleanup step fails or cannot be confirmed, leave the field unresolved and flag it for the next operator; a checkbox should represent an observed action.
In a hypothetical draft-editor test, the first run preserves a local draft and the second run begins with an empty draft list. In this invented example, different startup screens may be consistent with the different fixtures. The tester must establish the expected behavior for each path before calling the difference a regression.
HiveReach's current HiveReach product guide describes manual screen viewing, pointer gestures, Android navigation, and the phone's on-screen keyboard. For a supported and permitted test, verify how the required app build and fixture are prepared. This article does not promise automated reset, snapshots, build installation, or persistent account state across every rental event.
Protect the reproduction before cleanup
When an unexpected failure appears, our recommendation is to preserve enough evidence to recreate the starting state before requesting a reset. Use test data and your approved evidence handling process. Do not preserve sensitive client information merely because deleting it would make a convenient experiment harder.
For an agency, assign ownership of fixtures and cleanup independently from ownership of the client account. For a solo tester, keep the same responsibilities in a short session note. A reusable device becomes a useful QA resource when the next run begins from documented conditions rather than folklore.