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”.


Pradeep Soundararajan said...

There are one billion test cases that don't find bugs. There is a tester who finds bugs.

"...it is not a test that finds a bug but it is a human that finds a bug and a test plays a role in helping the human find it."

JeriK said...

Hi Pradeep,

I agree with what you have said. At the same time I also stand with the fact that "Out of those billion tescases, there can be many testcases that helps the tester to find bugs"

I know you will hang me for the 'can' term I used in the previous statement. :)

Tester, as a human can err, can miss things out. What is wrong there to write down the testing thoughts and keep them organized?

Pradeep Soundararajan said...

I also stand with the fact that "Out of those billion tescases, there can be many testcases that helps the tester to find bugs"

Well, test ideas in a human brain are converted to test cases. So it is the test idea in some brain that helped in finding a bug and not a document that arrived by vomiting those test ideas on a MS Word or MS Excel or elsewhere.