I define Error in two related ways. First, I call a human action that produces an incorrect result an error. Second, I call a discrepancy between an observed behavior or result and the specified behavior or result a fault. Both meanings occur in practice. Therefore, I clarify the meaning when needed. For example, I use human error for the first meaning. In addition, I use observed discrepancy or observed fault for the second meaning.
I explain each meaning briefly. First, human error covers slips, mistakes, and wrong decisions by people. For example, I enter the wrong value in a form. As a result, the system produces a wrong calculation. Second, observed error covers differences between what the system does and what the requirements specify. For example, I expect a login to accept a valid password. However, the system rejects it. That discrepancy constitutes an observed fault.
I emphasize the relationship between errors and requirements. Errors often trace back to unclear or conflicting requirements. For example, I may receive two requirements that conflict on color or behavior. Consequently, developers may implement one interpretation and produce an observed error against the other. Therefore, I resolve requirement conflicts early. In addition, I document decisions to avoid future human errors and observed errors.
I link errors to evaluation and prioritization. I assign higher severity when they affect high-priority requirements. For example, I treat an error in a critical security function as more severe than a cosmetic issue in a rarely used feature. Moreover, I use evaluation criteria such as importance, cost, frequency of use, and criticality to decide how urgently to fix errors. Thus, I align error handling with project goals.
I describe practical steps I follow to manage errors. First, I detect errors through reviews, inspections, and testing. Next, I report errors with clear descriptions, steps to reproduce, and links to the related requirement. Then, I analyze the root cause to decide whether the issue stems from human error, a faulty requirement, or an implementation defect. After that, I plan the fix using change management. Finally, I verify the fix and close the error when tests confirm the expected behavior.
I track error-related metrics to improve quality. For example, I measure the number of errors found in inspections, test coverage, error density in code, and the number of remaining serious errors. Furthermore, I track the proportion of requirements with incomplete attributes. These figures help me forecast project status and quality. Therefore, I use them in progress reports and prioritization meetings.
I recommend clear terminology. First, I call the human action a human error. Second, I call the mismatch between observed and specified behavior an observed fault. Also, I avoid the ambiguous term discrepancy when precision matters. Instead, I name the specific cause or symptom. This choice improves communication. As a result, stakeholders agree faster. Consequently, I reduce rework and lower risk.