Use Case Testing – An Introduction

Before beginning a test schedule for any software or system, requirements need to be prepared so everyone involved knows how each element has been designed to function. These documents are referred to as SRS, or software requirements and specifications. SRS is the traditional non-Agile method and is often supplemented by an additional approach known as Use Cases which can also aid with testing. A use case describes the interaction of a user with a system in a sequential manner for accomplishing a goal, and use case diagrams are how the interaction is represented. From the use case diagrammatic representation, the developer will understand what to code, the customer will know what to expect, and the tester will know what to test. Use cases provide a formal way to write the requirements from the perspective of the end-user. Use case testing is a technique that helps testers identify any missing links in a procedure to minimize the risk of failure in production.

Use Case Diagram and Use Cases

Use cases and use case diagrams are employed to explain the functionality of a system in an easily translatable way. A use case is a sequence of steps which the user will perform to achieve the desired output. It basically describes how the user interacts with the system to achieve those goals but is not concerned with  details of implementation. The graphical representation of the use cases through diagrams, sometimes regarded as the blueprint for a system, provides an overview in relation to associated users and related use cases. The formula used in the visual representation has an actor to indicate the dynamic causal element that interacts with the system to perform specific actions. As an example, when we have to write something in notepad, we use a keyboard to interact with notepad, which makes us the actors.The term actor, most commonly refers to the end-user, but could just as easily mean a different system or some external hardware that interacts with the system under test. With the help of use cases, we get to know the various ways the user can interact with the system. Hence, with use cases, expected behavior can be defined and we get to know the overall scope of the system.

Identification of Actors

As mentioned earlier, an actor is normally a user who will interact with the system. We can take an example of the university registration system and identify the actors.

1. Administrator
2. Students
3. Faculty

These users have specific roles and they will interact with the university registration system accordingly. Administration is able to add and delete programs, departments, students, faculty, etc. Similarly, students can add and drop their courses and track their progress, whereas, faculty can generate different reports based on their requirements. Following the identification of each individual actor’s specific roles, we can easily identify the scope and the expected actions that each actor can perform.

Identification of Use Cases

To be able to create a use case, a system must have a level functionality with which one or more actors interact. The person (or an external system or hardware) must be able to input to the system under test, so as to expect a presumed result. Once the requirements are all gathered and finalized, it’s common to reference them in creating use cases for the system, especially for areas that need further elucidation. Following are the points which need to be kept in mind when creating use cases:

1. Every use case should have a unique and meaningful name
2. Each use case should accept the interaction of multiple actors
3. A use case can only be initiated by the actor (i.e. actor must perform an action to proceed)
4. Every actor should be distinguished by their specific role when interacting with the system (i.e. which actor will initiate which action and under what conditions, should be clearly noted to avoid any confusion)

In the university registration system, we can identify use cases for every actor as follows:

#	Use Case	Actor(s)	Description
1	Login	Administrator, Faculty, Student	Login Change Password Forgot Password
2	Department Details	Administrator	Add Department Edit Department Details Delete Department View Department Details
3	Student Details	Administrators	Add New Student Edit Existing Student Delete Existing Student View Existing Student
4	Student Portal	Administrator, Student	Add Student Details Add/Drop Courses View Progress/History
5	Faculty Portal	Administrator, Faculty	Generate Report Program-wise Generate Report Semester-wise

The identification of use cases should be done with care, because if not done properly, can have implications for the system. For the best coverage of test cases and testing it is recommended to mention all the basic and alternative flows in use cases, which means providing a better foundation for a quality system.

UML Use Case Diagram

The diagrams are pretty simple and illustrate a pictorial view of the system, where the relationship between actors and use cases can be shown. Following are the three components of use case diagrams.

A simple use case diagram between actor and login use case is shown here.

If requirements are limited and the system small, then a single use case diagram can suffice, but if the system is large and complex then multiple use case diagrams may be required. In the case of our university registration system, we will show the use case diagram as below.

As you can see from the above use case diagram, we have five use cases and three actors who are relating to their specified use case with the aid of relationship arrows.

Use Case Description

As previously illustrated, actors may interact with use cases for the purpose of achieving the desired output. There is no standard templates for writing use cases, so teams can write in their own style to align with their existing process. However, for the purpose of demonstration, we will use a simple format as a guide to writing use case in a competent way.

Login Use Case Example

1. Introduction
   This use case outlines the steps that need to be followed in order to login into the system
2. Actors
   • Administrator
   • Student
   • Faculty
3. Pre-Condition
   The user/actor must have valid credentials
4. Post-Condition
   If use case is successfully executed, the user/actor should be logged into the system, otherwise, the state remains unchanged.
5. Basic Flow
   Login
   • The page will request the user/actor to provide valid credentials
   • User/actor enters the credentials
   • User/actor enters into the system
6. Alternate Flow
   Invalid Credentials
   • If user/actor provides invalid credentials in the basic flow, a validation message or error message should appear. Hence, returning the user to the basic flow..
7. Special Requirements
   None
8. Associated Use Case(s)
   None

Difference between Basic and Alternative Flow

The basic flow is the sequence where the majority of events take place between user/actor and the system for a specific purpose. Whereas, alternative flow works when the basic flow is unsuccessful and an error occurs.

Use Case Testing

Having explored use cases, we now turn our attention to use case testing, which falls within the category of black box testing. The intended purpose of use case testing is to make sure that all steps a user follows to interact with a system, are valid and work as expected. Let us now look at an example and understand the context of use case testing.

We have a university registration system. For a student to add/drop the course he or she must first login into the system and select the intended course which they need to add or drop from the semester, then after selection, finalize the action and log out from the system. These are the logical steps which the user will perform to accomplish the desired task. Before the student comes to enact this scenario, the end-to-end flow of the system will have already been tested and verified. The point of using this illustration is to show that use cases are not the arbiter for deciding the quality of the system. Rather, these are the path that users will use to perform the already recognized task in a sequential manner. By creating use cases, we are more likely to identify defects in the paths which user follows.

Testers should keep in mind a few guidelines regarding use case testing in order to improve the productivity of the system.

• Use Case Document Review: Tester should review the document and verify that all the use cases are complete and conform to the specified requirements.
• Special Data Conditions: Tester should verify validity checks for special symbols. For example: for email address ‘@’ and ‘.’ symbols should be validated for such inputs.
• Mandatory Data Inputs: Tester should validate such inputs without which, execution of a function is not possible. For example: In the login form, both username and password are mandatory and a validation check should be in place. Similarly, there are some fields which are not mandatory to fill such as telephone number, registration number, etc.
• Domain-specific Checks: Tester should ensure that domain-specific checks are in place because they are crucial to the business. In our university registration system, for example, a student should only able to add/drop only one course per semester and a student must able to login only with the roll number, etc.
• Basic and Alternate Flow: Tester should make sure that both flows function in the correct order.

Conclusion

In this post, we have explained in detail the use case. To write good use cases, it is necessary to have a good knowledge of the domain under test. To sum up, use cases capture the expectations of the end-user, and use case testing is performed to identify missing links and requirements, which do not comply with those specified.