Exceptions happen whenever the software does something unexpected. By properly managing expectations, and ensuring the software meets those expectations we can deliver a better user experience. Meeting user expectations is the most important part of software development. In order to do meet expectations, we employ a robust process of Exception Management.
What is Exception Management?
As developers, we are constantly dealing with the unexpected. Our end goal is to develop software that behaves in the way the user expects. Exception Management is the process for handling differences between the actual and expected software results. Just because the result was unexpected, doesn’t necessarily mean that it was wrong. We must understand the differences between what happens and what the user expects, and then eliminate or mitigate them in order to deliver software that matches what the user expects as closely as possible.
This article will introduce the initial definitions used throughout Exception Management. There aren’t any industry established definitions, because many of the terms are used colloquially in many different ways. So it is important to first establish the vocabulary and definitions for what the words are meant to describe in this specific context.
What is an Exception?
An exception is any difference between what is expected to happen and what the software actually does. An exception can be caused by the software delivering the wrong results, or it could be from the user expecting the wrong thing. Ideally, exceptions are detected and resolved in the process of development and testing, but sometimes it is still possible that they end up in Production. When that happens, we want to have robust Exception Handling built into our software to mitigate, or prevent, failures for the user.
Three Types of Exceptions
Depending on when the exception is found in the development process, it could be one of three types. The development process is generally defined into a minimum of three phases; Development, Test, and Production. Exceptions are defined by which phase they are detected because that determines how close they are to impacting the user.
Error
An exception detected during the development phase, usually through the development software.
Defect
An exception detected during the test phase, usually through user interface testing.
Failure
An exception detected by the end user in production.
Developing Around Exceptions
Developers are usually notified of exceptions by errors, which are reported by the development software when running the application. An error is an exception reported by the software which communicates a variance between the expected results and the actual results. An error does not necessarily mean there is a problem. For instance, when performing a find, the application expects to find records. If no records are found, the development software throws an error 401 to notify the developer that there was a variance between what it expected and what actually happened. It could be that no records match the find request, in which case that is the user expected result, even though it is an error.
Exceptions During Testing
A robust testing process is required for finding and resolving exceptions before they enter production. When an exception is found during testing, it is considered a defect, and defects fall into three categories:
1) Wrong: The user tries to navigate home, but is taken to a report
2) Missing: The user tries to navigate home and nothing happens
3) Extra: The user tries to navigate home and is taken home and a report downloads.
Defects are reported to the development team so that they can be appropriately categorized and managed. The development team files the reported defect as a bug or a deviance or a bug. A bug means that the software did not produce the results it was intended to produce. A deviance means that the software produced the results it was intended to produce, but they were not the results the user expected. How the development team addresses the defect will depend on if it is a bug or a deviance.
Bug
A defect caused by a variance in the actual results from the software as designed.
Deviance
A defect caused by a variance in user expectations from the software as designed.
Example: A Test User may find that clicking the home button pops up a message to confirm they want to navigate home, when they expected just to be taken straight home. The Test User logs this as an Extra Defect and hands it to the development team.
The development team categorizes the defect. If the software was not supposed to pop up a message, this is a bug. A bug is addressed by fixing the underlying code that was causing the defect. If the software was supposed to pop up a message, this is a deviance. In this case the software requirements defined that the user must be warned before navigating away from any page. Even though it’s not what the user expected, it is what the development team was asked to deliver.
A deviance doesn’t mean there is anything wrong with the code, but it should be treated as an opportunity to improve the user experience. Anytime software doesn’t behave as the user expects, the user experience is negatively affected. A deviance may need to be addressed outside of the development team.
The project team can re-evaluate if the software requirement is still necessary, and eliminate or modify the requirement itself. The project team can create a new way to meet the requirement that is more in line with what the user expects. For example, popup a warning that is automatically dismissed in 2 seconds, thus meeting the requirement that the user is warned, while eliminating the extra click required from the user. Or the project team can update user training documentation to explain the reason the user must be warned and why they must confirm their choice, updating the user’s expectations.
Exceptions in Production
Ideally, defects are reported in testing and addressed before they become failures in the production application. There are some events that are outside the control of the software.
Fault
An underlying cause of a failure that can’t be controlled by software.
A fault can be based on environmental variables, such as an unsupported browser or plug in version. It can also be bad data entry from the user, such as not providing a required value. Whatever the fault is, Exception Management aims to prevent or mitigate them before they become failures that are detected by the user. Some, but not all, exceptions can be eliminated. For example, the fault causing the failure may be that the user’s browser is out of date and not supported. The development team can’t do anything about which browser is used. However, Exception Handling can mitigate the fault before it becomes a failure, warning and preventing a user from logging in with an unsupported browser.
