Question

Write a short 1-2 page paper describing the following:

a. What is meant by Use Case Testing? Why is it useful and important? What other options exist other than doing Use Case Testing? Please include citations for any papers, books, or websites used.

Answer 1

Answer:

What is meant by Use Case Testing? Why is it useful and important?

Use Case Testing is a functional black box testing technique that helps testers to identify test scenarios that exercise the whole system on each transaction basis from start to finish.

Characteristics of Use Case Testing:

• Use Cases capture the interactions between 'actors' and the 'system'.

• 'Actors' represents user and their interactions that each user takes part into.

• Test cases based on use cases and are referred as scenarios.

• Capability to identify gaps in the system which would not be found by testing individual components in isolation.

• Very effective in defining the scope of acceptance tests.

How to do Use Case Testing: Example

In a use-case, an actor is represented by "A" and system by "S". We create Use for a login functionality of a Web Application as shown below

Main Success Scenario	Step	Description
A:Actor S:System	1	A: Enter Agent Name & Password
	2	S: Validate Password
	3	S: Allow Account Access
Extensions	2a	Password not valid S: Display Message and ask for re-try 4 times
	2b	Password not valid 4 times S: Close Application

• Consider the first step of an end to end scenario for a login functionality for our web application where the Actor enters email and password.
• In the next step, the system will validate the password
• Next, if the password is correct, the access will be granted
• There can be an extension of this use case. In case password is not valid system will display a message and ask for re-try four times
• If Password, not valid four times system will ban the IP address.
• 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.
• 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.

What other options exist other than doing Use Case Testing?

• Result negative: An Exception is anything that leads to NOT achieving the use case’s goal.
• Result positive: An Alternate Flow is a step or a sequence of steps that achieves the use case’s goal following different steps than described in the main success scenario. But the goal is achieved finally.

Cancel is no Alternative! It’s an Exception

Anything that leads to NOT achieving the use case’s goal is an Exception.

Very often the user is requested to confirm a step like data entry or delete something. In that situation there is always the possibility that the user does not confirm but cancel the use case. So what happens? The system works perfectly right handling the cancellation. Nevertheless this is a typical Exception because it leads to not achieving the use case’s goal.

In the example below the user confirms the deletion in step 5. But there are two other options the user may select: He aborts the the deletion or he prolongs the deletion. Because both possibilities refer to step 5 they are numbered as 5a and 5b within the section Exceptions. Again, both exceptions are not caused by system errors or malfunction. But both exceptions lead to not achieving the use case’s goal, which is the deletion of the contract. In the first case the user will not delete the contract. In the letter case the contract is also not deleted but additionally put into the job queue for later assessment.

Alternatives lead to success

We consider any steps deviating from the main success scenario, which finally lead to a success of the use case as Alternative Steps.

There are many roads to Rome. The main success scenario describes the most likely way a user may take to achieve the business goal. Nevertheless, there may be other ways to perform a particular step or a sequence of steps. Those different paths are called Alternate Flows or Alternatives.

Below an example show how to delete a contract. From the pure business perspective this is most likely not the way we do that. But take it just as an example. In the first step the user’s navigates to the customer who’s contract to be deleted. Next he selects the particular contract (step 2). Instead of locating the customer the user may filter the huge list of contracts alternatively. As this is an alternative to step 1 of the success scenario it is numbered as 1a within the alternate flows. As it is nothing stated explicitly in the alternate step the use case will continue with step 2 of the main scenario. The user selects the contract and initiates the deletion.