How to create Test Cases?

Hi everyone! ??

Today, let's talk about something that seems so simple, but where many people make mistakes...

?? Question: How do you write test cases?

?? Short answer: As simple as possible.

Long answer:

?? How a CORRECT test case template looks: ID -> Priority -> Title -> Preconditions (optional) -> Steps -> Expected Result. And I think most of you would agree with this format, BUT...

I very often get messages or requests for help from people whose test case format differs: ID -> Priority -> Title -> Preconditions (optional) -> Steps + Expected Result after each step. As a result, your test cases lack a clear "Expected Result" and there's no clear understanding of what you should ultimately check. I have no idea where this format came from, although there are tons of examples like this in English-language sources!

If we take the ISTQB, which I hate so much, even it doesn't have this format, and they advocate for the first, CORRECT template... I also checked this with Gemini, and like ISTQB, it confirmed the CORRECT template ??

?? Disadvantages:

• You check +100500 times what you've already checked in other test cases.
• Each step has an Expected Result (ER) that is not relevant to the test case.
• The ER is duplicated in hundreds of test cases.
• The test case does not have a clear ER.
• The test title does not describe the ER because there isn't one.
• Such test cases are not applicable for automation.

Advantages:

• There are none.

?? Automation: In automation, people don't write ERs (checks) in every step because tests should be as atomic and small as possible. Yes, there are also large tests, but their steps serve to get you to the "last step" where you will do the checks. Therefore, in automation, API and other life hacks are often used to "shorten" this path. It turns out that we have hundreds of tests that already check all this anyway, and if something goes wrong at some step, your test will simply fail with an error at that step.

Conclusion: Note that the CORRECT test case template 146% satisfies the requirements of automation. In addition, you save a lot of time when writing such test cases because duplication is significantly reduced. And of course, when testing, you spend less time because you don't check the same things 100500 times in every test.

?????Best practices:?In addition to problems with the template, people make other mistakes that complicate or hinder verification.

• Many small test cases are normal.
• Checks should correspond to the last step and the test title.
• When you write "the field contains the text" or "the color has changed", you should specify what text and what color (if required or not obvious).
• Try to include a link to the design and documentation if required for verification.

?? Here are two examples from Gemini - as they say, "spot the difference":

(imagine these steps being repeated from test case to test case)

#1

D: TC_001
Priority: High
Title: Successful login with valid credentials
Precondition: The user is registered in the system.

Steps:
- Open the login page.
- Enter a valid username in the "Username" field.
- Enter a valid password in the "Password" field.
- Click the "Login" button. (Or "Sign In", "Enter"). 

Expected Result: The user is successfully authenticated and redirected to the main page (or home page).        

#2

Test Case 1:
ID: TC_001
Priority: High
Title: Successful Login with Valid Credentials
Precondition: The user is registered in the system.

Step 1: Open the login page.
Expected Result 1: The login page loads successfully, displaying the "Username" (or "Login") and "Password" fields, and the "Login" (or "Sign In") button.

Step 2: Enter a valid username in the "Username" field.
Expected Result 2: The entered username is displayed in the "Username" field.

Step 3: Enter a valid password in the "Password" field.
Expected Result 3: The entered password characters are displayed in the "Password" field (typically as asterisks or dots).

Step 4: Click the "Login" button.
Expected Result 4: The user is successfully authenticated and redirected to the main page (or home page).        

???♀? From experience: When I worked at Yandex and Mail (VK) on a project with tens of millions of users, we didn't have a SINGLE test case. Only when we started hiring many people for testing did CHECKLISTS start to appear, but still, no one wasted time on test cases.

Therefore, I don't recommend wasting time on test cases at all. Most systems are completely trivial, and you'll have no trouble testing them with documentation and design at hand. However, if you have one of these cases — "test cases are specifically required" / "you have high turnover" / "you hire a lot of juniors" / "really complex logic" — then you have no choice, although I would still write CHECKLISTS rather than test cases.

?? Links:

Test Cases: https://www.rst.software/blog/software-tester-how-to-create-test-cases