Food is a necessity for humans, without its consumption on regular basis, arguably a human can survive but they cannot sustain their normal functions as they are supposed to. That is the basics of culinary know how which everyone understands.
On the other hand food is also a form of art, just like a masterpiece is created, a meal by a professional chef is an equal comparison to the artifact created by the same driven artist.
Cutting to the point, software applications are becoming a necessity for human beings, they are now part of their daily lives, and just like food, they are becoming trivial to their senses but in the absence, under so many contexts these same applications can cause hindrances to daily routines. We are not there yet but we are getting to this point – and we need to be ready.
Talking about food, one element that represents software application in a true form is a layered cake. Here is Wikipedia with a more mouthwatering definition:
“A layer cake (US English) or sandwich cake (UK English), also called a sandwich in UK English, is a cake consisting of multiple stacked sheets of cake, held together by frosting or another type of filling, such as jam or other preserves.”
Wow, isn’t it amazing, if we remove the word “”Cake” with “Software Application” the definition of this would become so much compatible with the applications we are now experiencing.
A system is formed on the basis of layers of architecture. If we place these layers horizontally then the top most layer with all the presentations, dressings, and those delicious cherries on top, represent the client facing side of the application. Whereas, the lower layers which are also the thickest ones, and balance all other layers on top, represent the complex hardware and database architectures, which obviously client does not experience at firsthand, but is aware of their importance.
While testing software applications, if software testers can draw and define these layers of the application and their consecutive touch-points, the consideration of finding important bugs at the right time can become a reality.
Testers should consider their approach first as a knife cutting the cake into several layered pieces, where the intersection reveals the layers intermingling with each other, the reason to do this is because the system does not have uniformity in connecting layers. For example, in some cases, the users may want to reach for the data directly as a lot of technical users of large systems like to jack up their reporting with access to databases and query writers. They don’t ask for support, they do it themselves.
Similarly, the presence of a third party application for data or process enhancement in between the users and database layers is another challenge to define coverage. The best example here is the presence of a CRM or a BI tool which actually works in between the application and users to enhance user experience journey.
CRM and BI have their own set of users, and this actually complicates the whole test execution process. The reason is the more enriched form of behavioral driven testing.
This is what most of the testers are unable to understand. This is why the test cases and test planning fails at various levels – because they can only act as a needle in the cake and not the knife.
The needle approach is good, but the BIG question is how many, where, when, and to what extent the needles need to be penetrated in the cake – this is something which is still un-digest-able for many test leads, managers, and testers.
The layered approach is to dissect and distribute the application so it is viewed as a blue print not as what users see. This way, the error which is not detected at the layer 1, is detectable at the layer “n”. Most of the time, testers remain shallow on the top layers as they have the pre-fabricated perception about the data being represented CORRECTLY from the last layer to the top most layer, and they forget the users, function calls, data commits and programming errors in between.
Practically, instead of writing hundreds of scenarios and cases, testers can identify layers, interacting objects, technology, and users. They can then identify the critical areas touching other areas, and thence make the complete element driven map of the product.
The coverage in this case is maximum, as all layers are visible. Testers can also keep a RISK clause within these layers and identify any reach-outpoints where there can be potential risks. For example, any area which is out of scope, but is also important under programmer perspective, OR any area which is not reachable such as a physical location OR the databases which only technology teams has access to.
Testing is about the discovery and learning, it is about experimenting and defining the coverage. Testing cannot be a scripted process. We can make so many scripts at a given time, but we will fail in defining the complete coverage – every time.
Happy Testing.
