The process of understanding requirements, and subsequently confirming understanding by writing the tests, is one that mirrors the counselling process.
The counsellor, much like the Tester, builds a relationship with the ‘client’ (who may be a single user or group of users, stakeholders or business analysts) and together they assess the problem. The aim then is to set goals or targets for change and to define what MUST happen as a result of one specific ACTION or EVENT. For the Tester these goals form the requirements. Usually the testing starts with the written requirements, but these may be in the process of being clarified, expanded upon or finalised, or as often happens when you get them they are already signed off.
In the process of analysis, each requirement is broken down into a series of simple statements that explicitly define what the resulting software MUST do in response to a specific event or action by the user. The job of the Tester is to ensure that the software adheres to these rules [but also continues to adhere to existing rules without conflict]. The Tester also helps discover situations where the software MUST adhere to the converse rule or variations of the rule, by considering the exceptions to the rule. Each component of a requirement is essentially a statement with a ‘MUST‘ at the centre of it. Each test for that MUST is a statement that begins ‘ENSURE that…’ where the rules are applied appropriately for precise situations, or a variety of cases, and always applied in a defined order.
Intervention by the Foxy Tester and the Counsellor is wielded in the form of insightful questions that help reveal the possible scenarios or ‘Ah-ha’ moments. Here the Tester must think laterally and ask ‘WHAT IF?’ this or what if that. Questions that challenge every aspect of the requirement. With the help of the users the Tester can outline the types of scenarios to consider. A Tester must wear every kind of hat, in consideration of every viewpoint he can think of. He/she must consider the current situations that may exist and ask: How will this or that situation, along with any existing data, be impacted by the proposed requirements? The Tester with the user’s help then explores how each scenario MUST be responded to by the EVENT or user ACTION. A counsellor may take a more challenging approach dependent upon the level of resistance to change and severity of the problem.
For the Tester, every ‘MUST’ within a requirement can yield one or perhaps many ‘ENSURE’ statements that outline the tests. For each test the Tester considers the pre-existing state or states. The state defines what must exist or have already happened prior to the specified test action or event. This is the ‘GIVEN’. Although it’s not always ‘a given’. Here again there may be many variations to consider. The GIVEN can include any complicated scenario that can pre-exist: that CAN, MUST or possibly SHOULD NOT permit the user ACTION or EVENT when under scrutiny of the test. Although the number of combinations may seem endless, they can be grouped into CLASSES that are similar enough to be considered EQUIVALENT.
Finally, reviewing the tests, and running them against the developed software mirrors the counsellor ‘s Evaluation, whilst the resulting outcomes is Referral and Termination. Whether the termination results in waiting for a bug fix before repeating tests, or confirmation that the Tester has ENSURED that the required MUSTS are correctly applied. For the counsellor and the Tester the outcome may also be one of, ‘wash, rinse, repeat ‘ until done.