The creation of new Use Cases (UC) should take into account the modules and features pre-existing on the platform. If the modules needed for a UC creation are already present, the inclusion of the use cases and test cases may occur quickly or even immediately. However, if a use case involves other components besides those that already exist, the GSMA Inclusive Tech Lab is on hand to accept suggestions, and incorporate them into future Interoperability Test Platform updates.
In order to create these new cases and submit them to our team, it is necessary to understand and detail the scenario that will be simulated. Below we provide relevant information and a few steps to follow for creating and proposing new test cases.
List of Steps
- Definition of a Scenario: Firstly, it is necessary to understand the scenario in which the use case is inserted, as well as the actors and entities involved.
- Creating a User Story: As a way of exemplifying the use case scenario, User Stories can be used to give examples of real events where the use case may be applied.
- Choosing the evaluation paths: It is important to detail the different evaluation paths for the use case. This process will facilitate the understanding of the flow and the creation plan for the test cases that will be used to validate each path. Both happy flows and unhappy flows may be considered.
- Sequence Diagram: If possible, the creation of a sequence diagram for the different paths will ease the test cases definition. You can also use the section Creating a Test Case to learn how to create a Test Case YAML file directly.
Use Case Description
The following table contains essential fields for defining use cases. Before describing a new UC we suggest understanding and filling out this information.
|Use Case Name:||Name by which the use case will be identified|
|Summary:||A summary explaining the scenario that will be simulated by the use case|
|Actors:||Actors who may be involved in the transaction|
|Preconditions:||Preconditions that must be met for the use case to be successfully simulated|
|Description:||A step-by-step description of the use case's operating sequence|
|Exceptions1:||The exceptions that you want to address during the validation of the use case|
|Postconditions:||What state we can expect after simulating the use case|
Use Case Suggestions
- 1 : The exceptions listed are directly related to alternative paths the use case can take. Using the exceptions, it is possible to derive the unhappy flows covered by the appropriate test cases.