Specifying Test Cases

When we come to make a test case, we are required to be very specific; in fact we now need exact and detailed specific inputs, not general descriptions. 

Note that one test case covers a number of conditions. A test case needs to have input values, of course, but just having some values to input to the system is not a test! If you don't know what the system is supposed to do with the inputs, you can't tell whether your test has

passed or failed.

Should these detailed test cases be written down? Note that the contents described in the standard don't all have to be separate physical documents. But the standard's list of what needs to be kept track of is a good starting point, even if the test conditions and test cases for a given functionality or feature are all kept in one physical document.

One of the most important aspects of a test is that it assesses that the system does what it is supposed to do. 

In order to know what the system should do, we need to have a source of information about the correct behavior of the system - this is called an 'oracle' or a test oracle. 

Once a given input value has been chosen, the tester needs to determine what the expected result of entering that input would be and document it as part of the test case. 

Expected results include information displayed on a screen in response to an input, but they also include changes to data and/or states, and any other conse-quences of the test.

What if we don't decide on the expected results before we run a test? We can still look at what the system produces and would probably notice if something was wildly wrong. However, we would probably not notice small differences in calculations, or results that seemed to look OK (i.e. are plausible).

The test case should also say why it exists - i.e. the objective of the test it is part of or the test conditions that it is exercising (traceability).

Test cases can now be prioritized so that the most important test cases are executed first, and low priority test cases are executed later, or even not executed at all.

This may reflect the priorities already established for test conditions or the priority may be determined by other factors related to the specific test cases, such as a specific input value that has proved troublesome in the past, the risk associated with the test, or the most sensible sequence of running the tests.

Test cases need to be detailed so that we can accurately check the results and know that we have exactly the right response from the system. If tests are to be automated, the testing tool needs to know exactly what to compare the system output to.