1
Automation testingHow ToQa

How To Write Good Test Cases With Examples

6 Mins read

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.

The difficulty in writing good test cases lies in the fact that creating good test cases requires thorough knowledge of the application’s normal behaviour – without knowing this, you can’t know if your tests are covering enough input combinations or putting the application in strange circumstances which you don’t expect it to work properly.

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 when you keep repeating tests. It is even harder to determine if a program has worked properly for each scenario. So avoiding repetition ensures your test cases are lean and deliver maximum value.

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.

write good Test Cases

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.

Good Test Cases:

Test Case #Test Case DescriptionPre-requisites/ Special ConditionsTest StepsExpected Results/ Acceptance CriteriaTest ResultsCommentsTest durationTest Priority
1A user should be logged in to the dashboard when they login with the correct username and password– User should have correct login credentials– Go to the test webpage
– Login with the correct username and password
– Click the Login button
The user should be redirected to the dashboardPASS20 minsHigh
2Users should get an error message if they log in with incorrect credentials – username– Go to the test webpage
– Login with the wrong username and correct password
– Click the Login button
User should get an incorrect username error displayedFAILNo error was displayed10minsHigh
3Users should get an error message if they log in with incorrect credentials – password– Go to the test webpage
– Login with the wrong password and correct username
– Click the Login button
User should get an incorrect password error displayedFAILNo error was displayed10minsHigh
4A user should be logged out when they click the logout button– User should have correct login credentials– Go to the test webpage
– Login with the correct username and password
– Click the Login button
– Click the top left where the username is displayed
– Click Logout
Users should be logged out to the main page, if they attempt to click the back button, they should not be able to go back to the dashboardPASS21 minsHigh
Good test cases


Let’s take a look at the same scenario but for bad test cases

Bad Test Cases:

Test Case DescriptionPre-requisites/ Special ConditionsTest StepsExpected Results/ Acceptance CriteriaTest ResultsCommentsTest durationTest Priority
User loginLogin to the web appUser to be logged inPASS20 minsHigh
User login fail 1Login to the web app with a different usernameError on the pageFAIL10minsHigh
User login fail 2Login to the web app with a different passwordError on the pageFAIL10minsHigh
User logoutLogout from the web appUser to be logged outPASS21 minsHigh
Bad test cases

Good test cases are easy to understand and specify clearly what is expected when input is given to the software. They are also easy to read because they are properly written. Bad test cases leave it difficult for testers, developers, and even managers to determine how tests were written or what they should do when testing them.

Can you spot the differences between the good test cases and the bad test cases?

What details should be in a test case?

  1. A test case should provide specific input and then expected results.
  2. What software was being tested
  3. Test pre-requisites – what should be set up before the test begins(e.g login, user registration etc)
  4. They should contain the date, names of testers and developers
  5. Location of where test was being performed(give web links, or app locations and how to access them)
  6. Test steps that should be taken to run/replicate the test
  7. An Acceptance Criteria(AC) for when the test should pass/fail – this is very important as it defines the validity of the test being performed
  8. What tool and environments to execute it – for example, which devices, operating system etc
  9. Requirement specifications for the feature under test
  10. Nature of the test case (positive/negative test, manual, automation)
  11. Timelines for the tests to be done
  12. Priority of the test in question

Test cases should also be written in a way so that the reader understands what the goal of the test is.

They should have supporting pictures or screenshots so that testers can easily identify them – this ensures that they are not executing something which they are not supposed to be doing.

Conclusion

Test cases are an important part of software testing. They give the testers, developers and managers a way to see what they expect and what they should be doing in order to determine if their software works properly.

Therefore, creating good test cases is an essential job for anyone in the software testing fraternity – it allows you to create a complete test plan for your application which can be used by developers and QA/QC testers to ensure that every aspect of the application has been thoroughly tested.

Don’t miss amazing tips!

1
Related posts
How To

How To Implement Data Tables In Cucumber Using Selenium Ruby

17 Mins read
Table of contents0.1 Advantages of Behavior Driven Development0.2 What is Cucumber?0.3 What are data tables in Cucumber?0.4 How to implement data tables…
Automation testingQaRuby

Selenium Ruby Example And Deployment To The Cloud Grid

13 Mins read
Table of contents0.1 What is Selenium?0.2 How does Selenium WebDriver in Ruby work?0.3 How to use Selenium with Ruby?0.4 How to run…
How ToProgrammingSoftware

How To Write Clean Code

3 Mins read
Let’s look at tips and tricks on how to write clean code. Everyone wants to be able to write code that is…

Leave a Reply

Your email address will not be published. Required fields are marked *

86 − = 76

Γ—
Automation testingQa

What are the most common automation testing challenges?