I've been writing test cases a long time. And I have seen people write them different ways. I go back and forth as to whether my first iteration should just be what the user should see in the Application, then write a separate test case for the functionality, or combine them together. So when I am done saying in this section you should see, this, this, and that, go right into how that section should function, or keep them separate and do functional in a different test case, or later in the same test case. Just looking to see who does what.
I see test cases as a placeholder of ideas based on the requirement at hand (functional,regression,integration) to test the application under test.If the requirement is functional test , he derives possible functions from the test specs and writes verification checks.
Thank you for initiating a topic on test cases...
I have seen many people working in different ways, and it mostly depends on the needs of the people who will be running the test cases themselves, let me explain.
When working with testers who work on very dynamic environments (e.g. start-up companies) they tend to work with what I call "check-list test cases" and these are very high level test cases that can be seen as checklists of functionality or even "general stuff" to test. In these places we usually see applications that are changing all the time together with testers who are power-users of the things they are going to be working with, so going into too much detail can prove wasteful and even harmful for the tester.
I've worked with companies who rely heavily on outsourcing and these guys used to write test cases that went very deep into the steps and actions needed to do during the test cases. In a sense these guys did not leave much to the imagination of the tester to execute. These tests took a lot of time to write, and underwent a number of review cycles, but in the end they could be sent to someone with only minor knowledge of the system and this person would be able to execute them without any issues. BTW, I also saw similar cases in places that worked with much regulation.
I also saw places that gave their tests to be written by business users. In these places they work in a kind of in-between approach where the tests had steps that described the processes but these steps where not very low level since the users knew the system pretty well. These tests also had many things that the users could do differently based on their own way of working - and in a way this was the objective of giving them these tests, to check how the system behaved once it was delivered to the field. Still they underwent a lot of reviews, and the interesting thing is that many of these reviews where done AFTER the users ran them, when they came up with additional steps that needed to be run.
In short, I think that the way you write your test cases and even the way you review them will depend on the environment you are working on...
Hope this helped.
The way any tester writes test cases is dependent on...
1. Test Design (What are the test case types and whether these should be "Scenarios" or "Test Cases") &
2. Business Objectives (Detailed Level in most cases).
For # 1 above, you can have testers write "Scenarios" (something like that written by the Business Users) Or "Test Cases" (with steps explaining in detail the flow).
This depends on the kind of setup that you have. If there is enough time to write test cases & the team has many members across locations with less business knowledge. There is a high dependency on the business requirement documents given by the business teams. And most importantly, if the project has many phases with these test cases going to be used many times. Then, usually projects go with test cases.
Test Scenarios are recommended with projects having less time to create coverage and usually the team may not have many changes (typical with product teams).
The test types "defines" the kind of test case (or scenario), such as UI, Functional, Validations, Batch etc... You can create a test-design with additional groupings - based on the system design, test needs and the testing approach.
Finally, on # 2 above, the overall business objectives is the most important when writing any test case (or test scenario). Each test case needs to be written to "achieve" a business objective Or "satisfy" a business requirement. It can also happen, that multiple test cases have to be written to satisfy a business requirement.
Hence, nobody can give an "objective" answer to this question here, although the above can be a of little help to start with.
To conclude, with my experience... with my teams I follow this approach as to...
Try to write a test scenario, whereby the time take to execute shall not be more than 3-5 minutes. If it exceeds, then we put it in a separate category & analyse if it can be broken down further (although, at the same time helping achieve the business objective.