Many of my fellow colleagues on this here blog have already commented on the value of the Business Data Diagram or BDD.  Those of you familiar with ERDsor Entity Relationship Diagrams should recognize the BDD.  The key difference between the ERD and the BDD is that BDDs are not intended to represent either the logical or physical relationships in a database.   They are a higher level of abstraction than the ERD and describe relationships between business entities.  Since my fellow bloggers have already covered to some how to elicit, create, and use BDDs, I won’t spend too much time going over the details of the BDD.  I’d like to talk more about a little-known use for BDDs: Creating UAT test scenarios.

Here is an example of a simple BDD:

Looking at this BDD, I should immediately be able to derive “Create”, “Edit”, “Delete”, “View”, and “Associate” test scenarios around each of the entities.  There should already be Use Cases which cover each of these scenarios anyway, but in case you didn’t create them, now is a good time (better late than never!).   Based on the above BDD, I would derive the following scenarios:

• Create/Edit/View/Delete Account
• Associate Customer with Account
• Associate Many Customers with a Single Account
• Create/Edit/View/Delete Order
• Associate Order with Invoice

and so on…

After building out this initial list, you can scrub it by determining which of these scenarios are handled by an offline tool, IT support structure, or through a manual process.  Some of your scenarios will just be illogical upon initial review, and you can eliminate them right away.  For example, “associate products with invoice” probably isn’t a very good UAT scenario, and would probably happen via either the “Create Order” or “Associate Order with Invoice” scenario.   The key is to focus on the scenarios  which describe a process implemented by the system you are building.

Next, fill in another level of detail around the scenarios you derived.  In this step, focus on answering the “Whos”, “Whichs”, “Whens”, and “Whats”.  Example:

• Create/Edit/View/Delete Account:  Who can do each (which users–look at your org chart!)?,  which accounts? Is there security around each?
• Associate Customer with Account:  Who associates this?  Does it happen automatically?  Which customers can be associated to an account?
• Associate Many Customers with a Single Account:  A variation on the above, but would probably be performed as an admin function for merging accounts.
• Create/Edit/View/Delete Order:  Who can perform each of these?  Which orders can they edit?  When can they edit them? When can they deleted?

After filling out this level of detail, the next step is to figure out the “Hows” of each scenario.   The level of detail to which you describe the “how” depends on how familiar you and your testers are with the system being tested, as well as how much time you have to develop the test scenarios.   In some cases, a few sentences describing what to do in the system is sufficient.  However, in other case, you may need to create more extensive, step-by-step scenarios which describe in detail how to execute the test.

Almost all the other scenarios that you might develop after this point are just different permutations and combinations of different types of data, roles, and security.   For example, you may need execute tests with whether customers in a particular region can order products that do not belong to that region.  Which permutations and combinations are relevant to test will need to be determined through good old-fashioned analysis (GOFA).

It’s important to note that this method is by no means a way to derive a comprehensive list of all UAT test scenarios.  There is no substitute for GOFA and elicitation from your business testers.  However, this will provide you with a starting point from which to derive further scenarios based on combinations and permutations of the different data associated with your scenarios.  Returning to the BDD to derive these scenarios also helps you review the BDD to determine whether it is valid or requires updates.

Now if I could only get someone else to write those UAT scenarios for me…