TESTING IS LIKE COOKING

Testing a Software is very similar to cooking, according to me being a cooking lover though 😇

I’m not an expert in cooking, but I do know some things about cooking:

• there exist different cuisines
• some dishes are famous only in certain areas
• some dishes need more time to cook, some can be done in minutes
• the correct proportion of salt is a must thing in every dish that we cook

All the above points need to be considered in order to cook a proper dish. To better relate the testing concept with cooking let’s consider an example: Cooking a Biryani.

• the foremost important thing to be checked for is the rice variety that you choose for preparing the Briyani. Briyani goes best with Basmati Rice, many out there would agree with me.
• another fact is you need a proper place to cook the Biryani.
• there's also an important point of the rice to be cooked only 80 percent before giving it a dum.
• there's also a need for a proper vessel to cook the Biryani, so it requires a wide thick bottom vessel.

These facts make me relate to an acronym: BELT, for Bait, Equipment, Location, and Timing (Read in an article online). Let’s use this in our later points.

All the above conditions have to be met in order to prepare a delicious yummy Biryani. If even one goes wrong, there would be a major mis in Briyani that was expected...

In the same sense, when you begin to find for a bug, consider the below points:-

• not all bugs are the same there exist different varieties of bugs. What kind do you want to find?
• you can’t find a bug everywhere. Where are you looking for bugs? 
• some bugs only exist at particular times. Are you looking at the right time?
• some bugs won’t reveal their presence unless you provide the right stimulus. Are you using the right tools and data for the job? 

So back to the BELT acronym that I mentioned before - Bait, Equipment, Location, and Timing. Let’s co-relate software testing to this acronym...

Let’s say the variety of bugs you’re looking for is a crash in a Web application. Crashes can be triggered when bad data is passed between functions, or if the application reads something wrong.

1. What would be the bait in this case? Does the application read data in from the command line? A file? A database? A network?
2. What would be the equipment? What tools will you use to assist in finding this bug? 
3. Where would an ideal location be? Where would you expect to find this type of bug? At the application’s entry (such as initially reading a file), or deeper in the code (arguments passed between functions)? The approach would be different depending on where you’re cooking :-)
4. When would you expect to find these issues? Is there a particular time you might find a crash? Does your application behave differently at certain times of day, or when certain other events are happening?

The above questions will help you to a better approach to testing.

Hopefully, this has helped consider what kind of bug you’re looking for, and don’t forget your cooking BELT.

Happy Cooking!