The QA samurai's path: from user stories to automated tests

Artifact: User story

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].

Example:

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.

Usually, a story has its own acceptance criteria, which is the set of criterias a feature must meet to be considered complete. They can be presented in Given-When-Then, checklist, or other custom formats.

Simple example in the Given-When-Then format:

• Given — a user is on the registration page,
• When — they submit a unique email and a password,
• Then — the system creates a pending account and sends an activation email to the user’s email.

Acceptance criteria should cover not only the happy path but also all alternative flows.

Artifact: Test case

The importance of test design becomes clear when the team starts discussing how a user will actually interact with the system. A user story tells us what the user wants, while test cases show how they can get there.

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 acceptance criterion, which covers both positive and negative scenarios. Everything is aimed at ensuring that the requirements are met. We need to consider and include edge cases in our tests.

Good test case attributes make a test easy to understand, repeat, and maintain. At a minimum, a test case should have a clear verification point, defined preconditions, specific steps, and an expected result.

Test case: Registration with correct data

Preconditions:

1. The test email is not already registered
2. A mail sandbox is active

Steps:

1. Open the website’s registration page.
2. Fill in the “Name” and “Surname” fields.
3. Enter the email address from preconditions in the “Email” field.
4. Enter a password that meets the password policy (min 8 characters, at least one uppercase, one lowercase, one digit, and one special character) in the “Password” field.
5. Click the “Register” button.

Expected result: A notification about successful registration is displayed with the text: “Registration finished! We’ve sent an activation link to your email. Please check your inbox and activate your account.”

Artifact: Prioritized list of test cases

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. We need to proceed with a smoke test, including the most essential checks first, and then proceed to the rest.

User story:

As a user, I want to be able to register on the website to access additional features.

Example test cases

Smoke tests

• Registration with correct data
• Verification email sending
• Account activation via a valid link
• Access to additional features granted after activation

Critical path tests 

• Registration with empty fields
• Registration with an invalid email format
• Registration with a password that does not meet the requirements
• Registration with an already registered email
• Resending the verification email

Extended tests

• Activation link reusing after the account is already active
• Account activation via the expired email verification link
• Registration attempt with a duplicate email while the first account is still pending

Having designed test cases, we can select the ones for automation according to their priorities. Also, we should take into account the following points: frequency of runs, cost of automated run in comparison to manual one. Usually, the best candidates for automation are repetitive test cases covering business-critical scenarios and included in regression testing.

Artifact: Automated test

Now — after requirements analysis, test design, and test case prioritization — automation is justified and can be implemented.

The concept of “inevitable goal achievement” finally finds its final form in an autotest, demonstrating the importance of test automation in a structured QA process. We can now run these tests on a regular basis to ensure quality and minimize manual testing effort. Autotests can be automatically run on every code push, after deployment, or during the regression phase.

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 path they have traveled will allow us to confidently state that the value is indisputable, the way to achieve it is evident, the verification approach is correct, and automation (and resources spent on it) is justified.

We keep our finger on the pulse, and we do it automatically!