Test cases are step-by-step instructions, including specific inputs and conditions, that testers follow to validate the system’s functionality as part of the business analysis and implementation. They also include the expected result. You and the project team can create hundreds — if not thousands — of test cases when supporting the testing effort. The larger the project, the more test cases you create. To create a test case, do the following:
Identify the test items.
Read through whatever project artifacts you have available to identify the test items. These documents may include the scope diagram, use case diagram, user stories, workflow diagrams, prototypes, and so on.
If you’re working on a program to search for airfares, the use case diagram may tell you that passengers are able to search for flights, which means you want to be able to test search for flights to ensure passengers can do it.
Create the input and output specifications.
Use the artifacts you reviewed in Step 1 to determine what data you need to put into the test and what the expected result is. When searching for flights, what inputs do you need to have in order to get the output? The answer may be something like the flight dates and times and the origin and destination locations.
Define the environmental needs.
These items come primarily from your nonfunctional requirements. For example, you may have a configuration requirement that states the solution must be able to run on iOS 5.1 and iOS 6. So you create a test case to operate under the iOS 5.1 environment and another for the iOS 6 environment.
You may also need to consider whether this new flight searching system works only on regular computers or is being rolled out as an app for tablets.
List any special procedural requirements.
If you need to process anything special, such as if you have to go outside the test to set something up prior to continuing the test procedure, list that here.
For example, suppose the interface with the master list of all flights isn’t working; in that case, you fake the test by mocking up flights in the master flight database between the steps for submitting the flights and receiving the results.
Document any inter-case dependencies.
List any other test cases or other artifacts that the test case must include to be complete. The flight searching system may contain dependencies on the list of airports and airlines in the system.
List any approvals.
Include who needs to approve the test case.
Test case writing is an iterative process, which means you go through it one piece at a time. Walk through the steps with one artifact (say, the use case diagram) and get the information out of that. Then, go through the six steps again with another artifact (such as the prototype) to uncover more test cases.
If you’re having a hard time uncovering test cases for any requirements or artifacts it may be because they aren’t written clearly or in enough detail. You may have to go back and redefine the requirement.
When creating test cases, think of both the positive (the expected value) and the negative (a value that leads to an exception condition) test conditions.