Let’s learn about the characteristics of a Good Test Case in this tutorial. A Test Case is a document that describes test input, test actions, and expected response to determine whether the application’s features are working correctly.
Test Case document
The Test Case document includes the following elements:
The purpose of the Test or description of what requirement is being Tested.
The method of how it will be Tested.
The setup to Test: Version of application under Test, Hardware, Software, Operating System, data files, security access, prerequisites such as our tests, logical or physical date,
Test Actions and Expected Results
Good Test Case
A good test case is the one that has a high potential to uncover an error, thus the successful execution of a significant Test Case increases our confidence in the correctness of a Program.
Writing good test cases is the most extensive effort in preparing to test software. Over half of all Software Development is maintenance Projects. How can you write Quality Test Cases that will deliver economical Testing the first time plus live again as Regression Tests?
Characteristics of a Good Test Case
Test Cases must meet the following standards:
Accurate: They test what their descriptions say they will test
Traceable. You have to know what requirement the case is testing. It may meet all the other standards,
but if its result, pass or fail, doesn’t matter, why bother?
Repeatable, Self Understanding: A Test Case is a controlled experiment. If it is theoretically sound but requires skills that none of the Testers have, it will sit on the shelf. Even if you know who is Testing the first time, you need to consider down the road- maintenance and regression.
Appropriate. A test case has to be appropriate for the testers and environment. If it is theoretically sound
but requires skills that none of the testers have, it will sit on the shelf. Even if you know who is testing the
first time, you need to consider down the road — maintenance and regression.
Self-cleaning. Picks up after itself. It returns the test environment to the pre-test state. For example, it
doesn’t leave the test system set at the wrong date. Automated scripts may call other scripts to do this.
Don’t confuse this standard with being destructive. Tests should be destructive, including trying to break a simulated production environment in controlled, repeatable ways.
Economical: They have only the steps or fields needed for their purpose. They don’t give a guided tour of the Software