What is Test Case?

A test case (TC) is an artifact that describes a set of steps, specific conditions, and parameters needed to test the implementation of a function or part of it.
A TC should contain the following:

Action > Expected Result > Test Result

Example of Positive Test Case:

Action	Expected Result	Actual Result	Result
Open Login Page	Login page is opened.	Login Page is opened in Chrome.	PASS

Type of Test Cases

TCs are divided according to the expected result into positive and negative:

Positive test case uses only valid data and verifies that the application correctly executed the called function.
Negative TC operates on both valid and invalid data (minimum 1 invalid parameter) and aims to check for exceptions (validators fire), and also checks that the function called by the application is not executed when the validator fires.

Test Case Structure

On the Internet, you can find a lot of information about the structure of TCs, the level of detail, and the number of checks in them; I’m going to talk about the approach I use and which I want to suggest you use.

Each TC should have 3 parts:

Pre-conditions: A list of actions that bring the system into a state suitable for a basic check. Or a list of conditions, the fulfillment of which indicates that the system is in a state suitable for conducting the main test.
TC Description: A list of actions that transfer the system from one state to another, to obtain a result, based on which it can be concluded that the implementation meets the requirements
Post-conditions: List of actions that bring the system to its initial state (the state before the test is performed – initial state)
Note: Post Conditions is optional. This is most likely – the rule of good form: “littered – clean up after yourself.” This is especially true for automated testing, when one run can fill the database with hundreds or even a thousand incorrect documents.

Detailing the description of test cases

There are many different opinions about the level of detail when writing test cases, as well as the number of checks in one TC. All of them are correct in their own way. It is my opinion that the level of detail of TCs should be such as to provide a reasonable ratio of transit time to test coverage. Those. as long as the coverage of certain functionality by tests does not change, you can reduce the detail of TCs.

Positive TC Example:

Step #	Action	Expected Result	Actual Result	Test Result
1.	Open Login Page	Page is opened successfully.	Page is opened successfully.	PASS
2.	Enter Email and Password	No errors are displayed.	No errors are displayed.	PASS
3.	Click Login	User is logged in.	User is logged in.	PASS
4.	Click Logout	User is logged out.	User is logged out.	PASS

Negative TC Example:

Step #	Action	Expected Result	Actual Result	Test Result
1.	Open Login Page	Page is opened successfully.	Page is opened successfully.	PASS
2.	Enter Incorrect Email and Password	No errors are displayed.	No errors are displayed.	PASS
3.	Click Login	User is logged in.	User is not logged in. Wrong Email/Password error displayed	FAIL