Why this matters
Writing test cases is the skill that appears most often in testing adverts we read. A good test case lets anyone on the team repeat a check and get the same answer, which matters when a release is due tomorrow and you are not the one running the tests.
What a test case contains
A test case is a short, precise recipe. Most teams use these parts:
- ID and title: a short name that says what is being checked, such as "TC03 Send money to a valid number".
- Preconditions: what must be true before you start. For example, the user is signed in and has at least 100 cedis in the wallet.
- Test data: the exact values to use, such as the recipient number and the amount.
- Steps: numbered actions, one action per step.
- Expected result: what should happen if the software works correctly. This is the most important line.
- Actual result and status: filled in when you run it: pass, fail or blocked.
Write steps so that someone who has never seen the app could follow them. Avoid vague words like "check it works". Say what "works" means.
Positive and negative cases
A positive test case checks that the software does the right thing with valid input. A test case checks that it handles invalid input safely, with a clear message and no damage. Many serious bugs live in negative cases, because developers naturally think about the happy path first.