Changes between Initial Version and Version 1 of BluePrint/DestructiveTesting


Ignore:
Timestamp:
01/10/12 09:47:00 (13 years ago)
Author:
Dominic König
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • BluePrint/DestructiveTesting

    v1 v1  
     1[[TOC]]
     2= !BluePrint: Destructive Testing of Sahana Eden Modules =
     3
     4== Introduction ==
     5
     6Destructive testing means to test the response of the system to user errors for consistency. When the user performs invalid actions, the system should:
     7
     8  - respond with a proper error message
     9  - prevent any unintended data loss
     10  - give information how the user can do it right (if the user's intention is clear)
     11  - if necessary, allow the user to return to the previous state
     12
     13The primary goal of the test is to find situations where the user can accidentally loose data or expose them for unauthorized access, or put the system into a state where it is impossible to resume the normal workflow. It is *not* the primary goal of the test to find bugs (=wrong response to right user action) but to confirm a proper error handling (=right response to wrong user action)
     14
     15The test method is to intentionally perform everything that the user could do wrong, misunderstand or forget when performing a regular user task (e.g. input of invalid values or no values where values are required, clicking on UI elements that are not meant to be clicked on, or unintended navigation actions like clicking the "back" button, bookmarking invalid URLs, and so forth) and document the systems response to the error.
     16
     17It 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. 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".
     18
     19This 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.
     20
     21From this BluePrint, we want to be able to implement a standard testing procedure for Eden releases.
     22
     23== Typical User Mistakes and their Priorities ==
     24
     25This section shall document any knowledge about typical user actions and mistakes, and their relative likelihood (=priority).
     26
     27== General Testing Method ==
     28
     29== Examples of Test Cases ==
     30
     31== References ==
     32
     33----
     34BluePrints