Designing Test cases is with the reference of the Software Requirement Specifications (SRS) and clearly mentioning the steps to execute the test case and what is the expected and actual result of your test case execution.
I would add that one must clearly state what is expected from performing that particular test case. It is very important that the steps are clearly specified. When creating test cases, one must assume that some one else who has no knowledge of the application will be performing the test case.
The way I write test cases is that I have a 5 column table as follows: first column is the step number ,second column is the steps to execute, third column is the expected result, 4th column is the section of requirement being tested and the 5th column is to indicate is the test case passed or failed.
By listing the section of requirement being tested helps with the traceability matrix
it is right that test cases are designed with referance to the software requirement slpecifications(SRS).And it should be written in specific format as follows:
1)TestCase ID :
2)TestCase Name :
3)TestCase Objective/Purpose :
6)Expected Result :
7)Actual Result :
9)Defect ID :
bye for now [img]images/icons/smile.gif[/img]
Software QA Engineer-ARYAN InfoTech
Test-Driven Development is not a Testing........
Im a newbie here, kindly excuse me if am wrong.,
Before writing test cases, scenarios should be writen and the reference of scenarios id in the test cases may help the testers for easy reference, so the format goes like this..
1. Scenario No.
2. Scenario Id.
3. Test Case Id
6. Test Steps
7. Expected Result
8. Actual Result
9. Pass / Fail
Correct me if am wrong.
HEAVEN doesnt need me. HELL is afraid, I might take over.
I think we are mixing terminology, again...
A test case is something that must be tested. So what is important is to document the specifics of the what. An example might be easier to explain:
Case 123: creation of a new customer
Case 124: put customer in status 'to follow up'
These are test cases, things that must be tested.
A test procedure/scenario/... documents how the test cases can be checked. Here we see the steps.
I do agree though that in a lot of companies both are merged. In fact these companies often loose track of what really must be tested. The how is documented, but the first step (the what) is often not documented. So it is hard to identify the coverage that is reached.