How to reproduce the steps that caused an app bug

When an app is being developed, a lot of effort goes into making sure that every feature works as expected.

However, even the best apps sometimes have bugs and other issues that can cause problems for users, such as crashes, slow performance, and other annoyances.

When this happens, developers need to know how to reproduce the steps that caused them so they can fix them as quickly as possible.

That’s why in this article we’re going to discuss exactly how you and your team can do just that.

Stay tuned!

How to reproduce the steps that caused the bug

The key to fixing an app bug is being able to reproduce the steps that led to its occurrence.

This way, developers don’t have to spend hours trying different scenarios in order to figure out what’s wrong with the app.

Instead, they can simply repeat them and fix any issues as they arise.

In the following sections, we’ll go over the most common steps that developers take when reproducing bugs and explain why they’re so important in the process of fixing them.

Replicate the environment

The first step in reproducing a bug is to make sure that developers are doing it under the same conditions as when the bug was originally encountered.

This means that if the tester’s internet connection was slow, they should ensure that theirs is also slow.

If the testers were using an outdated browser or operating system, they should use such a browser as well.

If the testers had a lot of apps open and running at once, then the developers should do the same.

When you look at the bug report below, you’ll notice that it includes a lot of technical details about the environment in which the bug was found.

This data is important because it gives the developers a clearer picture of the situation that caused the bug.

By taking this information into consideration, they should be able to replicate the exact circumstances in which the bug occurred.

This will make it much easier to reproduce it, while also improving their chances of identifying the source of the problem.

Follow the steps to reproduce

In well-written bug reports, the steps to reproduce are always given prominence, and it’s safe to say that they’re the most important part of bug reports.

Because they make it possible to reproduce the bug, they’re also the key to identifying and fixing it.

Steps to reproduce are usually numbered and described in the following format:

Source

It’s here that developers will need to be especially careful because this is where the rubber meets the road.

The testers who wrote the bug report may have done a good job describing what’s going on, but it’s up to developers to figure out what exactly they did and how that caused the problem.

The best way to do this is to read through the steps, try them out themselves, and see if they can reproduce the same results.

If not, then they’ll need to ask for more information from the testers or try some other approach.

Deviate from the steps to reproduce

Reading a bug report and trying to determine what steps were taken is often challenging.

Often this involves a lot of guesswork because the steps aren’t always clear.

Therefore, in these cases, developers should deviate from them a bit and try out different variations on the steps to see if any of them lead to the same outcome.

That’s exactly what John Kotzian, a senior solution architect at Applause, did when faced with what seemed to be a hard-to-reproduce bug.

Certain readers were unable to read articles on the client’s website because the HTML code was blocking out the content.

So he started with inspecting known facts about the bug:

The first thing I did was to look at the existing evidence, the description of the issue, and—more importantly—the screenshots the readers had provided.

From there, he went on to search for the bug in different browsers and operating systems, and discovered that only Internet Explorer was affected by it.

Articles were being blocked, he determined, because of a problem with one of the ads on the site that prevented readers from accessing content.

As you can see from this example, developers will sometimes have to go beyond the steps described in the bug report and try to reproduce the problem on their own.

In these cases, it’s up to them to investigate the issue further and try to understand why it’s happening.

Look for a pattern between bugs

If everything else fails and developers are still not able to reproduce the bug, it might be time for them to do some real detective work.

They should look for patterns between the different reports and see if there are commonalities between them that seem related.

For example, Gaurav Rathi, engineering manager, can’t stress the importance of finding patterns enough when it comes to identifying the root cause of a bug.

Here’s what he has to say about the topic:

While trying to reproduce the bug, look for the possible patterns that are similar to a cousin of this bug. Who knows, you might be able to find a pattern which could help you to reproduce this bug!

He also shared an example of how observing patterns helped him find a bug.

Determined to fix a bug related to the database general error, he struggled for a long time.

Then after searching for other bugs that might have been reported by other testers in the bug database, he found a similar report from another tester.

When he went through it, he was able to see that the bug occurred when certain Unicode characters were present in the input.

This helped him determine that this was the reason his app broke.

In other words, once he identified the pattern, he was able to reproduce the bug easily.

That’s why finding patterns is an important part of the bug-reproducing process.

It can help developers get to the bottom of the problem when all the other options seem to be exhausted.

Make a note of each change

Finally, developers should document the actions they take while trying to reproduce a bug.

For instance, if developers change a line of code, they should note the exact lines that were changed and what they were changed to. The same goes for changing settings or features.

This way, they don’t have to keep track of these details in their head as they work through the problem.

Instead, they’re written down for easy reference for them and other developers who might have to consult their notes in the future.

This is exactly what Tim Broberg, a senior software developer, suggests in the Quora thread below.

He even goes on to say that developers should document everything as diligently as if they were collecting evidence for a case.

And he follows his own advice—not only does he record the changes that have been made and the questions that remain unanswered, but he also makes a note of the different approaches which could be useful if tried again in the future.

This way, he has a record of his thought process to refer back to in case there’s any confusion about how he reached his final conclusions.

Therefore, making notes while trying to reproduce steps is a good habit to get into as it can help developers avoid going down blind alleys and enable them to get back on track if they do.

How Shake makes reproducing the steps easier

Bugs often have very technical underpinnings and only appear in certain conditions.

Because of this, it can be difficult to reproduce them—even for expert developers.

Therefore, there is a great benefit to integrating tools like Shake into the process when attempting to reproduce bugs.

Shake is a bug and crash reporting tool whose name refers to its most prominent feature—the ability to report bugs by shaking the phone.

After that, the bug report is sent to developers, and they immediately gain access to more than 70 different metrics.

In fact, some of the metrics that are automatically attached include the following:

This gives developers access to information such as the OS version, steps to reproduce, screen resolution, battery status, device model, CPU usage, connectivity details, the timeline of console logs, as well as other relevant information that can help them reproduce the bug.

Additionally, a report contains screenshots and video recordings of the tester’s interactions with the app at the moment they encounter an issue.

As you can imagine, all this data can be very helpful in reproducing a bug.

Now developers can see, from the tester’s perspective, exactly what the bug looks like.

This enables them to easily reproduce the bug, pinpoint its root cause and fix it more quickly.

Conclusion

In this article, we discussed the importance of reproducing app bugs and showed you how through real-world examples.

As you may have noticed, there are a number of steps involved in reproducing an app bug.

While it may seem like a lot of work at first glance, by following these steps and using them as a guide for your own bug-reproducibility efforts, you and your team will be able to reproduce any bug that comes your way.