from user stories to automated tests.
Insight for: QA-engineers, Project Managers
The Samurai philosophy can be applied to automated test development, as automation should not be the goal but a means to achieve high product quality and meet user needs.
The samurai code states that "a samurai has no goal, only a path." This means that following a designated path with strict adherence to rules will lead to goal achievement.
"Tests for the sake of tests" is a disastrous situation caused by positioning automated tests as the main goal.
Automation is one of the checkpoints on a QA samurai’s path. And this path should be guided by standards and best practices, which can be considered as artifacts.
The user's needs and expectations (in the broadest sense of the word) are the starting point of the path. It is meaningless to move forward until this "location" is thoroughly explored.
Here, it is important to find answers to the most complex existential questions: "Who am I? What do I want? Why is this necessary?". A deep analysis, philosophy, and contemplation of meaning. Pure East!
The main treasures that one must take from the starting point of the journey are formulated as follows: As a [description of user], I want [functionality] so that [benefit].
As a user, I want to be able to register on the website to access additional features.
As a user, I want to be able to reset my password so that I don't lose access to my account.
As a user, I want to be able to leave a review about a product to help other users make the right choice.
If the first point is important to capture desires without asking how to achieve them, the second "location" will solve practical issues.
What exactly needs to be done to get what you want, and how the system should respond to these steps?
And, as we all know, there are always several ways to achieve what you want. It is important to record all options, each of which must be presented in the form of clear sequential steps and reactions to them.
The further the journey, the heavier the burden. It is extremely important here to carefully consider and indicate which Use Cases will bring greater benefits, and which are more backup. Example:
Registration
As a user, I want to be able to register on the website to access additional features.
Prio 1: e-mail registration
Prio 1: via Facebook
Prio 1: via phone number
Prio 2: Twitter
Prio 2: LinkedIn.
Now that it is crystal clear what we are fighting for, it's time to enter the real battle. Numerous Test Cases are deployed under the leadership of a QA samurai to defend each Use Case, which includes both positive and negative scenarios. Everything is aimed at ensuring that the requirements are met. Example:
As a user, I want to be able to register on the website to access additional features.
Registration
Email registration
Test case : Checking mandatory fields during registration
Test case : Checking password confirmation
The development process is relentless, and resources are always strictly limited. It is necessary to build a strong defense to hold the line. Prioritizing Test Cases allows us to distribute efforts, accurately identifying what needs to be tested and automated first.
As a user, I want to be able to register on the website to access additional features.
Registration
Email registration
Prio 1 / Test case 1: Registration with correct data (Autotest)
Prio 2 / Test case 2: Checking mandatory fields during registration (Manual)
Prio 1 / Test case 3: Checking password confirmation (Manual)
The concept of "inevitable goal achievement" finally gets its embodiment in an Autotest.
Obviously, product testing is a continuous process, and our QA samurai must always be ready for new challenges. They will have to return to familiar artifacts, analyze them, and make changes if needed. But the traveled path will allow us to confidently state that the value is indisputable, the way to achieve it is evident, the control method is correct, and automation (and resources spent on it) is justified.
We keep our finger on the pulse, and we do it automatically!
