Use case testing in software testing

·          Use case testing is a technique that helps us identify test cases that exercise the whole system on a transaction by transaction basis from start to finish. They are described by Ivar Jacobson in his book Object-Oriented Software Engineering: A Use Case Driven Approach[Jacobson, 1992].

·          A use case is a description of a particular use of the system by an actor (a user of the system). Each use case describes the interactions the actor has with the system in order to achieve a specific task (or, at least, produce something of value to the user).

·          Actors are generally people but they may also be other systems.

·          Use cases are a sequence of steps that describe the interactions between the actor and the system. Use cases are defined in terms of the actor, not the system, describing what the actor does and what the actor sees rather than what inputs the system expects and what the system’s outputs.

·          They often use the language and terms of the business rather than technical terms, especially when the actor is a business user.

·          They serve as the foundation for developing test cases mostly at the system and acceptance testing levels.

·          Use cases can uncover integration defects, that is, defects caused by the incorrect interaction between different components. Used in this way, the actor may be something that the system interfaces to such as a communication link or sub-system.

·          Use cases describe the process flows through a system based on its most likely use. This makes the test cases derived from use cases particularly good for finding defects in the real-world use of the system (i.e. the defects that the users are most likely to come across when first using the system).

·          Each use case usually has a mainstream (or most likely) scenario and sometimes additional alternative branches (covering, for example, special cases or exceptional conditions).

·          Each use case must specify any preconditions that need to be met for the use case to work.

·          Use cases must also specify post conditions that are observable results and a description of the final state of the system after the use case has been executed successfully.

·          The ATM PIN example is shown below in Figure 4.3. We show successful and unsuccessful scenarios. In this diagram we can see the interactions between the A (actor – in this case it is a human being) and S (system). From step 1 to step 5 that is success scenario it shows that the card and pin both got validated and allows Actor to access the account. But in extensions there can be three other cases that are 2a, 4a, 4b which is shown in the diagram below.

·          For use case testing, we would have a test of the success scenario and one testing for each extension. In this example, we may give extension 4b a higher priority than 4a from a security point of view.

·          System requirements can also be specified as a set of use cases. This approach can make it easier to involve the users in the requirements gathering and definition process.