Detecting bugs in mobile apps, especially after it has gone live, is often challenging. Unlike web applications where there is always the option to login to the server and check logs to collect enough data to reproduce the bugs, mobile apps reside on devices that are owned by someone else and developer has no easy way to collect information from the device.
This is where tools like Finotes (https://finotes.com), Bugsee (https://bugsee.com), Bugsnag (https://bugsnag.com) and such have a role to play. These tools come with in-built intelligence to identify most of the possible bugs that can happen in mobile apps. In addition to that these tools provide support to report issues that the developer is able to anticipate.
Well, I would like to inform the readers that I am a co-founder of Finotes. I am not proposing to use Finotes, but in this article I am presenting some of the decision parameters that developers should consider when choosing a bug tracking tool for live mobile apps.
Let us explore some of the parameters that should be taken into consideration while selecting a bug detection and tracking tool.
Most bugs in iOS and Android apps are memory related, HTTP API related or function call flow related. These issues then manifest as crashes, delayed loading of screens, unexpected output, broken functionality, unresponsive UI elements and such. Tools should have capability to handle these situations and report these bugs in real time.
Detecting bugs is one thing, and collecting enough data to help the developers to reproduce them faster is another. To successfully reproduce the bug, developer need to be provided with time of occurrence, location information if available, device information, device state information at the time of occurrence of bug, activity trail of user and stack trace along with a detailed description of the bug.
Data should be collected in realtime and with out exposing the identity of the user. Ideally no data that can uniquely identify the user should be shared with bug detection tools.
It should not come to a situation where the tool's SDK / framework end up consuming more memory than it should. Also it's important that such SDKs do not add unreasonable delta to the size of APK and IPA.
Being good enough to be used in live mobile apps also means such tools are good to be used in development and testing phase. QA teams will be able to report lot more bugs with such tools and with lot more information that can be manually captured.
Reported issues will be handled better if similar issues are grouped into tickets and can be pushed to a proper bug tracking system like JIRA.
When selecting a third party SDK or framework for integrating with iOS or Android apps, ease of doing that will be an important determining factor. Whether the developer is using Java or Kotlin for Android, or if the developer chooses Swift or Objective C for iOS, or if they prefer Flutter, React Native and such, they should be able to do the integration with minimal code change.
While developers may feel that they have tested the app properly and no bugs will occur in production, reality proves otherwise. While testing, developers capture those bugs that they encounter. Also in most scenarios number of bugs captured in development and testing phase are directly proportional to number of test cases that are run. But there are more possible cases given the number of phones and OS versions out there. Proper automated reporting of bugs and faster reproduction followed by timely fixing will help to improve the performance of the app and thus reduce the number of user dropouts.
Happy bug fixing ... 🙂