Changes between Version 8 and Version 9 of BluePrint/DestructiveTesting

Timestamp:

01/10/12 10:46:03 (13 years ago)

Author:

Dominic König

Comment:

--

BluePrint/DestructiveTesting

@@ -16 +16 @@
 
 It is important that the test targets "regular user tasks", i.e. the intention of the user must be part of the expected workflow, just actioned the wrong way, and also that the user's mistake has an actual (not ''potential'') consequence on the data integrity or workflow. That means, if the user puts in values in wrong syntax, and the system is able to still save the right values in the record, then that is ''not'' an inconsistency but tolerant behavior. If though the user puts in values in wrong syntax and the system saves a wrong value, then that's a bug. And of course, no user action should ever lead to a HTTP 500 "Internal Server Error" (whereas other error messages may be a proper response to the user's mistake).
+
+Ideally, any error messages should:
+
+  - name the action that lead to the error
+  - explain the cause of the error
+  - explain the consequences of the error for the user action
+  - explicitly state the impact on data integrity (e.g. "Record could not be deleted")
+  - where suitable, suggest what the user could do to
+    a) mitigate the impact of the error (e.g. "Please contact the system administrator to ...")
+    b) continue with the task the user was going to perform
 
 This BluePrint shall document the procedures for a systematic destructive testing of a particular Eden module, with focus on "systematic", so that the testing covers as many possible user mistakes as possible, and in a way that the test cases can be easily reproduced for any Eden modules.