Test Case: set of input values, pre-conditions of execution, expected results and post-conditions of execution, developed for a specific objective or test condition.” (IEEE 610)
A Test Case shows the paths taken by a module, Use Case or functionality within the project. It serves as a basis for testers to run tests manually, but it can be created, too, in order to automate tests. In addition, Test Cases should cover as many situations as possible.
In short, a Test Case is a set of actions and the expected results for them.
What should you do?? -> Actions
The actions are the steps that will be performed by the tester/who run the test cases. These actions should lead to an expected result. They must always start with an infinitive verb – fill, validate, click, trigger – or imperative – fill, validate, check. Examples:
– Validate the “Password” field mask
– Check if the record has been saved in the database.
– Click on the “Back” button.
– Access Admin > Settings menu.
What did you expect?? -> Expected Results
The expected results are the responses to the actions taken by the user. Each action should have an expected result.
Examples:
What else you need to start writing the test cases?
- Be aware that the purpose of the Test Case is to find bugs;
- Be focused and think about several possible scenarios;
- Be detailed (or even perfectionist);
- Know some testing techniques (it is not mandatory, but it always helps);
- Have a user view;
- Know the business;
- Be critical;
- Be proactive.
Characteristics of a good test case..
1. Have a clear, objective, traceable and self-explanatory title : the title of the Test Case must allow it to be easily found and recognized, it must make clear what it’s purpose is.
2. Follow a pattern: Following a writing pattern is ideal, especially when there is one more Test Analyst on the team. Example: always put the menu in square brackets in the title of the Test Case, put fields and messages in quotes.
3. Be objective and not exhaustive: always avoid Test Cases with many steps (more than 20, for example). This is not always possible, but a very extensive Test Case becomes exhausting and can cause you not to pay attention to every step.
4. Make failure situations evident: the purpose of the Test Case is to find bugs, so it is necessary that the expected result is clear. In this way, the tester will know exactly the answer that the system should give, leaving the flaws evident.
5. Be self-sufficient: all the information needed to perform the test must be within the Test Case, whether the prerequisites, possible templates, etc.
6. Achieve the greatest possible coverage: Test Cases must cover as many scenarios as possible, that is, there must be a Test Case for each documented flow.
7. Always be up to date: an outdated Test Case will confuse whoever is testing it, as the expected results will no longer be in accordance with the documented.
8. Be reusable: Ideally, Test Cases should be written to be updated and reused, either in the following Sprints or in the system integration / approval phases.
Some Extra Tips for Authoring 🙂
- Plan before writing: in very complex cases, you can create a document to aid planning (it can be a table / matrix / flow, a handwritten sheet).
- Enter information that seems obvious: what is obvious to you may not be obvious to someone else
- Always inform the expected result: a step can never be without the expected result. If there is no expected result, the action is not complete. In this case, it may be necessary to write a more detailed action for there to be an expected result
- Take care of very extensive actions: just as there should not be an action without an expected result, an action cannot be extensive enough for the tester to get lost when performing it. Each action that generates a result, must be a step.
- Take care of duplicate and / or contradicting information: it is very important to take care that one step (or even a Test Case) does not invalidate another.
- Take care of grammar: always, please! Put a period in sentences, accentuate words correctly.
- Can Vs Must: never use phrases like “the system can “, prefer the word must/should , so there is no doubt about the expected result for the action.
- Review the Test Cases at the end of writing.
Happy Writing 🙂
References: