In our Project we have a test case based on Rational Test Manager (RUP Process).
This test case includes:
I feel that having expected results for each step is an over kill in writing a test case and includes lot of redundant steps.
What are the test case templates that everyone else uses?
Would this differ for Web, Desktop and Mobile?
I'm currently using Quality Center for test case management, and it has a similar structure. I've found that in the expected result section for each step is a good place to write down some items that you would look for outside of the basic 'action completes without error'.
You could mention a few points of other questions to ask while the application is in that state. I think that it is a good template for any platform, but I also don't have a problem with leaving an 'expected result' step blank if I don't believe it would have much value.
I've used Excel for this in the past, it's cell limits were one way to enforce terse descriptions and notes so the cases did not get too big. It allowed us to make one worksheet with the cases and pull them into other sheets for scenarios so we could test the steps in different conditions. It was a little bit to set up but once we learned the system it was fairly easy to do, it also allowed us to summarize results within the Excel document and then roll up the summaries into a higher level document that covered all of the case; the company liked Excel so we used what they wanted.
Expected results we usually kept small when we implemented this, the idea was to only know enough to verify the case, not write down everything about it. Although as Todd says, if you don't find the information pertinent don't add it.
Yes , I have wrote a test case of Web application , Mobile Application according to the requirement and also module wise.To write the Test cases different format we are using, but in which some field is required to write the test cases.Commonly to write the test case we can use the excel.
See above image of the test case , in which Test case description , Expected Result , Actual result,precondition field should be required.Into the test case remember that Expected and Actual Result should be same. Into the Mobile Application define all field also required into write mobile App test case.
I like the AAA pattern:
Test name:
- Arrange all necessary preconditions and inputs.
- Act on the object or method under test.
- Assert that the expected results have occurred.
Although designed for Unit-Tests. I think it covers all you need also for manual test-cases. Creating asserts for each step in your Act seems overkill, although sometimes I want to be sure that after the Arrange something is in a certain state and I do add Asserts in the Act for this reason.
Keep your tests small and short and try to keep the least number of Asserts as possible. Try to keep the Act steps to a maximum of 10 or try to split up the test in multiple cases.
I don't see a need for a notes field, since that is what the defect tracker is for. If a test-case fails report it! :)
In Expected Results I also put any graphical updates the product did to the screen (font color change, etc.)
Whether it's "Notes" or somewhere else I put the reasoning behind the logic. As Ralph van Roosmalen writes in his blog http://softwaredevelopmentisfun.blogspot.com/2011/05/things-tester-can-learn-from-programmer.html:
"A good programmer writes why-do-we-do-this comments. For example in the above code, he describes why a should be less than 1 and why he raises an exception. As tester always try to write why-do-we-do-this comments, in your test scripts and in your automated test scripts. How you test, that is clear, describe why you are testing the software."