Testcases

3 years back, when I started my career in testing, testcases and testcase writing were something I hated the most. Now I feel it is the most basic and unavoidable entity in the testing field. Testcase writing substantiates the testing thought flow and, reviewing them solidifies those collections of thoughts or logic which were gained from the design docs and requirement docs. Testcase creation should be started from the requirement phase and will go till the coding phase. Each for one phase

Testcases should have a proper format which, of course depends upon the standards of your organization. A good testcase document should contain following information.
Module Name: For any software made or in-making should have modules or functionality.
Type of testing: Unit, System, Regression etc
1. Testcase ID: Every testcase should be identified by a unique ID. The implicit details which should be reflected through the ID are functionality, Module and sub module.
E.g. testing a “parameterized report for the delayed payment”. Here report is functionality, Module is delayed payment. We will be testing the parameters one by one.
2. Testcase Name: Name of the test case should summarize the activities of the tester.
3. Steps to reproduce: Now, this is the most important part in the testcase, the part which should be so simply and elegantly written to be understood by a layman.
4. Expected result: What is expected from the application?
5. Actual Result: What application gives to the user?
6. Pass/Fail: Is the testcase passed or failed?
7. Defect ID: If the testcase fails, log it. Enter the defect Id in the testcase document. ( This makes me happy…I am explaining it J)
8. Test Run ID: Which is the run of these testcases? First run? Second Run? Third Run? You need to know and record it.
9. Test Run date: Date at which the test run.
10. Tester’s Details: Name, ID.

What defines a good testcase document?
The testcase document which helps the tester to hunt down the maximum number of bugs can be defined as a good testcases document. It should contain both positive and negative cases. Yes, Positive testcases too, a tester is neither supposed to trust the developer nor what he “thinks”.