Debugging

How to troubleshoot and test errors before escalating to ED.

TL;DR

Remote device testing helps diagnose app-specific issues by simulating different devices to replicate and document bugs before escalation.

Services like Browser Stack and Kobiton enable testing across various Android models.

Before reporting an issue, testers should verify display settings, confirm the issue is app-specific, and collect debug reports. If needed, temporary end-user access can be requested via a secure proxy system, expiring within three days.

Proper tools, including multiple devices and temporary email accounts, are recommended to optimise testing and support.

Remote Device Testing

In-depth testing for app-specific issues ensures that:

a) correct information is supplied in full, b) a bug is observable and replicable, and c) technical support knowledge can be documented.

Using Remote Device testing, device-specific issues can be simulated before escalating an app-specific issue to ED. If the issue affects all device types, you will not need to carry out this step.

Remote Testing Services

Android has over 6000+ device types - remote testing services will allow you to simulate devices in order to replicate a reported issue, and to observe and confirm the issue in detail.

1. Browser Stack offers live app testing, which allows you to install apps from Google Play. https://www.browserstack.com/app-live

2. Kobiton is similar to Browser Stack but is app-focused. https://kobiton.com.

3. End-User Access. Request access to a user's account.

Test Checklist

When reporting an issue the following checks should be completed prior to reporting:

• Simulate the device on remote testing services

• Video recording of the bug being observed

• Have info on the display settings the user was using

• Confirm that the user's issue only occurs on the app and no other apps

• Search device manufacture community forums for pending issues

• Ask user to file a device debug report (from their App Account)

• Request End-User Access from the user in order to gain temporary app access

End-User Access

End-User access allows you to provide end-user app account level support. This should only be used as a last resort when other support measures cannot determine the issue.

For account-level app support, you can request temporary access to an end-user account via the Control Centre. This ensures full transparency and granted permission from the end-user.

Support Steps to Follow

Before requesting access, ensure you have exhausted other support steps and troubleshooting. Gathering the right information assists in resolving the issue in a timely manner.

Step 1. Your first step in end-user support is to ask for information to be provided. This should include details about the app, account and device being used. Account information is important to ensure that when the issue is investigated, account-level information is accurate.

Step 2. If applicable, request an app debug report to retrieve device logs. This report provides device offline data to be checked against backend records.

Step 3. Check configurations on the backend if applicable. These may include group assignment, targeting and data manager depending on the feature or problem.

Step 4. Attempt to replicate the issue. With the information, gathered try to replicate the issue the user is experiencing either by using your own account or creating a temporary email account. If you are able to replicate the issue, then report it as a bug on your GitHub support channel.

Step 5. If you are not able to replicate the issue. Your last step would be to send an end-user access request from your Control Centre. Ensure that the end-user is made aware of the request and who will be sending the request.

How to get End-User Access

To gain access to an end-user account, the requester's account is given access as a proxy to the end-user's account. This approach means that the end-user is not required to share their password.

Request is sent. First, an Account Access request is sent to the end-user with a 6-digit request code and a link. The end-user can accept or decline the request.

Request is accepted. The end-user accepts the request and thus gives the requester proxy access.

Proxy Sign In. The requester can now use their own credentials to sign in to an app. Once signed in, the requester will be given access to the end-user's account.

Expiration. Account access will automatically expire within 3 days or when the request is manually expires via Control Centre.

Support Recommendations

If you are a support user, we highly recommend you have the right tools to make testing issues more optimal and accurate. Below is a list of support tools we recommend you have:

Multiple Devices. Ensure you have both have an iOS and Android device as sometimes issues can occur on specific devices. Having both devices will allow you to test for the issue based on the user's device.

Temporary Mail. Sometimes you may need to test with new accounts. If this is the case, you can use a temporary mail service. We currently recommend https://temp-mail.org/en/