Deep dive is about going deeper, by reading available spec, by exploring, and using information from past experiences to understand an entity. This is done rapidly with a sharp focus and a 360 vision in eight steps.
Good understanding of an entity, be it a small component/feature or big requirement/flow is key to testing it effectively & efficiently. It cannot be assumed that whatever information given as spec is complete. Give that we are always time challenged, how do we understand details of an entity, so that we can validate well? What would be a smart thing to do? Well, do a DEEP DIVE.
Deep dive is about great techniques, agility, speed, sharp focus on the objective and a 360 degree view. Much like when one dives deep (into ocean/sea) where time is limited and depths darker, it is necessary to rapidly dig in and ask questions to illuminate the depths and understand what an entity is doing/intended-to-do.
Deep dive is about going deeper by going through available spec, by exploring it, and using information from past experiences. The entity under consideration of the system under test may be a small sized component/feature or a larger requirement/flow.
What does it take to understand an entity smartly?
1. Describe succinctly
After going through a spec, exploring an entity, commence by describing succinctly as to what the entity is probably expected to do. Why succinctly? Because using least number of words to describe behaviour demands intense clarity of what-is-there/what-may-be-missing. It sharpens one’s thinking and helps stay focused. Read, explore and summarise tersely. This is the first step.
2. Understand inputs & outcomes
Be it a small component/feature or larger requirement/flow, the next step is is to figure out as to what it takes as inputs (could be simple granular inputs for small entities and higher level bigger blobs of information for larger ones) and what the intended outcomes may be. Note that this is not merely about understanding the outputs stated or those evident, it is about diving deeper to understand outputs, for intended behaviours or unintended.
In current times, there is a great emphasis on non-functional aspects. Step #3 is key to great user experience. A bigger picture of the system, a greater empathy for users is very useful to appreciate as to what attributes may be critical and need to be baked in.
4.Understand behaviour conditions & criteria
Now is the time to understand the conditions that govern functional behaviour. How does this help? Well a good behavioural model provides a framework for great test design. Note that conditions need not be limited to functionality only. Having understood the inputs and outcomes, understand what the acceptance criteria may be. So how are these criteria different from conditions? Well criteria is derived from outcomes while conditions are derived from inputs. Going forward and backward is very useful, being complementary.
5.Understand structural aspects
A mere black box view of entity is insufficient. It is necessary to get under the hood and appreciate how it is built. What is our code, what are other people’s code? What is new, what is modified? What are the layers, interfaces, connections? What are the challenges/constraints that may be imposed by environment, technology? How do these help? Well, these give us ideas to what structural aspects need to be examined, enabling us to refine the scenarios. Also, these can help in implementing good testability and also assist in automation.
6.Hypothesise potential issues
Using a mixture of logic & experience, hypothesise potential issues to go after. Identifying potential issues to go after, sharpens the purpose and forces us to think from ‘what-can-go-wrong’ mentality. Behaviour conditions help in coming up with scenarios from ‘forward’ direction , while criteria help in coming up with scenarios from the ‘backward’ direction, and potential issues/faults enables coming up with scenarios from the middle.
7.Understand who the end users are
Identify who the end users for this entity are to get a big picture view. This certainly is necessary for higher level entities like user requirements and business flow, as it enables a wholesome understanding of usage, and sharpens one’s appreciation of criticality of an entity to an end user. Note that an end user may be human and another machine.
An entity is never alone, understand how this entity is dependent on others. The correctness of an entity is not limited to a good implementation of what an entity should do/not-do, it is also about how it is not being affected by other entities so that it may be robust. It is also necessary than the entity is a ‘good citizen’ , implying that it does not affect adversely other entities in the system.
These eight steps may start off in this sequence, think of these as a dynamic process where we need to revise, revisit constantly to understand or list questions to clarify and therefore need to jump across to another step as needed.
Deep dive is not a splash, it is a smart way to understand deeply to design minimal yet sufficient scenarios & automate well.