3 practical examples how to create test cases for your application
To design test cases for an application, you don’t need to be an IT-person or a software developer.
You need first and foremost to understand the requirements which means understand what the application needs to do. After that you need to translate those requirements into test cases.
The requirements documentation can be available in plain text form or better in a more formalized way as:
- a decision table
- a user story
- or a diagram ( “state diagram” , “flow diagram” or “business process diagram”)
This article will show you examples how to derive test cases from those 3 different forms of requirements documentation.
The test cases can be later implemented, executed and automated depending on the platform you want to target.
The application it self can be:
- a mobile app
- a web application
- or a blockchain smart contract
The process of designing tests is similar.
1. Test cases from a decision table for a web application
Let’s assume the application you want to build is a hotel booking web application and in the booking component you want to offer discounts and rewards (free drink vouchers) for hotel customers depending on some conditions as described in the table below:
As you see in this example above, when it comes to requirements based on conditions and outcomes (Actions), a decision table is more suitable then a lengthy plain text.
Gaps, missing outcomes or ambiguities will be directly more obvious in the table than in the text.
So if you have a documentation in a plain text form, try to translate it first into a decision table when appropriate.
Test cases are indeed now much easier to derive from the individual rules displayed in the table. ( see the “table columns” containing the rules: Rule1…. Rule 4 in the discount decision table above).
That means for our decision table, the derived example test cases for every Rule would look like follows:
2. Test cases from a user story of a mobile app
In this second example, let’s assume you have a mobile app where the registered user needs to login first to be able to access their Dashboard.
The documentation for this requirement could be available as a user story, which is a common documentation form in agile projects.
Here you need to focus on the success and exception scenarios to derive your test cases.
You will need one or multiple test cases for every scenario (depending on the story).
The test cases from the login user story are listed below.
Note that in the exception scenarios we have 2 cases because we have 2 different input fields (user id and password) which can be invalid and both need 2 different error messages. ( Test cases 2 & 3)
3. Test cases from a state diagram for a smart contract
In the last example. Let’s assume you have an online marketplace driven by a blockchain application.
Something like eBay online market place, but driven automatically by a smart contract deployed on the ethereum blockchain.
A seller creates a smart contract when he has something to sell. The smart contract acts as an “Escrow” account to manage the money with a defined program logic tied to it.
The simplified workflow is then a as follows:
- The buyer transfers the money to the smart contract (instead of directly to the seller or to an online marketplace like eBay). The money is locked into the smart contract and no one can withdraw it
- The seller can verify that the money is transferred to the smart contract, and sends the product to the buyer, but he cannot yet withdraw the money from the smart contract account until the conditions are met ( Delivery of the product to buyer)
- As soon as the product arrives to the buyer, the money is sent automatically by the smart contract to the seller
So the smart contract has 3 possible use states:
- State 0: Smart contract created ( Escrow Setup)
- State 1: Buyer transferred Price ( Payment Locked)
- State 2: Product delivered and seller receives money. The process is finished here (end state) and the contract can no more be used (Escrow Inactive)
It make a lot of sense that the documentation of our smart contract is available as a “state diagram”, since state diagrams are good at describing the behavior of an entity across several use states.
Note that the state diagram shows all valid states and valid transitions during the life cycle of the contract.
For example a direct transition from
State 0 -> State 1 is valid
State 1 -> State 0 is invalid ( there is no transition possible)
also
State 0 -> State 2 is invalid
So looking at our state diagram above we can already derive some or all valid and invalid test cases, to verify if the implemented code in the smart contract is correct and does what we expect.
If you want to learn more about technical test engineering, how to design, implement and automate test cases for different platforms. Check out our event page for the next courses.
We offer for example a practical course where you can learn testing for the different platforms ( native mobile iOS/Android, web, and ethereum smart contracts). Contact us at smartskills for more details.
