One of the common statements in software testing that I come across is “Domain knowledge is critical to testing the functionality”. The belief is that knowledge of the domain acquired from prior experience is very necessary to perform good functional testing. Not that I disagree, because a prior experience is always handy. But the key question is ‘What if I am encountering a functionality for the first time? Will I be effective?’. Wouldn’t it be nice to be able to do this using a set of techniques in a scientific manner?
Let us first examine the basics… The objective of functional testing is to ascertain if the behavior of the entity under test (EUT) is as intended. So what is behavior? When we tell an unruly kid “Behave yourself”, what we mean is ’please comply with the acceptable norms i.e. rules’. Hence behavior of an EUT is about ’obeying some rules’. These ’rules’ are really the specification. So to test a functionality of any EUT, we need to first understand the intended rules and then create scenarios that are really various behaviors by combining the rules in different ways and then check the outcome(s).
So how do we figure out the rules? Hmmm… If I had domain knowledge then I would know how this should work, and therefore the rules. Note that this can be dangerous too as this sets up a bias, and we may assume certain rules that may be incorrect. Anyways, the issue is, how otherwise? To understand the intended behavior, first, describe what the EUT is supposed to do. Describe the behavior as a series of steps. Each step accepts/uses data and processes the data according to some condition(s). Examine each step and extract the condition(s) hidden in the step. Voila… We now have the various conditions aka rules.
This technique of extracting conditions (aka rules) is what I call “Descriptive to Prescriptive”, that is converting the descriptive specification to a prescriptive specification. “Describing” enables us to understand the behavior from first principles while “Prescribing” helps us to validate the behavior. We all know that clear and comprehensive description consists of the 5W+1H – Who, What, When, Where, Why & How. So when you encounter a functionality for the first time, apply 5W1H and describe the behavior as a series of simple steps.
Now examine each step and identify conditions implicitly or explicitly present. Once the conditions are extracted from each step, re-write each step as a series of rules and what we have now is prescriptive behavior. From this, it is easier to create the test scenarios and then identify the various data sets for each scenario and subsequently generate test cases and therefore for the entire EUT.
This behavior-based approach to functional test design is implemented by two techniques ’Box Model’ and ’Behaviour-Stimuli Approach’ in HBT (Hypothesis Based Testing). This lessens the need for domain knowledge as a prerequisite by enabling you to question better to understand behavior, and then extracting conditions to test effectively. Click here to read some articles on this from hbtcentral.org.
So whether you test a technical feature or a business flow try this approach. Be the doctor – “Ask the patient to describe so that can you can prescribe”. Enjoy the happiness that comes out of the cure.
May you contribute to healthy software and a cleaner world.
If you find the article interesting, please ‘like’, ‘share’ or leave a comment below.