When something crashes in an app, fixing the bug is usually quite straightforward. But apps can also be blighted by bugs that don’t result in crashes, and this is where things start to get interesting. To find and fix these bugs, you will require as much information as possible and probably a combination of tools.
Let me explain a process we know as ‘bug forensics’, based on a real bug that has impacted one of Bugfender’s customers.
The Bug
The customer came back to us, complaining that there’s a value missing in a report generated by their app. As you’ll see below, Question 5 is empty when it shouldn’t be. So straightaway, this seems like a potential bug.
Bugfender Logs
As the information is sent to the Bugfender platform via an iOS and Android application, the first step in cases like this is to check Bugfender’s records to examine the data the user sent. As we know the exact date the answers were sent, we can check the logs for that date on Bugfender.
Locating the user device and finding the logs
When we check the records on Bugfender, we need to localize the specific device that’s experienced the problem. To make things easier, you can use Bugfender’s device data (you can read more about how to identify a device in our knowledge base).
Using the Bugfender filters, we can easily locate the device we are looking for.
Now we can look deeper and investigate the logs. As we know the time the user sent the answer, we can jump to the session at that time and search for the logs for that specific date. Here you can see how we go directly to a session:
Checking the logs allows us to find the request (that’s why we recommend you log all network requests, giving you the power to debug all kinds of issues). As the session might contain a lot of logs, another key recommendation is to add a tag to your logs.
In our case, all network requests use the tag API, so let’s filter the logs using this tag. Now you just need to scroll a little bit to find the logs of the network request we are searching for.
With the logs, you can analyze whether it was an app problem or something related to the backend. In this case, the user request seems OK, as it contains the missing answer — even though this is missing in the system.
This time it wasn’t the app’s fault, but in other cases we have found different scenarios. Thanks to this, we have figured out that people use certain features in a very different way to that which we initially thought, and it has also helped to add some missing validations that developers didn’t find important when building the app.
Checking the Server
On this project, we use Papertrail to gather all the server logs in a single place, so we can search and analyze what’s going on there.
With all the information found in Bugfender, the backend guys have a lot of information to find out whether there’s any problem on the servers or not. And after some minutes they have figured out that there was no bug at all.
It was one of the platform users that deleted the record, but he didn’t remember doing that. With the server logs we have the proof that, for once, it wasn’t the developer’s fault.
Conclusions
We have seen how useful Bugfender can be in checking bugs in systems with multiple components, without the logging capacity of Bugfender. In this case, something that was reported as a bug actually wasn’t in the end.
As a developer you need to plan in advance what you want to log, so log as much as information you might need in the future. Logs are a lot more cheaper than the time your team will spend trying to figure out bugs in your apps!
We publish tutorials and debugging stories almost every week. You can follow us on Twitter to be updated or use the box below to subscribe to our quarterly newsletter.
