Think about what we do while cooking food to make it the best dish possible. We taste the food first, make necessary adjustments and add a few more ingredients, taste the food again, and repeat until the dish is how we want it.
This is just like building a product in any software development lifecycle. If you don’t taste the food before serving it—or test the software before rolling it out—there will be a risk that the quality isn’t up to your standards, and you’ll get a bad review that could affect repeat customers.
The person who is making the food is like a software developer—he already knows what he is making and has clear requirements. It may happen that the requirements get changed, even after planning and starting the development, like when a customer has special requests for the chef. When that happens, the developer or chef has to add or take away ingredients to fulfill the requirement.
Before asking someone else to taste the food, the chef can taste it himself, just like when the developer does unit and sanity tests before giving the software to the tester. He can then hand off the dish to the cook, or tester, for further adjustment based on their observations. In the case of a software tester, this would be conducting system tests, integration tests, and functional tests for the betterment of the software. The chef would use that feedback to improve the product. For example, after tasting the first round of the food, the chef can make practical decisions, like adding more water; include new requirements, like tossing in sugar or spices; fix defects, like cooking the meat longer; or include additional nonfunctional elements for customer satisfaction, like garnishing the food or plating it in a more appealing way.
Of course, based on the individual, feedback might be different. Having only one person taste the dish does not ensure food quality is superior for all restaurant patrons. Multiple tastings are required for giving a better chance of serving quality food. It’s the same for software testing: Multiple testers give you a better shot at a quality software product.
But even with tons of different testers, all of whom are trying to keep the users’ interests in mind, some users will still have different tastes—just like some restaurant customers love a lot of salt or can't tolerate any heat. If that’s the case, the patron will send back the dish with requests for changes. This is like user acceptance testing in software. Feedback from actual users is very important to improve the overall performance of your product.
Additionally, depending on the customer’s geographic location, feedback may be totally different. You may need to update the requirements based on location, like for diet restrictions or flavor preferences. For software, this is like language testing, adherence to region-specific rules, or legal compliance testing.
Serving the food in the restaurant is like getting real user experience in production. Take note of all the feedback, make necessary adjustments to the requirements, and think about how you can implement the suggestions. This is also similar to user acceptance testing. Listening to those responses will help you create fantastic food in the future.
Concepts of automation are also applicable for making food, such as using a microwave, mixer, grinder, or ready-made spices to speed up the cooking process, just as automated testing assists in test phases and speeds up delivery. Similarly, inviting restaurant employees to try a new dish before putting it on the menu is like alpha or beta testing, where we get customer feedback prior to launch to gauge product quality and improve the overall performance. And while making the food, there are certain safety standards to follow, such as checking expiration dates, adequate food storage, and cooking to the proper temperature. This can be applied to software testing also, where we use checklists to ensure quality, performance, and security standards.
Even the process for cooking good food and developing quality software is similar. Think about traditional waterfall methodologies and modern agile methodologies. Like in waterfall, you can wait to taste the food until the end of the cooking, or tasting can be started as early as possible, so you try each element of the dish as you go along and then taste the final product. Continuous tasting makes the food better, and continuous testing makes the software product better.
The process of cooking food is a lot like the software development process. In both cases, we need to go through a series of steps. Collaboration between the chefs and cooks is like the collaboration between the development and testing teams. They need to work together to build a quality product for their customer, whether that’s quality software or tasty food. Tasting the product as you cook your food is like testing the product as it goes through the software development lifecycle: early and frequent checks ensure a quality end-product.
It would seem that tasting and testing have a lot in common. Let’s use this recipe to cook up some good software.