> For the complete documentation index, see [llms.txt](https://practical-testing.gitbook.io/home/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://practical-testing.gitbook.io/home/testing-practices/testing-failures-and-errors.md). # Testing Failures and Errors Testing involves intentionally triggering errors and seeing how the system behaves. But it's not enough to just state *"yes, the error pop-up appeared as expected, all is good"*. {% hint style="warning" %} Errors aren’t just about whether they occur, **but how they are surfaced, how meaningful they are to the user, and what happens next.** {% endhint %} ### A simple example Regardless of context, does this error dialog have problems? * *"The message is vague"*. This might be intentional. Revealing technical details to non-technical users is likely to be inappropriate, useless, and might even expose sensitive information. * *"OK, so what do I do now?"* - Missing information on how to recover. Do I navigate back? Can I close the window? * *"What happens when I click OK/Cancel?"* - given the message, there is no obvious difference between the two buttons. * *"Shouldn't OK be on the right?"* - bonus question. There is no right or wrong, as it is platform-dependent. On Windows, affirmative actions are on the left; on macOS, Linux, and Android, they are on the right. The web? It depends. See [UX StackExchange discussion](https://ux.stackexchange.com/questions/1072/ok-cancel-on-left-right). This example is contrived yet realistic, but it highlights that error events require thought, design, and testing. ### Structured Categories for Testing Errors & Failures Follow the CAROL-G mnemonic. It captures user-facing and backend aspects of error testing. Not all points apply to all situations. #### **C – Clarity** * Is the error message clear and understandable for the intended audience? * Does the error explain *why* it happened (without leaking sensitive info)? * *"Oops, something went wrong." → "Payment failed due to expired card."* * Is the technical detail level appropriate (end-user vs. admin vs. developer)? * Are error codes meaningful and consistent? *** #### **A – Actionability** * What can the user do after seeing the error? Are the options non-ambiguous? * “OK/Cancel” → “Try Payment With Another Card / Cancel Booking.” * Are recovery options clear (retry, cancel, contact support)? Does it guide the user on next steps or recovery options? * Are destructive actions (like “Delete anyway”) clearly warned? * Are users given the "Submit error report" option? If they do, does the submission work? *** #### **R – Recovery** * Can the user continue working without losing data? * If the app crashes, is there auto-save, rollback, or undo? * Does retry work under varying conditions (network restored, permissions fixed)? *** #### **O – On-Time** * Does the error appear promptly, without long freezes or hangs? * Are timeouts handled gracefully? * Are cascading failures prevented (e.g., one error doesn’t spawn multiple popups)? *** #### **L – Logging** * Is the error logged in the backend/system logs? * Does the log capture enough diagnostic detail for debugging, or will the developer struggle? * Is sensitive information (passwords, PII) excluded from logs? * Does the backend log contain a payment gateway error code, but not the full card number? *** #### **G – Gracefulness** * How gracefully does the system degrade under error conditions? * Does the UI remain usable (no frozen screens, unresponsive buttons)? * Is error styling consistent (colors, icons, modal placement)?