Test Case - A Quick Snapshot
In this article let us try to understand the basics of a Test Case.
How well can a Test Case be defined? What's on your mind? Let's see :)
Set of input data, execution conditions, expected result that is developed for verifying the compliance of a requirement could be defined as test case. Does it make sense?
Let us discuss about some of the Best Practices in writing a good test case. Lets keep this in mind before writing the test case.
1. Test case should be written in such a way that it ensures the maximum coverage of the requirements.
2. Test Case should be able to uncover most of the defects and prove the software to be buggy:)
So now lets move on to discuss about positive and negative test case with an example.
Let us take an online store and you hit the URL of the website and the sign in page pops up. User name and Password fields are given. The client has given his requirement that user name can take alphabets, characters and only two special symbols like @ and _. Now, if the input is given as techdive.in@gmail.com and if an application is tested, it is considered to be positive test case. If the input data is * or & (anything apart what is specified) the test is designed to be the negative test case.
To be very simple, the test case, which is designed to test the application with the given requirements, is termed as Positive Test Case.
Test Case, which is designed to test the product not confining to the requirements, can be depicted as negative test case.
Let us also look into the significant elements that form the test case.
Test Case Id - Unique Identifier which is used to identify a test case
Functionality/Feature ID - Unique Identifier of either the functionality or the feature number.
Precondition - Set of conditions which has to be executed before the other test case has to be executed.
Description - Description of the test case.
Execution Steps - The steps that are followed to execute the test case,
Expected Behavior - The expected outcome after executing the test.
Actual Behavior - The results that you actually get after executing the test case.
Test Data - This space can be used for displaying the required data for executing the particular test case.
Priority - Specifies which test case has to be executed first or generally the execution order.
Result - Pass/Fail (If the test case fails you can log it as a defect and mention the Defect ID)
Tested By - The Name of the Test Case.
Date - The Execution Date.
Here is the generic sample test case template. Please refer the below Test case template for reference.
How do you measure the effectiveness of testing? Do you like to have any wild guess?
Well, you can ask your engineers to clock 14 hours a day? Doesn't it sound ridiculous? Well then what do you think is the best way to ensure the testing is done to the level best.
One way is to check if all the requirements are tested. So how do you do that? Here comes the traceability Matrix :). Mapping of requirements to test case is known as Traceability matrix. There can be a one to many mapping between Requirements and Test Case, which depicts that more than one test case, can be mapped to a requirement. It is also used to ensure better test coverage technique, which is widely used in the industry.
In short, a good test case should be able to uncover the maximum number of bugs or defects in a software application or a product.
Hope the information provided would suffice you to start writing efficient test cases. Happy Test Case Writing :)