In this simulation, you will identify when it is and is not appropriate to log a crash bug for the software. Time commitment: 10 minutes [[Start|intro]] //Questions or issues with this simulation? Email the training leads.// We hope that our users never experience a crash! But when customers do report crashes to us, it's important that we understand the best procedures for what to do with that information. 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 product team when something needs addressing. In this simulation we're going to focus on notifying the product team of reproducible crashes through logging crash bugs. [[Learn more about crashes and crash bugs.|info]] (set:$scenario1=0) (set:$scenario2=0) (set:$scenario3=0) (set:$scenario4=0)Click the links to reveal more information. **What is a crash?**(click:"What is a crash?")[ Crashes happen when the software is unable to gracefully catch an error, and it instead stops working and closes unexpectedly.] **Why are crashes bad?**(click:"Why are crashes bad?")[ 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.] **When is it appropriate to log a crash bug for a crash?**(click:"When is it appropriate to log a crash bug for a crash?")[ 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 obtain repeatable steps, apply the problem-solving framework: Understand-Interrogate-Explain] **When is it //inappropriate// to log a crash bug?**(click:"When is it inappropriate to log a crash bug?")[ Non-reproducible crashes should not be logged as bugs. As with every bug, you are logging the steps that another person from the development team can use to reproduce, examine, and resolve the problem. If they are unable to reproduce the error, they will not be able to resolve the error. Crashes that occur due to a system not meeting the minimum requirements should also not be logged as crash bugs.] Ready to apply this knowledge? Click the links below to own a case. (if: $scenario1 is 0)[[[Own crash case #1: These tools keep crashing!|scenario1]]] (if: $scenario2 is 0)[[[Own crash case #2: The software won't start|scenario2]]] (if: $scenario3 is 0)[[[Own crash case #3: The software crashed last night|scenario3]]] (if: $scenario4 is 0)[[[Own crash case #4: This tool used to work|scenario4]]] Incoming email: //Hi tech support, I'm trying to run the raster analysis tools for deep learning, the ones that run on my web server. Every time I try to run them with any inputs, the software crashes. Please advise. Thank you, Burt G, GISP// You will begin by applying the problem-solving framework by first seeking to understand the problem. Easiest way to do this is to give Burt a call. [[Call Burt]] (set:$scenario1ans=1)Incoming call: You: //Hi Maria, looks like the software isn't starting for you, is that correct?// Maria: //Yes that's correct. I'm brand new to working with this software, and I can't even get it to start! It crashes as soon as I open it.// You: //Let's figure out what's going on and get you started with your workflows. Can we get on a screenshare so I can see what you are seeing?// You get on a screenshare and begin to understand the issue. You verified that the software is crashing upon startup, and you get more information about Maria's system. She's using the latest version, but is using an older operating system. On the call, you do verify with the documentation that her operating system is supported for her version of the software. Typically when you see problems like this, you try to reproduce the issue in-house, and you have a colleague who is using the same operating system Maria is using. Should you try to reproduce on that machine? [[Try to reproduce|scenario2repro]] | [[Don't try to reproduce|scenario2norepro]] (set:$scenario2r=0)Incoming call: You: //Hi Deshawn, I can see from these notes that the software crashed on you last night, is that right? Can you tell me more about what happened?// Deshawn: //Yes that's right. I was in the middle of working with my data when the software froze up. I don't remember exactly what I was doing but when it started freezing I just started clicking around to see if anything would respond. Nothing did and then it crashed. It asked me to send in a report and I did but I'm not sure if anyone reads those so I figured I'd call this morning.// You: //I'm glad to hear you submitted the error report when it happened. We do have a team of people that review those crash reports. If you include your contact information, we can even notify you when we have a high-confidence fix for a crash. Or, if we need more information from you on what was happening when the crash happened, we can reach out to you too.// Curious about these programs?(click:"Curious about these programs?")[ Link to documentation on error reports Link to more info on submitting crash reports] [[Continue working with Deshawn|scenario3continue]]Incoming email: //Hi Support, I upgraded my version of the software yesterday, and now I can't use this tool on my data without the software crashing. Is this a bug? Nadine// It could be! By applying the problem-solving framework, you'll be able to determine if this is truly a bug. To start understanding the problem, you decide to give Nadine a call. [[Call Nadine|callnadine]] Excellent work identifying when it is an is not appropriate to log a crash bug! Remember to check first that the system meets the minimum requirements, then log a crash bug for any reproducible crash. And don't forget to continue trying to be helpful even when a crash isn't reproducible. Now you're a Crash Bug Hero! [[Return to the beginning|Start]] //Questions or issues with this simulation? Email the training leads.//You've got Burt on the phone now, and you've asked him to show you the crash. Just as Burt described, the tool crashes regardless of input. You ask Burt if there's anyone else in his office that's tried to use these tools to get an idea of if this problem is unique to him, but he's the only one who has tried. Burt also mentioned that he's used these tools before for his Deep Learning workflows, but the ones that run on the local desktop machine not the tools he's currently showing you. You get more information about his goals and his system, and you begin speculating that this could be a crash bug. You ask him if you can give him a call back after you run a few tests while he continues with his day, and he obliges. [[Test the tools on your system|scenario1test]] You found a sample dataset to use and you test the tool Burt showed you. Sure enough, it crashes. You also test the other tools that Burt mentioned worked for him, and those work for you, too. You and Burt both have the latest version of the software installed. Do you log a crash bug? [[Yes|scenario1yes]] | [[No|scenario1no]](if:$scenario1ans is 1)[Correct! This is an appropriate time to log a crash bug. You determined that the crash is consistently reproducible, even with a different dataset than Burt was using. At this point, you have enough justification to proceed with logging a crash bug. ]With the bug now logged, it's time to call Burt back to let him know the status of his case. [[Call Burt|scenario1close]](set:$scenario1ans=0)At this point, you have reproducible steps that consistently produce a crash. The product team will be able to take this workflow, reproduce it, and examine a possible resolution from here. Remember that the software shouldn't crash as a response to an error. If there is an error, it should be handled gracefully and not unexpectedly close. You should proceed with logging a crash bug. [[Log a crash bug|scenario1yes]](set: $scenario1=1)You called Burt back and let him know about the bug. He's understandably disappointed, but happy that you took his issue seriously and reported it. You share the usual information about how he can track the status of the bug and what he can do now. You ask if he needs anything else, he doesn't, and asks that you close his case. (if: $scenario1+$scenario2+$scenario3+$scenario4 is 4)[Congratulations! You have owned and closed all four cases! (link: "Click here to finish this simulation.")[(goto: "reflect")]] (else:)[Nice work! [[Try owning another case|info]]]You could try to reproduce, but it's likely not the best use of time. You know that the operating system is supported, which means that it was tested thoroughly by theproduct team and has been proven to work with the software. It's not likely the operating system causing the issue. (set$scenario2r=1) A more useful test would be to check if Maria's system as a whole meets the minimum system requirements. The best way to do this is by having Maria run the Can You Run It tool on her machine. [[Use Can You Run It|scenario2norepro]](if $scenario2 is 0)[The operating system is supported, so trying to reproduce the issue in-house will likely result in the software opening normally. In this case, trying to reproduce will not be the most effective use of time. A more useful test would be to check if Maria's system as a whole meets the minimum system requirements. The best way to do this is by having Maria run the Can You Run It tool on her machine. ] You ask Maria to run the Can You Run It tool on her machine, and see that the machine doesn't pass. It doesn't have the minimum .NET version required to run the latest version of the software. Maria is glad that she has a concrete answer and is happy to share this with her IT department in a ticket in their system. Great! But do you log a crash bug? The crash was reproducible for Maria every time she tried to open the software. Do you log a crash bug? [[Yes|scenario2yes]] | [[No|scenario2no]]Even though the crash was reproducible, the system was not ready for installation. Making sure the system meets minimum requirements is mandatory prior to installing the software, so logging a crash bug for this case is not appropriate. [[Continue without logging a crash bug|scenario2close]]Correct, since the system didn't meet the minimum requirements, this is not an appropriate time to log a crash bug. [[Continue without logging a crash bug|scenario2close]](set: $scenario2=1)You agree with Maria that you will keep her case on hold while she waits for her IT department to upgrade her version of .NET. After 2 days, she emails you back letting you know that the software is now working great for her and requests you close the case. (if: $scenario1+$scenario2+$scenario3+$scenario4 is 4)[Congratulations! You have owned and closed all four cases! (link: "Click here to finish this simulation.")[(goto: "reflect")]] (else:)[Excellent! [[Try owning another case|info]]]As of right now, you have no concrete reproducible steps to share with a developer to investigate this issue. This is not an appropriate time to log a crash bug. However, you can still assure Deshawn that the crash is something worth monitoring. If he ever is able to reproduce the crash, we want to know about it. You can continue to be helpful even though the issue is no longer present. [[Propose a plan to Deshawn|scenario3close]]That's correct, since we do not yet have a reproducible crash, we don't have enough information to log a crash bug. However, you can still assure Deshawn that the crash is something worth monitoring. If he ever is able to reproduce the crash, we want to know about it. You can continue to be helpful even though the issue is no longer present. [[Propose a plan to Deshawn|scenario3close]]You let Deshawn know that the crash is still important to us and that you want to make sure it doesn't come up again tonight or at another time. Deshawn agrees to keep the case on hold for a few days while he continues his work, and you will check in again with him in a few days. If at any point the crash resurfaces, he will inform you. You wait a few days and have no response back from Deshawn, so you decide to give him a call to check up. [[Call Deshawn|scenario3close2]](set: $scenario3=1)Deshawn: //Thanks for checking in, but I have no news for you. The software never crashed again, which is great! But I do still worry it'll happen again.// You: //I'm also glad to hear things are okay now. But don't worry, if you do experience the crash again, send the error report with your contact info again and then contact me back under this case number. We can continue where we left off.// Deshawn is satisfied and agrees to close the case. (if: $scenario1+$scenario2+$scenario3+$scenario4 is 4)[Congratulations! You have owned and closed all four cases! (link: "Click here to finish this simulation.")[(goto: "reflect")]] (else:)[Nice job! [[Try owning another case|info]]]You continue chatting with Deshawn about what happened during last night's crash and try to help him reproduce it, but everything is working perfectly this morning. You get a copy of his crash report file and run it through the analyzer, but nothing jumps out at you as an obvious cause. Maybe this was a one time fluke, but Deshawn still did experience a crash last night. Do you log a crash bug? [[Log a crash bug|scenario3yes]] | [[Don't log a crash bug|scenario3no]] You: //Hi Nadine, I'm with technical support. I just owned your case, and I want to get some more information about what you're seeing. Are you available to chat now?// Nadine: //Yes thank you for calling! Here's how I get the crash, it happens every time I...// Nadine shows you her workflow. She's working with a table that's participating in a complex data model and trying to use the tool to add new records. Immediately you are suspicious, because you know that that complex data model is not editable in the software. However, Nadine also shares that before the upgrade, this tool worked just fine. Nadine has to run to another meeting, so you agree that you'll do some additional research for her while she's busy and you'll get back to her when you have an update. [[Continue researching|scenario4test]] You found a sample data model to test with, and begin to replicate the behavior Nadine showed you. Your test also crashes. You have a set of reproducible steps that produce a crash, but is this a supported workflow? This data model should be read-only in the software. Should you log a crash bug? [[Log a crash bug|scenario4yes]] | [[Don't log a crash bug|scenario4no]]Wise choice. Regardless of if the workflow is supported or not, the software should not crash. If the workflow is unsupported, the software should catch the error and display a message, not unexpectedly quit. If the workflow indeed is supported, then it is absolutely appropriate to log a crash bug to notify the developers of the issue. Either way, a crash bug is appropriate in this scenario. You log the bug and send an email to Nadine asking for her availability to chat on the phone about her case. She immediately calls you back. [[Answer Nadine's call|scenario4close]] Regardless of if the workflow is supported or not, the software should not crash. If the workflow is unsupported, the software should catch the error and display a message, not unexpectedly quit. If the workflow indeed is supported, then it is absolutely appropriate to log a crash bug to notify the developers of the issue. Either way, a crash bug is appropriate in this scenario. [[Log a crash bug|scenario4log]] You: //Hi Nadine! Thanks for calling me back so soon. I reproduced the crash with a sample dataset of my own and confirmed that this is a bug. From here...// You share the usual information about how she can track the status of the bug and what she can do now. Nadine is grateful for your work and shares that in her meeting she spoke with a colleague who is working on migrating to using a more modern data model with the software. You agree with her that that is a better long-term solution for her. You ask if she needs anything else, she doesn't, and asks that you close her case. You close her case, she gives you a glowing survey, but then [[a few days later...|scenario4close2]]You log the bug and send an email to Nadine asking for her availability to chat on the phone about her case. She immediately calls you back. [[Answer Nadine's call|scenario4close]] (set: $scenario4=1)You get a notification that the crash bug you just logged has ben resolved in the latest patch! You email Nadine back to let her know, and she replies: //Hello, Thank you so much for notifying me! I just downloaded the latest patch and it works! I did not think the developers could resolve the bug so fast! // (if: $scenario1+$scenario2+$scenario3+$scenario4 is 4)[Congratulations! You have owned and closed all four cases! (link: "Click here to finish this simulation.")[(goto: "reflect")]] (else:)[You knocked this one out of the park! [[Now, try owning another case|info]]]