bug_report Crash Bugs 10 min
bug_report
Simulation ยท Technical Support

We hope our users never experience a crash.

But when customers report crashes to us, it's important that we understand the best procedures for what to do next.

The product team is committed to making the software the highest quality product on the market. In technical support, we make the product better by notifying the developers when something needs addressing. In this simulation, you'll focus on when to notify the product team of reproducible crashes by logging crash bugs.

schedule 10 minutes
cases 4 cases to own
school Technical Support
Learn more about crashes and crash bugs
Crashes happen when the software is unable to gracefully catch an error, and instead stops working and closes unexpectedly.
If you've ever personally experienced a crash in any software, you probably don't need anyone to explain this to you. When software crashes, users risk losing unsaved work, orphaning edits in an enterprise geodatabase, losing their license, and more.

If an error occurs in the software, we expect that the software will catch that error and display a message to the user explaining why something cannot work properly. Crashing is an unhelpful response to an error.
Any crash that can be reproduced should be logged as a crash bug. Any time you have a workflow where a series of repeatable steps produces a crash, log a crash bug.

To make sure the steps are repeatable, apply the problem-solving framework:
Understand โ†’ Interrogate โ†’ Explain
Non-reproducible crashes should not be logged as bugs. When you log a bug, you are logging steps that a developer can use to reproduce, examine, and resolve the problem. If they can't reproduce it, they can't resolve it.

Crashes due to unmet minimum system requirements should also not be logged as crash bugs.
Ready to put this to the test?
Next, you'll own four simulated support cases and decide whether to log a crash bug for each unique situation.