According to the processes or software development methodologies, a certain number of test artifacts (documents, models, etc.) are created and used during the testing.

Today we will study the test case and test suite.

Test Case

The Test Case is an artifact that describes the totality of steps, the specific conditions and parameters required to test the implementation of a function or part of it.
A test case is a structure of the form:

Action> Expected Result> Test Result

Example:

Types of Test Cases
Test cases are divided according to the expected result in positive and negative ones:

• A positive test case uses only the correct data and verifies that the application has correctly performed the called function.
• A negative test case operates both correct and incorrect data (at least 1 incorrect parameter) and aims to check for exceptional situations (activation of validators), and also check that the function called by the application is not executed when the validator is triggered.

Test Case Structure
On the Internet, you can find a lot of information about the structure of the test cases, the level of their details and the number of checks in them, I’m going to talk about the approach I use, and I want to suggest using it to you.

Each test case must have 3 parts:

Note: Post Conditions is optional. This is most likely a rule of good form: “messed up – clean up”. This is especially true for automated testing, when in one run you can fill a database with hundreds or even thousands of incorrect documents.

Case study example:

do A1, verify B1

do A2, verify B2

do A3, verify B3

In this example, the final test is B3. This means that it is the key one. Hence, A1 and A2 are actions leading the system into a testable state. A B1 and B2 – the conditions that the system is in a condition suitable for testing. Thus we have:

PostConditions in this example were not described, but according to the logic of things, you need to perform steps that would return the system to its original state. (for example, delete the created record, or cancel the changes made in the document)

Now we answer the question: “Why is this partition convenient to use?”

Answer: the final check is one, i.е. In case the test fails, it will be immediately clear why. Because if the checks B1 and / or B2 fail, then the test case will be blocked (test blocked), because the function can not be brought into a testable state (a condition suitable for testing), but this does not mean that the test function is not working.

Test Case Specification
There are many different opinions about the level of detail when writing test cases, as well as the number of checks in one test case. All of them are correct in their own way. My opinion is that the level of detail of the test cases should be such as to ensure a reasonable ratio of the passage time to the test coverage. Those. As long as the coverage of tests of certain functional does not change, you can reduce the detail of the test case.

Example test case 1:

Example test case 2:
Title: Checking the display of the page
Action: Open the “Login” page
Check: Check that the displayed page corresponds to the page in picture 1 (and attach the image of the page “Login”)

In example 1 and 2, the coverage will be the same, but the time that will be required for the passage will be different. It seems that the second example will be even clearer.

In addition, I want to say that the decision on the form of the test case and the details of its description is taken by the person responsible for its creation – Test Designer or Test Analyst with the necessary experience and who knows the test design not by hearsay and has to experience in the practical application of test design techniques. In many companies, this role is not singled out separately but is entrusted to ordinary testers, which in case of insufficient qualification can lead to the correspondence of case tests.

Summary

In conclusion, in order for the testing team to work together and not be distracted by the design of the test cases, everyone should have a single template or an approach to writing them. What we offer is the structure of PreConditions, Test Case Description, PostConditions, and it’s your own business to use it or create your own “bike”.