It is the brief description of a particular use of the software application by the users. Basically, it is made on basis of user action. It is widely used in developing test cases at acceptance level.
Use Case is a list of action taken by actor while interacting the system to achieve a goal. Here, actor can be anyone either human users or any other external system. Basically, it is a technique that helps to identify test cases that cover the entire system, on transaction by transaction basis, from start to finish.
In Use Case, there will be a set of action for the users to complete. The action can be −
The action which are being developed relating to software
In this, we provide a complete overview of the distinct ways in which the user interacts with a system to achieve the goal. Better documentation can help to identify the requirement for a software system in a much easier way.
This can be used by Software developers, software testers as well as Stakeholders.
Uses of the Documents −
Developers use the documents for implementing the code and designing it.
Testers use them for creating test cases.
Business stakeholders use the document for understanding the software requirements.
There are two types of use cases −
Sunny day use cases − It is the primary cases that are most likely to happen when everything does well. Sunny day use cases are given high priority than the other cases. Once we have completed the cases, we provide it to the project team for reviews and ensure that we have covered all the required cases.
Rainy day use cases − Rainy day use case can be defined as the list of edge cases. The priority of such cases will come after the ‘Sunny day Use Cases’. We can investigate with the help of Stakeholders and product managers to emphasize the cases.
The various type of elements in use cases are given below −
Actor − Users that are involved in Use Cases Actions.
Precondition − Conditions to be Satisfied before the case begins.
Basic Flow − Basic Flow is the normal workflow in the system. Basically, it is the flow of transactions done by the Actors on accomplishing their goals. When the actors interact with the systems, and there won’t be any error and the Actors will get the expected output what he is expecting.
Alternate flow − Apart from the normal workflow, a system can also have an ‘Alternate workflow’. This is the very less common interaction which are done by a user with the system.
Exception flow − Exception is a flow that prevents a user from achieving a certain type of the goal.
Post Conditions − The conditions that needs to be checked after the case is completed.
Common mistakes that the participants do with Use Case is that either it contains too many details about a particular case or no enough details at all.
These are textual models if required we may or may not add a visual diagram to it.
Determine the applicable precondition.
Write the process steps in the correct order.
Specify quality requirement for the process.
When we are trying to write a use case, the first question that should arise is that “What is the primary use for the customers?”.
We must have to obtain a template for the these.
It must be productive, simple and strong. If there are minor mistakes, then a Strong Use Case can impress the audience.
We should have numbered it.
We should write the Process in its step Order.
Give proper name to the Scenarios, naming must be according to the purpose.
This is an iterative process, that means when you write them for the first time it won’t be perfect.
Identify the actors in the system.
Let’s consider the first actors. We can have more than one actor having the same behaviours.
For example, in online shopping, both Buyer/Seller can ‘Create an Account’. Both Buyer and Seller Can Search for Item. So, these are duplicate behaviours and these need to be eliminated. Apart from using the duplicate cases, we must have more generalised cases to avoid duplication.
We must determine the applicable precondition.
Consider a scenario where a person tries to shop something from online mode of shopping for that the user will First Login to the system. The user will may start performing a search operation and select one or more items shown in the search results and he will be adding them to the cart or buy.
After all this, user will buy or check out. So, this is an Example of logically connected series of steps which the user will perform in order to fulfil the system to accomplish the task.
While developing use cases, test case table is usually developed. There will be several steps that user should complete −
Validate Card and ask for PIN
Enters a PIN
Validates a PIN, and
Allows access to the accounts
Following this, there will also be a list of extension within the table. For example, if the system determines something is incorrect.
The extension can be −
Display a message that the card is not valid and rejects, and/or
Display message that pin not valid and ask for re-try for times only
A use case specifies type of some behaviour that subjects can performed in collaboration with one or more actor.
The use case cannot be implemented, which implies that it is only designed. On other hand, the test case is designed, and later we implemented them.
The use case is obtained from the BRS (Business requirement specification) whereas the test case is derived from the use case.
The use case is a graphic representation of client requirements, whereas the test case is not represented in only documented in an excel sheet.
The use case is a document and it always describe the flow of events of an application. On other hand the test case is a document that always contains an action, event, and expected output of a particular feature of an application.
The use case relies on the software requirements. On other hand, the test case depends on the use case.
The use case collects the requirements, and on the other hand, the test case will analyse those requirements.
In use case, the results are not verified. On the other hand, the test case results are verified, which means that the test case checks if the result shows in use cases is functioning right.