As an ongoing story, here is something about a test design technique. This post is because I’ve been working at my client in educating some testers in the art of testing. One of the things they needed are Test Design Techniques (TDT). I started with a simple one, for them. And one we needed regarding to the test basis. This is the Use Case Test (UCT) and I will explain it in this posting.

What is a Use Case?

With a UCT you test a use case. Further down I’ll explain this. But first I have to explain what a use case is.

If you look a Wikipedia and TMap you get this definition.

“A use case is a description of a system’s behaviour as it responds to a request that originates from outside of that system (the user).”

In other words a use case describes “who” can do “what” with the system in question. The use case technique is used to capture a system’s behavioural requirements by detailing scenario-driven threads through the functional requirements. The use cases describe the system from the user’s point of view! A use case is a standard set by, among other, UML 2.0. It is a non-technical description of the behaviour of the system.

For testing use cases consists of 3 types of input, namely the Use Case Diagram, the Uses Case Description and the Activity Diagram. The explanations of Use Case Diagram and Activity Diagram can be found on the Internet, better than I can, and therefore shall not be explained. An example of an Use Case Description is shown here.

How to create a Use Case Test (UCT)?

First you have to know is when you can use the test design technique UCT. There should be a few (sort of) rules set. At first the quality characteristics (ISO 9126 or TMap) of the test object should be functionality, suitability, user-friendliness or usability, or a mix of these. This is because the UCT covers these quality characteristics. When other quality characteristics need te be covered the UCT is not useful.

When the quality characteristics are known the test basis should comply with the UCT. These are the 3 types of input mentioned earlier, namely the Use Case Diagram, the Uses Case Description and the Activity Diagram. And also like with the quality characteristics, when the test basis is not one of these three the UCT is not useful.

From here there are 5 steps that need to be taken:

1. Identifying test situation;

2. Creating logical test cases;

3. Creating physical test cases;

4. Establishing the starting point, and

5. Create test script.

Test situations

Test situations should be derived from the scenarios in the use case. The build-up of these scenarios can be found in the test basis and normally consist of a main scenario, an alternative scenario and the exceptions. This is the build-up of the test situations per scenario.

Another option is to build-up the test situations by using the needed data. With the needed data in the test situations the situations from the scenarios can be aggravated, not only with data from the database, but also with parameters.

When the situations are defined the needed coverage types should be chosen. The possible coverage types are a checklist or paths/decision points. These should also be derived from the different scenarios.

Logical test cases

The logical test cases consist of the combining of the test situations derived from the scenarios and data. These should be combined into 1 test case per scenario and 1 piece of data. Therefore more than one logical test case will be specified with multiple scenarios and data.

The description of the test cases can be in two ways, a check off list of written out test situation and choices.

Physical test cases

After the logical test cases the physical test cases can be derived. A physical test case is a full use case scenario from beginning to end. Physical test cases are structured in such a way that no test scripts are needed, they can function as the test script, like this one.

Because physical test cases have an integrated starting point stated in the ‘Initial situation’ and are structured the next two steps of ‘Establishing the starting point’ and ‘Create test script’ don’t need te be explained further. They are already created with the physical test case.

1. Software Testing Services Says:
   July 30th, 2010 at 19:52

   Nice post. The information that you have provided above about the test case design is very useful and presented in a very simple manner. After reading it once I do got the points cleared in my mind. Thanks for sharing it.

2. Jethro123 Says:
   May 12th, 2011 at 15:15

   Nice post. Can you recommend a software package for converting a test script into an activity diagram. Thanks.
   Bespoke Software Solutions

3. Trackbacks Says:
   February 5th, 2012 at 20:34
   • iPhone MRI Scanner