I like IDMTDT testing, it can be a rich source of errors and can show up data integrity faults and usability problems that you might not otherwise find.  The big advantage is that you can then see how the system handles CRUD activities in unusual combinations.

Oh, sorry, IDMTDT stands for “I didn’t mean to do that” and is a set of tests that try to recover from when the user has done something stupid and wants to undo somewhere down the line in the Business process. 

A simple example:

User creates a new record for a new customer

User enters name/address/Post code

User then creates new accounts record for new customer

User puts credit limit on new customer account

User enters sales representatives name

User activates new customer.

At this point, User finds that the Post code is mistyped.  How do you recover?  If the system allows an edit of the customer field, then it is easy, but lets say, for the sake of the example, that there is no edit function for the Post code, it maybe a primary key in the database that is uneditable.  Let us also assume that deletion of customer records is not allowed as the system requirement is to keep all records for audit purposes and the design assumes that the user does not make this type of mistake. 

The recovery from this type of problem in a real world situation can be a nightmare (I have seen this type of scenario in a number of systems).  The testing can, however, be quite fun as you have a number of points at which you can try to recover the situation; after the new record created, after the account set up, after the sales rep entered, after activation.  Each of these scenarios will have a different set of tests and may involve exercising different functionality.

Planning and scripting such testing tends to be difficult as it is often the type of scenario not covered well in requirements or business scenarios (because people don’t make mistakes, do they?), so the best technique I have found is to include it in Exploratory tests.

It is a type of testing that can be forgotten or is done haphazardly.  It also, as a general guideline, should be done once the software is relatively stable as you are not trying to find functionality bugs, but business flow bugs.