A recent discussion with a top-brass guy in software QA business brought up this very question which I really didn’t bother about for past six years as a QA professional. After the discussion was over I managed to find some spare time to reflect on it: Does it matter how many test cases are there to test a particular application?
First, a bit of theoretical background
Well, this is something we all know. According to the ISTQB foundation level text (which is, by the way, can be considered as a comprehensive handbook for a test engineer) and IEEE829 Test Documentation Standard, test cases are stemmed out as a part of test design and documentation procedures.
Given a software system to test, the test engineers first analyze the system specification to find test conditions - which in simple terms, are things that could be tested. Once the engineers are satisfied that they have found a good amount of conditions that covers the system's functional and non-functional aspects (which is named as 'Test Oracle'), they select which of these to be actually used for testing and prioritize them based on importance and risk levels assigned to each one.
Then comes the test cases - they are the detailed specification on how one or more test conditions are actually tested. A pre-determined set of pre-conditions, inputs, steps to follow and expected outputs are documented as a test case which resides in a formal test specification.
On top of these, test procedures are also documented to specify how the test cases should be executed. In case test automation comes in to the picture, the procedures may extend to automation scripts etc.
But the most important point is, no matter how these standards and 'conventional ways of doing it' are set, when it comes to the point where you find yourself actually doing the thing, it all depends on several different things.
[To read the complete article visit blog.zone24x7.com/testcases]
[To read the complete article visit blog.zone24x7.com/testcases]
