The Samurai's Blade: A Story of Automation Testing
The Samurai's Blade: A Story of Automation Testing
Before we define automation testing, let's take a journey.
Imagine you are walking through the misty hill stations of Japan. You notice the situation is dire. Thieves plague the streets, and the people are afraid. Suddenly, heavy winds whip through the valley, and a piece of paper slams against your face. You peel it off and see it’s a warning alert: the city's commander is sending samurai to control the thieves' actions.
The next day, you walk through the blacksmiths' street, where the famous katanas are born. A samurai, his face stern, brushes past you and enters a shop. He addresses the master blacksmith: "I need 100 katanas by next week."
He passes over a scroll detailing the requirements. "The commander has specific needs. It must be lightweight, yet able to pierce metal. Its strike should resemble thunder, and it must withstand heavy damage. The commander's personal blade must have a red sandalwood handle; the rest can be normal."
In software terminology, we call this the Customer Requirement Specifications (CRS).
The old blacksmith—a true Product Manager (and domain expert)—knew this was a challenge. He called his assistants: Roger and his team, the master Developers (the katana makers), and Jessie and her team, the meticulous Testers.
The First Blade
Roger was a genius in his work. He claimed he could build all 100 katanas in three days. But the old blacksmith, now acting as the Scrum Master, knew the risk. What if they didn't match the commander's requirements? They would have to start over.
"We will use a new plan," the blacksmith declared. "First, we build one basic katana. We will build it one feature at a time, and we will get feedback and approval from the commander's assistant."
This iterative approach is what we now call Agile Methodology.
The old blacksmith assigned tasks, asking each team to complete their portion within one day. Roger’s team forged the first blade, working tirelessly. As they finished, Jessie approached.
"Roger, what did you build? Let me check if it's working properly." This, in essence, is Testing.
Roger, bristling with the arrogance of his 30+ years of experience, asked, "Why test my work?"
Jessie replied politely, "I trust your work, master. But this isn't just about your expertise. We must impress the commander. To do that, we must ensure we are perfectly matching every requirement he gave us. That is why I am checking."
From Manual to Automated
To test the katana, Jessie's team began. They took the blade and had assistants perform separate checks: a strength check by striking wood, a sharpness test by piercing a target, a durability test, and so on.
But Jessie's team members were not expert swordsmen. Using the blade manually was dangerous, slow, and inconsistent. They needed a better way.
They came up with a plan: build a dummy human and tie the katana to it. They arranged a track where wood bars, bundles of grass, and steel plates would come toward the dummy. When an object approached, the dummy would automatically strike it with the katana.
This mechanism, executing all the tests one after another through a repeatable process, was their first act of Automation Testing.
The Demonstration
In the evening, the commander himself arrived. The old blacksmith presented the single, perfected katana. This was their Sprint Review—a stakeholder demo.
"Oh, Lord," the blacksmith said, "please check this katana with your own hands."
The commander took a deep look, noting the red sandalwood handle. "I like it," he murmured. Then, in a blur, he struck down all the wooden dummies in the courtyard.
He turned, a smile on his face. "Master, this katana is a piece of art. I am happy with your work. I am appointing you the Master of Katana for this valley. Continue this work and deliver the remaining katanas on time."
Success. The combination of expert development (Roger) and rigorous, automated validation (Jessie) delivered a product that met every requirement, satisfied the customer, and ensured quality at scale.
Technical Notes & Definitions
As promised, here are the professional definitions for the terms used in our story:
Testing: The process of evaluating a software application to identify any gaps, errors, or missing requirements contrary to the actual requirements. Its purpose is to verify and validate that the product works as expected. (Jessie's team checking the katana manually).
Automation Testing: A software testing technique that uses special automated testing software tools to execute a test case suite. The automation software enters test data, compares expected and actual results, and generates detailed test reports. (Jessie's team building the "dummy" to run the tests automatically).
Customer Requirement Specifications (CRS): A formal document detailing all requirements, features, and constraints for a software product. It serves as the "source of truth." (The samurai's list of demands for the katana).
Product Manager: The person responsible for defining the "why," "what," and "when" of a product. They own the product vision and are the voice of the customer. (The old blacksmith, who understood the commander's needs).
Developer vs. Tester: The Developer (Roger) is responsible for building and creating the product. The Tester (Jessie) is responsible for verifying the product's quality.
Agile Methodology: A project management approach where projects are broken down into smaller, iterative cycles called "sprints." It emphasizes flexibility, customer feedback, and rapid delivery. (The blacksmith's plan to build one katana first).
Scrum Master: A facilitator for an Agile development team, responsible for ensuring the team follows Agile practices and removing impediments. (The old blacksmith, who managed the process).
Sprint Review: A meeting at the end of a sprint where the team demonstrates the completed work to the product owner and stakeholders (the customer). (The evening demonstration for the commander).
Comments
Post a Comment