This document only entails writing test cases for manual testing.
The trick to writing test cases before the software is even built is imagining that it is already built and you have it in front of you. By pretending so it forces you to come up with scenarios that you could’ve only thought of when the product was already developed.
What is a test case in software development?
Simply put, a test case is a set of conditions using which it can be determined whether a feature of a software application is working as intended. Usually consisting of steps outlining how the test will be executed, it helps testers keep track of the success criteria of a feature and helps developers understand the expected results.
A test case is also accompanied with test data and expected results. Test data can be a user, a file, any data that is used in testing of a software. Expected results is written information that specifies what should happen when a certain test is executed. Expected results is sometimes also called Success Criteria.
Prerequisites before writing test cases
It is imperative that you have the requirement document of the software application already written and a user stories document. A requirements document is a detailed list of all the features and functionality that the software application is supposed to do. Where as user stories are short descriptions of functionalities from a user’s perspective.
It is also helpful if there are wire-frames and/or mock-ups of the application. They aren’t crucial for writing test cases but can be helpful so that you don’t have to imagine each functionality as the wire-frame or the mock-up can act as a visual sample of how the product is going to look like.
How to start writing test cases
Once the above documents are available, the best way to approach writing test cases is imagining you already have the working software in front of you. Think of what a certain functionality was meant to do and then think of how it can be broken. Think of what it was supposed to do and then think of what it isn’t supposed to do. Imagine the functionality’s performance on a web browser vs a mobile one, on wi-fi vs on slow mobile connection. Imagine the performance of the software when the test date is increased to 100s, 1000s or 10,000s. Think of the UI of the feature. Meanwhile never ignoring the end user’s perspective during all of it. When you account for the above, you will be in a better position to write test cases.
When you imagine you already have the product in your hands, it compels you to have foresight. It forces you into the user’s shoes.
Few more points to remember
- Keep the language simple and easy to understand
- Avoid repetition. You don’t want the same test case written 5 different ways.
- Under any circumstances do not skip a test case as obvious. No matter how obvious you think it might be, it is always better to write it down in order to maintain clarity across all involved stakeholders.
- Do not assume any feature/functionality – your test cases should be based on the requirement document only
- Spend time preparing test data and keep adding to it
- Do not forget prerequisites for every test case i.e some conditions that should be met before the test is executed.