What is banking cross-device testing?

Banking cross-device testing checks whether a banking service behaves correctly and securely across the different devices customers use, such as phones, tablets and desktop computers. It covers device-specific presentation and input, as well as banking workflows that continue or change when a customer moves between devices. The aim is to find compatibility and state-handling defects that could affect access to accounts or financial transactions.

What banking cross-device testing covers

A test device is more than a screen size. Relevant variables can include the operating system and version, browser or app version, display dimensions, input method, network conditions and device settings. A bank may test its mobile app on supported phone and tablet configurations alongside its web portal in desktop and mobile browsers.

Tests check that account information is legible, controls remain usable, and actions produce the same intended result across supported configurations. They also examine device-dependent behaviour such as biometric sign-in, push notifications, keyboard handling and links that open a banking app. Which behaviours apply depends on the bank's channels and product requirements.

Cross-device testing can include a customer journey that starts on one device and continues on another. For example, a customer might sign in on a phone, review a payee on a desktop, then return to the phone to approve a payment. The test should verify the expected authentication and approval steps, transaction status, and account data on each device.

How to plan the device coverage

Start with the supported device, operating system, browser and app combinations. Prioritise combinations using customer usage, product support commitments and the impact of failure. Include devices with different screen dimensions and input methods, along with configurations that use features such as biometric authentication where supported.

Testing every possible combination is usually impractical. A risk-based matrix can cover common configurations and high-impact banking journeys, with targeted checks for less common combinations. Record the chosen configurations and the reason for their inclusion so that changes to supported devices or customer usage can prompt a review.

The test environment must support the relevant channels and dependencies. Prepare controlled test accounts, known balances and payment data, and suitable authentication options. Use a test or sandbox environment for transactions, and confirm how test data is reset. Environment drift, such as different service versions or configuration between web and mobile channels, can make failures difficult to reproduce or attribute to a device.

Example: resume a payment on another device

A test case can check a scheduled transfer that a customer starts on a phone and reviews on a desktop:

1. Sign in to the mobile app using a controlled test account and enter the transfer details, stopping before final approval.
2. Sign in to the web portal with the same account on a supported desktop configuration. Check whether the transfer appears in the expected state and whether its payee, amount and date match the saved details.
3. Complete the required approval step on the permitted device or channel. Return to the app and confirm that the displayed status agrees with the web portal.
4. Verify the resulting transaction through an authorised test record or service response. Check that the transfer was created once and that the account data reflects the expected result.

Expected results should specify what happens if the session expires, the customer changes a transfer field, or approval is attempted from a device that is not permitted. These checks expose stale screens, inconsistent workflow state, duplicate submissions and incorrect handling of authentication requirements.

Interpreting failures

A defect may come from the device interface, a channel-specific implementation, shared services or the test environment. A clipped button on one phone suggests a presentation or layout issue; a transfer shown as approved on one channel and pending on another may point to state synchronisation or caching. Compare the same account and transaction across devices, then inspect relevant service records and application logs where access permits.

Cross-device testing differs from cross-browser testing, which focuses on behaviour across browser implementations. It also differs from responsive testing, which checks layout adaptation across viewport sizes. Banking cross-device testing can include both, while adding device-specific functions and continuity of banking workflows across channels. A combined test suite should report these dimensions clearly so a pass on one browser or screen size does not imply coverage of every device journey.