Query on Test Case Designing
I have an doubt on designing the Test Case. How should we design the Test Case? I mean to say that 1 Test Case for all the features of a requirement or multiple small small test cases for each features.
How many steps should be in a Test Case as per the Standard.
Is it better to write the small test case having some steps or 1 test case having 20-30 steps??
Please let me know the details...
Testcase must have unique Objective. If steps are reoccurring, you should right first step to call the reusable testcase and then proceed with current test case. Test objective give you priority to manage your testing to match precious time. Length of step doesn't matter.
Rules of thumb vs. Silver bullets when thinking about Test Cases
For me I like using Rules of thumb mostly. For example test cases should be modular, as Yogi wrote above, but sometimes for me it makes more sense to group some test cases that are very closely related (e.g. positive and negative scenarios of the same feature) and save time to my testers when defining their test sets. I wrote about some of my rules of thumb in this article about test management in my blog - Rules of thumb vs. Silver bullets | QA Intelligence - a QABlog.
I also wrote another post about different things to think about when writing down your test cases here - If you?re going to write-down just one test case? | QA Intelligence - a QABlog.
In the end it needs to be the approach that makes the best sense to your team, to your process and to your product. Also don't be afraid to start with one approach and fine-tune it as you go along.
I hope this helps!
How about not using test cases? List the objective. Say to explore going there multiple ways. I prefer mischeivious testers rather than rule followers. Say things such as try going to the Book entry screen and enter some data. Try going to the same screen multiple and creative ways. See if the data still appears.
But have the testers keep of log of where they have been.
I find more defects when I have a general direction, but I am left to do some experimentation.
Are you talking about written or automated?
For automated tests, I only do 1 verification per test. There is lots of redundant setups and tear downs for each test, but the key here is I can parallelize them.
For manual tests, I think it's best to keep them at fairly high level, and organize them into "Tours", which are grouping of test cases that can be executed as part of a continuous flow.
One Test Case is enough with multiple steps just give them an unique id for each bug what you noticed. So its easy to track the bug.
You can have a script that tests for multiple things. Then in QC have multiple test points each pointing to the single script. If you find a defect, you can relate it to the requirement. I don't know if it is better or worse to have more than one test point per script. But this is a way that you can link defects to requirements.