- cases - Test cases may build on each other. For example, the first test case exercises a particular feature of the software and then leaves the system in a state such that the second test case can be executed. In testing a database consider these test cases:
- Create a record
- Read the record
- Update the record
- Read the record
- Delete the record
- Read the deleted record
Each of these tests could be built on the previous tests. The advantage is that each test case is typically smaller and simpler. The disadvantage is that if one test fails, the subsequent tests may be invalid.
- Independent test cases - Each test case is entirely self contained. Tests do not build on each other or require that other tests have been successfully executed. The advantage is that any number of tests can be executed in any order. The disadvantage is that each test tends to be larger and more complex and thus more difficult to design, create, and maintain.
As Lee mentions about this book that, “It does, however, contain techniques that will make you more efficient and effective in your testing by helping you choose and construct test cases that will find substantially more defects than you have in the past while using fewer resources.”
The book takes us to understand various test designing techniques that are explained with number of good examples, which makes the reading interesting and an experience. The book is a ‘must_read’ for all test professionals.
Ross Collard about Good Test case
Apart from the generic discussion that one normally finds in books and articles in test case design, Ross discusses a few practical problems of test teams that affect test design time and again. I have highlighted some of the examples below to keep this reference narrowly focused on only those variations.
In his forthcoming book, Developing Software Test Cases, Ross defines test case as,
“A test case exercises one particular situation or a condition of the system being tested.”
He thinks that the purpose of the test cases is,
“A test case describes what to test and how and provides direction to the person (or to automated test tool), which perform testing. The direction includes how to set up and execute the test case, what behaviors to monitor and how to evaluate the results.”
After a detailed discussion about test case structure- test condition, test procedure, test results and test environment, he says,
“there is no standard or correct way to document the test cases. Multiple projects will use multiple formats, or a project will use multiple formats. Such variation is justified when test cases need different information or it might be just due to lack of coordination in test teams, which is often the case.”
Then Ross brings out a very interesting discussion about the level of details that a test case may have versus the experienced test team and non-experienced test team, who will be executing the test cases. Then he brings out another important aspect of good test design and test cases- collaboration of insiders and outsiders. According to him, the insiders have usually a very good knowledge of the system under test and they can develop better quality tests from this perspective however, they lack detachment from development team and hence they may lose the advantages of this good design by sheer mismatches due to human relationship dynamics and losing the objectivity of the project.
Whereas, though the outsiders have less knowledge of the