We all have been in situations where we had to send app builds to multiple teams for their own testing needs. Although it is hard but still possible to keep track of them with build and version numbers, it is not an efficient way to handle this situation. When there are multiple API environments setup that testers need to connect to, advertisement ids need to be flipped to test ads, get detailed debug logs from testers etc., it becomes a nightmare to coordinate.
In an effort to make this experience as convenient as possible for all teams involved, we recommend incorporating a hidden screen in the application, a debug panel, where all teams can change their variables for their needs. This is an easter egg implementation i.e, this is something that should be invisible to the end users outside of your teams. However, the internal team would have quick access to a hidden screen that gives them the option to configure the behaviour of the application.
Uses of a Debug Panel
You can be creative in your own ways of how you want to configure your Debug Panel and how it can affect various features of the application. However, the following are some of the common use cases we have faced:
Switch between environments
This is one of the most important features of a Debug Panel. This allows the QA team to easily switch between different data environments to test any new features or to easily reproduce bugs. If there are more configuration data retrieved from your backend systems, then changing the environment not only changed the data feed but can also change the behaviour of the application.
When your applications start to incorporate significant amount of advertisement technologies, it needs to be rigorously tested. Most of the time, the ads are tested by a separate team due to its complexities. It could be a third-party vendor or a separate in-house team. It is better to perform it with test placement ids and values than altering production values. However, issuing a separate build for such purposes is very time consuming. Hence, Debug Panel can help in such situations where they can configure it locally in one device.
Troubleshooting live with the tester
This also helps the development/product team perform troubleshooting live with testers and occasionally with early users of certain features. Consider a case where a user is experiencing a particular issue and was reported by this user. The debug panel enables the internal teams to reproduce the exact scenarios that causes the issue faced by the user on a different environment without affecting the live data feed and this speeds up the process of identifying issue and performing a bug fix.
Enabling and testing planned features
Another frequent use case for Debug Panels is the ability to turn-on/off upcoming features that are already developed but has not gone live. With multiple build configurations and settings, the team can enable or disable certain features in the application in real-time. Also, it is useful for certain features to be enabled for very small subset of users who participate in early testing. They can enable that through Debug Panel.
Enabling detailed analytics and logs
Advanced analytics and logs are not only good for learning user behaviour but can also provide insights into issues. A production version of the application need not have debug level analytics and logs enabled but will be very useful to be enable such details while testing. Testers can also send the logs manually as an email or upload to server through the Debug Panel.
Better collaboration between teams
As an application grows tremendously in number of features, the amount of time needed on testing and debugging real-world scenarios also grows exponentially. Every feature, after implementation, is sent to multiple teams and processes to be vetted prior to going to production. Having the ability to change settings in Debug Panel, makes it easy to collaborate between teams. For instance, whenever a new feature implementation is complete, the development team first deploys the changes to a development environment. The QA team can then use the same front-end application but point it to a different backend environment and test these new features without having to depend on the development team to issue a new build pointing to a different backend environment. This saves a lot of time.
Additional useful information
The debug panel also shows additional useful information such as the app version, OS version, bundle ID, device type, device UUID, memory info, cache info, carrier info and network health. This is useful for testers to create tickets in the project management system, if they find bugs or other concerns.
Where to hide the Debug Panel
I would say that this is one of the most important factors of this component. If you are not creative in hiding it, your end users can easily open it and play with all the settings in there. There are many places in an app to hide it and it could be opened with a combination of different gestures. There are two factors to be considered: the complexity in finding where it is, the ease in performing the gesture to open it. If you follow these, you should be able to hide it from your users and still your teams should be comfortable using it when they need to.
In general, there is no definite answer to this. Some of the most common examples are:
- To celebrate its one billionth user, FB messenger recently introduced an easter egg feature wherein if you choose the basketball emoji and then tap on this, this would start a basketball game.
- Youtube came out with an easter egg implementation in which, when a user typed in “Do the Harlem shake” and this would make the Youtube logo dance.
- Other implementations include triggering the hidden feature by long press, double tap, typing certain phrases into the search tab, tapping on the screen for a specific number of times
Over a period of time, we noticed how useful this feature has been for the internal teams, especially for the applications that have millions of users and multiple features being rolled out every month. During any emergencies it’s always been easy to setup a test case in the dev/stage environment and switch the app to this environment in order to reproduce the issue. This has greatly reduced the effort and time required to issue fixes.