When correcting either defect, it is typical to update the system to handle the unexpected user input. This is where most people stop. Since systems are built using patterns and models, a defect in one part of the system has likely been introduced elsewhere. Generally, solutions to reported failures miss opportunities to identify and resolve the underlying class of defects.
When faced with a failure report from the field (or internal QA), go deeper. While more an art than a science, there are several questions to ask that may reveal additional latent defects:
- Where else is this programming model used? (E.g., the pattern is used in all our repositories)
- How can the specific user input be generalized? (E.g., a screen blows up because one piece of information was made inactive by the system administrator, but other types of information can also be made elsewhere)
- Where else can these type data be entered? (E.g., Dates prior to today can be entered in many places)
Cultivate this perspective by starting with these questions and extending them to your environment. Encourage people on your team to generalize every failure reported. The goal is to get past the specific instance of the failure and to consider the class to which the failure belongs. You may elect to only repair this instance due to time or money. At least you will be doing so consciously. Alternatively, you may find that you identify and avoid serious field failures.
You may elect to only repair this instance due to time or money. At least you will do so consciously. Alternatively, you may find that you identify and avoid serious field failures.
