Use Case Scenarios as Test Cases

What is Software Testing?

Software testing is the act of checking the artifacts and behavior of the software under test through validation and verification. Software testing also provides an objective, independent view of the software, enabling companies to appreciate and understand the risks of software implementation.

Software testing can provide users or sponsors with objective, independent information about software quality and the risk of software failure. One of the main purposes of testing is to detect software faults in order to find and correct defects. Testing cannot determine that a product will work properly under all conditions, only that it will not work properly under specific conditions.

Use Case Testing

Use case testing is a functional black box testing technique that helps testers define test scenarios and exercise the entire system from start to finish on a transaction-by-transaction basis as described by Ivar Jacobson in his book “Object-Oriented Software Engineering” By using this technique, the testing team creates a test scenario that can exercise the entire software from start to finish based on the functionality of each feature. Use case testing is an interaction between the user and the software application and, therefore, helps to test the system from the user’s point of view. Here are some of the advantages.

What is a Use Case?

• A  use case is written using narrative language, describing the functional requirements of a system from the end user’s perspective.
• A use case diagram is created using a unified modeling language, with each step represented by its name in an oval;
• An actor represented by a stick figure with their name written below; each action indicated by a link between the actor and a use case;
• A  system boundaries indicated by a rectangle around the use case.

Elements of a use case

Depending on the depth and complexity you want or need, a use case describes a combination of the following elements.

• Actor – anyone or anything that performs a behavior (who is using the system)
• Primary Actor – Stakeholders who initiate interaction with the system to achieve a goal
• Secondary Actor is one from which the system requires assistance to complete the use case.
• Preconditions – must be real or occur before and after the use case is run
• Trigger – This is the event that causes the use case to be initiated

Use Case Scenarios ad Alternative paths

Use case modeling is a formal way of representing how a business system interacts with its environment, and it illustrates the activities performed by the users of the system. It is also a scenario-based technique in UML. A use case is a set of steps required to accomplish a specific task or goal. Typically, a use case can have multiple paths; each path is considered to be a use case scenario. Simply put, a use case is a goal with various processes, and a use case scenario represents a linear and direct path through one of these operations.

A scenario is a scene that illustrates some interaction with a proposed system. A scenario is a tool used during requirements analysis to describe a specific use of a proposed system. Scenarios capture the system, as viewed from the outside, e.g., by a user, using specific examples. A use case may contain several “paths” that a user can take while interacting with the system; each path is referred to as a scenario

• Primary Success Scenario [Basic Flow] – There are no errors in the use case.
• Alternative Paths [Alternative Flow] – These paths are variations on the main theme. These are exceptions that occur when something goes wrong at the system level.

Use Case Testing Example

A use case scenario is seen as an interaction between the application and the actors (users). These use cases are used to describe the requirements and can therefore also be used as a basis for acceptance testing.

With an ATM example, we show successful and unsuccessful cases. In this diagram, we can see the interaction between A (actor — in this case, people) and S (system). Steps 1 through 5 are success cases, which indicate that the card and password are verified and the actor is allowed access to the account.

1. A: Insert card,
2. S: Validates card and asks for a PIN,
3. A: Enters a PIN,
4. S: Validates a Pin, and
5. S: Allows access to the account.

However, there may be three other scenarios during the extension process, for example, when verifying a card and the system determines that something is incorrect. These expansion cases can be listed below. They are namely 2a, 4a and 4b as shown in the figure below.

2a) S: Card is invalid (message is displayed and the card is rejected)
3a) S: Password invalid (message displayed and ask to retry – twice), and
4a) S: Password invalid 3 times (eats card and exits)

Use Case Scenarios as Test Cases

A use case scenario is basically a document of use cases. In other words, it describes the actions that a user might take using a application or system. It also describes the situation the user may find himself in while using the software. In order to create accurate test scenarios, we often gather input from customers, end users and/or stakeholders. This helps to effectively cover all possible use case scenarios and enables comprehensive testing of all business workflow of the use case.

Use Case vs Test Cases

Use cases and test cases are terms that are often used in the field of software testing, and they are also closely related. A use case is used to specify how a system designed to perform a specific task is to be used. By way of contrast, a test case is a set of test inputs, execution conditions, and expected results developed for a specific test objective.

Comparison parameter	Use Case	Test case
Definition	A sequential actions which is use to describe the interaction among the role and system to maintain a specified objective,	A Group of test inputs, conditions and variables by which the charcaterstics of the software is defined.
Goal	To reach the last operation follow all sequential operation	validating the software as it is working fine or not.
Iteration	it follows different paths	it follows single test case is tested at a time
Dependency	it is dependent on the requirements	it is dependent over the use case
Requirement	Documents and research is required	Test inputs scripts and each test scripts complete one step
Completion	complete all step once	The testing is done again and again then finish.
Interaction	User	Results
Working	it is working as following the step by step function ability of the software.	it is working with the help of testers to validate the software

• Documenting use case details in Visual Paradigm
• How to Generate Use Case Scenario from Notes?
• Use Case Diagram Made Easy