Extracting Testable Conditions
Following on from Part 1, a large part of Specifications Analysis is extracting Testable Conditions, so now we will look at how to do that.
In order to ensure a quality product, every function that the product carries out must be testable. That is to say, if a product is supposed to do x, y, and z, then in order to determine that it does do x, y, and z, it must be possible to test that it does indeed do x, y, and z.
This is why it is so imperative that the Specifications should be specific rather than vague.
If the Specification says the product will do "x", then it must do "x". Whatever "x" is, it must be clearly defined. When "x" is clearly defined, it is possible for the Developer to develop the product so that it does "x", and it is possible for the Tester to confirm that the product does "x".
Does the product do "x" is therefore a Testable Condition. A Testable Condition is a black and white scenario. Either the product does "x", or it does not do "x".
So when you are analysing the Specifications to produce Testable Conditions, you are looking for everything that can be resolved to a black and white scenario.
To the extent that you are able to do this, the Specification is clear and specific.
Conversely, to the extent that you are not able to do this, the Specification is unclear and not specific.
There are different ways of ways of determining whether you have extracted all the conditions. One is to number everything. Another is to use coloured highlighting pens.
Wherever there are gaps (numerical or uncoloured), you will need to get clarification from the BA.
This is a matter of going through the document for as many times as it takes to get everything in it to be testable.
By the time you have finished, you will have a set of Testable Conditions - you now have to fit these Testable Conditions into your Test Cases.
