Test cases are an integral part of the testing process. But how can one write good test cases? They are used to verify that when a software application is being tested when it comes in contact with input, the output is what is expected.

The test cases are executed by a tester. The tester should have enough knowledge about the software being tested so that he/she can identify the prerequisites that are needed to proceed with the execution of the test cases.

Having sufficient knowledge is key because it saves time, effort and money for both the individuals executing the test cases and also for teams who have to write test cases.

This information can help them know what value each hypothesis they write should have so that they don’t waste time implementing solutions not applicable or not suited for their use case.

Prerequisites are to be satisfied before the test case can be executed.

A test case generally has two parts:

1) Inputs

They describe what should happen when they are given different inputs – these will be given in different combinations to see if they produce the correct output. For example, one input might be “One plus One” and another input might be “2 minus 1”. These inputs would be combined with all other possible inputs to see which ones produce the desired results.

2) Outputs

Outputs describe what an application should produce when given a certain input. For example, if the input is “One plus One” the expected output would be “Two”.

Most Test cases are generally created or written by Quality Assurance/Quality Control (QA/QC) testers.

However, programmers also document test cases for themselves to ensure that they are testing each part of their application.

Tips to write good test cases

1) Avoid test repetition

it is difficult to determine if you have covered all possible input combinations or not. It is even harder to determine if a program has worked properly for each scenario.

2) Verify the application works properly under different conditions

This helps ensure that your application will work properly after a change has been made to it. For example, if a calculator is being tested and the programmer implements a new feature that doesn’t work as intended, the users of that calculator can check whether it works as expected or not by running tests created before and after the change was implemented, this is known as regression testing – see more here.

3) Have someone else read your test cases(peer reviews)

Peer reviews help to catch errors in logical thinking as well as typos that may have been introduced when writing test cases manually.

4) Consider a test-driven development approach

This allows the test cases to be created by developers so that they can create a complete set of test cases for a demo/prototype rather than manually creating all the scenarios the software has to be tested against.

5) Tests should be simple and easy to understand.

6) Tests should be easily identified by the title

Avoid writing vague titles like “Test for Input” or “Test for Output 2”. Keep in mind that your goal is to communicate what the test case does to the reader in the most concise manner possible.

7) Never assume any test scenarios

User stories, acceptance criteria or use cases should be written to describe expectations of the application. Do not write test cases without considering these as they can lead to you executing incorrect tests. Covered by other tests is a good Cucumber term, i.e., this scenario covers all those scenarios which are already written in the past.

8) Create a standard testing template for the team to follow

It’s very useful as it can help keep the team members consistent in their test cases by following a format that works for the entire team.

Good Test Cases are the foundation that is used to create proper test plans, i.e., test cases are used to decide what should be present in the test plan, therefore creating a good plan is essential for maintaining high-quality software.

Good tests cover all functionalities that are required for the application being tested and ensure that these applications implement all necessary functions.

A proper testing plan should contain Minimum Viable Product (MVP), User Acceptance Testing (UAT) and User Acceptance Testing with Regression Testing (UAT+R).

Best practice to write good test cases:
1) In most cases, Test cases should be written against the requirements and not against the design.

Let’s take a look at some examples of good and bad test cases for the same scenario. Here we have a webpage that needs testing on basic login – logout functionality.

Check examples of good test cases on the main article here.