ServiceNow Mobile Experience Testing and Acceptance Checklist

Mobile experience testing checks ServiceNow mobile apps on iOS and Android, and responsive web pages opened in mobile browsers. Test on real devices rather than emulators, set performance targets for slower networks, and cover offline behaviour, security of cached data and battery use before a release moves to a staged rollout.

Mobile Testing Layers and Platforms

Mobile experience testing covers ServiceNow mobile apps (native iOS and Android) and mobile web (responsive web accessed via mobile browsers). Native app testing validates that the app installs, launches, authenticates, and functions correctly on target iOS and Android versions. Test on actual devices, not just emulators, because device-specific behaviors (network interruptions, sensor access, battery drain) are not replicated in emulators. Mobile web testing validates that the web interface adapts to phone and tablet screen sizes, touch input works correctly, and performance is acceptable on cellular networks. Performance testing on mobile is critical; users access ServiceNow over 3G, 4G, or WiFi with varying latency and bandwidth. A five-second load time on desktop is acceptable; a five-second load time on 3G is not. Set performance targets for mobile and test them explicitly.

Offline capability testing (if the mobile app supports offline mode) validates that users can view previously cached data and initiate actions when network is not available; when network is restored, queued actions are synced. Security testing validates that authentication tokens are not exposed in app storage, that cached data is encrypted, and that logout removes cached data so another user cannot access a previous user’s information if the device is lost. Battery and data consumption testing measures whether the app drains battery excessively or uses excessive data, which would discourage users from installing and using it.

Entry and Exit Criteria for Mobile Release

Mobile testing begins once the app can be installed on test devices without crashing. The mobile app must communicate with a ServiceNow instance for testing, so staging environment connectivity should be verified before UAT begins. Exit criteria require zero critical issues (app crashes, authentication failures, data loss), high-priority issues resolved, all regression tests passing, and UAT sign-off from mobile users. Mobile apps often have staged rollout (beta to an initial beta cohort, then one-quarter of users, then all users) so issues found in early stages do not affect all users. Each rollout stage should complete successfully before expanding to more users.

Mobile Device and Network Test Matrix

The following table outlines essential mobile test scenarios and platforms:

Common Mobile Failures and Regression

Authentication failures occur when mobile app and backend lose sync on session tokens; a long-running session on mobile may have a valid token on the app but an expired token on the backend, causing the app to crash or show incomplete data. Test session expiration and refresh token behavior explicitly. Memory leaks occur when the app holds references to data structures that should be released, causing the app to slow down or crash over time; test the app for extended periods (several hours of continuous use) to detect memory issues. Background sync failures happen when the app syncs data in the background but does not recover if the sync is interrupted; test network interruptions (toggle WiFi off and on) and verify the sync resumes correctly.

Platform-specific issues emerge during UAT: a feature works on iOS but not Android due to API differences, or a screen layout is correct on iPhone but overlaps on larger iPad screens. Test on multiple device sizes. Gesture conflicts occur when the mobile app’s gestures (swipe to go back) conflict with the system’s gestures; test that swipes and long-presses behave as expected and do not trigger unintended actions.

Mobile Rollout and Monitoring

Plan a staged rollout: release to internal testers first, then beta to an initial beta cohort, monitor for crashes and bugs, expand to broader rollout, then full rollout. Each stage should run long enough for issues to surface. Use crash reporting to identify issues users encounter in the field that testing missed. If a critical issue is discovered during rollout, rollback to the previous version, fix the issue, and re-test before rolling out again. Establish a mobile support hotline for users to report issues immediately so problems can be addressed quickly.

Designing a mobile test day around the tasks users really do

Mobile acceptance testing tends to fail in a predictable way. The team tests every screen once, on office Wi-Fi, with a test account that holds every role, and the release passes. Then a technician finds they cannot finish a job in a car park with two bars of signal. The remedy is to design the test around complete user tasks, run them under the conditions where the work actually happens, and record each defect in a form that shows its effect on the job. This section is for the QA lead and the business tester who will plan the acceptance cycle.

Build the scripts from tasks, not screens

Start from three or four end-to-end tasks that represent a working day for each user group, drawing on the candidate use cases as the starting point. A field task might be: receive an assignment, open the job, record a completed step, attach a photo, and close the job. A script that walks those steps in order finds problems that screen-by-screen checks miss, such as a photo upload that succeeds but leaves the job unable to close. Keep each script short enough for one tester to finish in a single sitting, and give each script one user role, so results are not blurred together.

Choose conditions by where the work happens

Rather than testing a generic network, list the places the user group works and the conditions in each. A depot with thick walls, a moving van and a rooftop site each need a different condition. Use a throttled network profile for the slow case, a deliberate signal drop for the interrupted case, and a standard office connection as the baseline. Record which condition produced each result, because a pass under good conditions says nothing about a bad one.

A triage table for defects found during acceptance

Not every defect calls for the same response. The table sorts defects by their effect on the task, which serves the release decision better than a generic severity label alone.

A test-day procedure

1. Confirm the test build and the staging instance match the release notes, and that the test accounts carry only the mobile role under review.
2. Run each end-to-end script once under baseline conditions, then repeat the same script under the throttled and interrupted profiles.
3. Record each step with a time stamp and a device identifier, so a defect can be reproduced on the same handset.
4. Log each defect against the triage table on the day, with the condition in which it appeared.
5. Close the day with a short review of blocked tasks, and agree who retests each one before the next session.

What to do without a device lab

A full device lab is not always practical. A smaller team can cover much of the risk with two handsets, one from each major operating system family, passed between two testers who swap roles. Ask the device team which models your users carry and test those first. A pass on a model nobody uses is worth less than a second pass on the common one.

Signs the acceptance cycle has worked

Every must-have task has been completed end to end under at least the throttled profile, and each defect carries a recorded condition and a triage class. Business testers recognize the tasks as their own, and the sign-off conversation is about trade-offs rather than whether the app works at all. If the cycle ends with nobody certain which conditions were tested, the scripts or the condition list need rewriting before the next release.

Matching the cycle size to the change

A label or list-order change can be checked quickly and does not justify the whole calendar. Run the affected task once on each device family and record the result. Reserve the full cycle for new tables on the phone, changes to offline behaviour and any change to authentication.

Frequently asked questions about mobile acceptance testing

How many end-to-end scripts should one release carry?

Enough to cover the primary task of each user group, and no more. One script per group is easier to run and to review than dozens of scripts that overlap.

Should testers use their own phones?

They can be used for exploratory testing, but the formal cycle should use managed devices that match the enrollment policy, so the result reflects what users will hold.

What evidence is enough for a business sign-off?

A recorded run of each must-have script under the agreed conditions, the defect log with triage classes, and a list of accepted open items with owners. Screenshots help, but the log is what a later reviewer will rely on.

Can automated tests replace the test day?

Automated checks suit regression work such as sign-in and basic navigation. They rarely show how a task feels on a slow connection, so keep a human test day for any release that changes the task itself.

Next step

The mobile experience best practices guide covers the design habits that make a mobile release easier to check.

Related guides: Troubleshooting ServiceNow Mobile Experience: A Practical Guide.