A mobile app runs in an environment controlled by the user and operating system. Camera access may be denied, the screen locked, a system dialog opened over a form, or notifications disabled in settings. Quality becomes evident in how well the product handles these changes.
QA checks state transitions and preservation of user work. Permissions, interruptions, and notifications are related, but each needs separate expectations: access rights, scenario recovery, and correct message interaction.
Permissions are mutable state
Do not treat a permission as a checkbox granted once at installation. Users can deny access, grant it later, revoke it in settings, or choose limited access. Available states depend on the resource, OS version, and app configuration.
Camera, location, photo, and microphone access require different checks. Selected-photo access and approximate location are legitimate user choices rather than accidental environment problems.
When to request permission
A good request is linked to an action: camera access when adding a photo, or location access when searching nearby. QA checks that the explanation matches the feature, denial is possible, and the request does not reappear whenever the screen opens.
Android recommends requesting permissions in the context of a feature and keeping the rest of the app functional after denial. System dialogs vary by OS, so cases should describe the expected meaning rather than one exact window design.
An access test matrix
For every protected feature, prepare initial states and expected reactions. Confirm state in system settings rather than relying on old text inside the app.
- →Access not yet requested: the feature initiates the request correctly.
- →Access granted: the resource is used as intended.
- →Access denied: a clear explanation and accessible alternative are provided.
- →Access revoked while backgrounded: the state updates when the app returns.
- →Limited access: the app works with the data actually available.
Returning from settings is especially important. The screen must not continue showing camera access as available simply because it was available before navigation.
What counts as an interruption?
Interruptions change app activity or divert the user: an incoming call, device lock, notification shade, app switch, system permission prompt, or file selection. They differ in duration and consequences for the process.
Backgrounding, removing a recent-apps card, and force-stopping are not equivalent. Android and iOS rules differ; record the exact action instead of a vague instruction to "close the app."
Practical example: attaching a photo to a support request
Consider a support request form with text and a photo. The aim is to establish that denial or interruption does not destroy completed work.
- 1.Enter request text and tap add photo before access has been granted.
- 2.Deny permission. Expect the text to remain, a clear message, and a way to submit without a photo if requirements allow it.
- 3.Grant access in settings and return. The feature should recognize the new state without reinstalling the app.
- 4.Take a photo, then lock the device before attachment completes.
- 5.Unlock and return. Check text integrity, attachment status, and the absence of repeated submission.
- 6.Submit and compare with the server: one request, the correct photo, and preserved text.
Separately repeat with cancellation of system file selection. User cancellation should end selection normally, without a false failure alert.
Which data should survive a return?
Define expectations for each state type: entered text, selected product, list position, payment operation, and unfinished upload. Sensitive screens may require reauthentication, but this should be compatible with preserving safe user data.
Recovery after OS process termination may differ from a brief background transition. Separate these checks so successful background recovery does not conceal a process restoration failure.
Notifications: permission and display
Notification permission does not guarantee that a particular message appears as a banner. System settings, Android channels, Focus modes, application state, and message type all matter. Android 13 and later provide the POST_NOTIFICATIONS runtime permission for nonexempt notifications; details also depend on the target SDK.
Check local and remote notifications separately. The app creates a local notification on the device under defined conditions; a remote one passes through the server and delivery service. These chains have different failure causes.
What to check during interaction
Tapping a message should open the correct object for the current user. If the session expired, safely resume the route after sign-in. If the object was deleted, show the intended empty state.
Check the locked screen, active app, background state, several consecutive messages, and repeated tapping. Assess confidential lock-screen content against agreed requirements and system preview settings.
Common mistakes
Testing only "allow everything" misses many real scenarios. Another mistake is declaring a missing banner a defect before establishing whether the event was created, accepted by the delivery service, and permitted by device settings.
There is no need to combine every interruption artificially with every button. Choose points where data loss, repeated operations, or access violations are likely. This provides a manageable scope and clear priorities.
Key takeaways for QA
Test after permission changes, during interruptions, and after returning. A good outcome preserves work, reflects current access, and provides a safe route from notifications. Record OS state, the exact interruption, and its timing in every bug report.