How to Write Effective Test Cases in 2022 (13 Best Tips)

Test cases are very important for any project as this is the first step in any testing cycle, and if anything goes wrong at this step, the impacts get extrapolated as you move forward in the software testing life-cycle.

Knowing how to write good test cases is extremely important for you as a testing professional and it doesn’t take too much of your effort and time to write effective test scripts! You just need to follow certain guidelines while writing test cases or as they call it – follow “test case writing best practices.”

In this article, I am going to talk about some simple yet effective tips which you could use for writing effective test cases.

Related: Do you need to write test cases in agile testing?

Test case writing is an activity that has a great impact on the testing phase and this makes test cases an important part of the test execution process!

Writing test cases that are effective as well as reusable is very important; good test cases save a lot of time in the later stages of testing (really!) if you do it right on the first attempt…

Effective Test Cases writing is a skill and you can acquire it only with practice and an in-depth understanding of the application for which test cases are being written.

Incorporating some simple tips I have given here will help you master the skill of test case writing.

Before we jump right on to the tips, let’s briefly understand what’s a test case.

What is a Test Case?

A Test Case is simply a list of actions and instructions that need to be executed to verify a specific functionality or feature of any application under test. Check out the Wikipedia definition here.

Here is the list of the top 13 tips and guidelines that you can follow during test design activities to write test cases that are effective, easily understandable and reusable!

Here we go!

Tips for writing effective Test Cases

#1. Test Case Naming Conventions

Although this is the simplest tip to follow on this list (I feel!), the majority of testers don’t practice it very effectively – a Naming convention for Test Cases!

It’s always a good practice to name your test cases in a way that makes sense to anyone who refers the test cases in the future (including yourself!)

Let’s take an example!

There is a project called “Online” which has a functional area named “Login”

Now, I want to write a test case to verify a simple test whether the user is able to log in to the website using an email and password.

To keep things simple, instead of naming the tests as TC_01, I could use the below naming convention for my test case to give a brief idea of what the test is for just by looking at its name. Without even going into the test case.

• TC_01_Online_Login_Success or,
• TC_01_Online_Valid_Case
• and so on…

Make it look relevant to the project/module/functional feature under test. This is just an example and you can name the test cases whichever way suits you best.

Try to make them make as much sense they can just by looking at the test case ID or test case name!

This one was pretty simple.

Okay, let’s move on to the next one!

#2. Test Case Description

The description is where you mention all the details about what you are going to test, and the particular behaviour being verified by that test.

The ‘description’ of a test case should define and clearly explain “What am I going to test?”

What needs to be verified, which test environment it needs to be verified in, which test data is to be used – all this information goes into the description.

Mainly, you would find the below information in a well-written test case description:

• Test to be carried out/behavior being verified
• Preconditions and Assumptions (any dependencies)
• Test Data to be used
• Test Environment Details (if applicable)
• Any Testing tools to be used for the test

I have written more about ‘Assumptions and Preconditions’ and ‘Test Data’ below.

#3. Assumptions and Preconditions

While writing test cases, you should communicate all assumptions that apply to a test, along with any preconditions that must be met before the test can be executed.

Below are the kind of details you would like to cover as part of this section:

• Any user data dependency (e.g. the user should be logged in, which page should the user start the journey, etc.)
• Dependencies on test environment
• Any special setup to be done before Test Execution
• Dependencies on any other test cases – does the Test Case need to be run before/after some other Test Case?

This list is not exhaustive and the items I have listed are just an example of what you could include in this section.

#4. Test Data Input

Identifying test data can be really a time-consuming activity – many times, test data preparation takes most of the time in a test cycle.

It may sometimes need you to create test data afresh as creating new data might take lesser time compared to identifying it. (Ask a Tester!)

To make your life easy as a tester (and your fellow testers!), wherever applicable, you can give Test Data to be used for the Test Case within the test case description or with the specific Test Case step.

This saves a lot of time in the long run as you won’t have to hunt new test data every time you need to execute the test.

A few tips for Test Data in a Test Case:

• In many cases where you know the test data can be re-used over time, you can mention the exact Test Data to be used for the test.
• If the test only involves some values to be verified, you can opt to specify the value range or describe what values are to be tested for which field. You can do this for negative scenarios as well.
• Testing with every value is impractical, so you can choose a few values from each equivalence class which should give good coverage for your test.
• You could also decide to mention the type of data which is required to run the test and not the real test data value. This applies for projects where the test data keeps changing as multiple teams use it and may not be in the same state when I use it the next time – mentioning the type/state of user test data to be used helps a great deal for anyone who is running the test next!

#5. Cover all Verification Points in Test Design Steps

Another important part of a well-written test case is properly defined test case verification steps covering all the verification points for the feature under test.

By comparing your Test Case steps with the artefacts (Requirement documents, Use Cases, User Stories or Process Maps) given for your project, you can make sure that the Test Case optimally covers all the verification points.

Bonus Tip: If you work in agile testing, you can opt NOT to cover every single test as a test case (read: should you write test cases in agile?). Instead, you can cover some of these verification steps during exploratory testing (read: benefits of exploratory testing).

#6. Attach the Relevant Artefacts

As I mentioned in the above point, wherever possible you should attach the relevant artefacts to your test case.

If the change you are testing is not massive, you could consider mentioning it in the test step itself.

But, if it involves a specific section on the screen which could be tricky to mention in the test step, attaching the specification documents or screen designs to that particular step helps.

#7. Expected Result

A well-written Test Case clearly mentions the expected result of the application or system under test. Each test design step should clearly mention what you expect as the outcome of that verification step.

So, while writing test cases, mention in detail what page/screen you expect to appear after the test and, any updates you expect as an outcome to be made in back-end systems or database (ex. a new entry should be made to DB table).

You can also attach screenshots or specification documents to the relevant step mentioning the system should work as outlined in the given document to make things simpler.

#8. Divide Special Functional Test Cases into Sets

For effective test case writing, you should consider breaking down your Test Cases into sets and sub-sets to test some special scenarios like browser-specific behaviours, cookie verification, usability testing, Web Service testing and checking error conditions etc.

If you strive to write effective test cases, you should write these special functional test cases separately.

For instance, test cases to verify error conditions should be written separately from functional test cases and should have steps to verify the error messages.

For example, if you need to verify how the login feature for any application works with invalid input, you can break this negative testing for login functionality into subtests for different values like:

• Verify with invalid email-id
• Verify with invalid password
• Verify with blank email-id field and so on…

#9. Legible & Easily Understandable

Whatever project you work on, when designing test cases, you should always consider that the Test Cases will not always be executed by the one who designs them.

So, the tests should be easily understandable, legible and to the point.

Test Case suites that are only understandable by the ones who designed them is a mess.

Imagine a scenario where the person who wrote all those Test Cases leaves for whatever reason and you have a completely new team to work on the Test Case execution, the entire effort spent during the design phase goes down the drain. I’ve been there, it’s painful.

If you are the one leaving the organization, you are off the hook but if you are within the same company but just changed teams, you might be nudged all the time for explaining what you wrote!

So better do it right the very first time!

You should focus on writing Test Cases that:

• are simple and easily understandable by everyone (including YOU!)
• are to the point! You don’t have to be writing essays! (wherever you feel any Test Case is going beyond a certain amount of steps, feel free to break it into a new Test Case)
• still have enough coverage

#10. Test Case Review

With Test Cases playing an important role in the Software Testing Life cycle, making sure they are correct and conform to standards becomes even more necessary – that is where the Test Case review process comes into the picture.

However, you need to take care of a few prerequisites for the review process to start because of which the review process could be harmful as well! Check out Eric’s take on this.

#11. Reusable

You should write test cases keeping in mind that they could be re-used in the future for some other project/teams.

On that note, before writing a new Test Case for your project/module, always try and find out if there are test cases written already for the same area? That saves a lot of time!

If you spend a bit of time with other teams finding out the existing test case you might get lucky – you won’t be repeating any test cases hence avoiding any redundancies in your Test Management Tools.

Also, if you get the existing test cases written earlier around the same module, you should be updating those instead of writing new test cases so that for any journey you always have the updated test cases in place.

This might not apply if yours is a new project, however, you can try to write test cases in a way that they could be reused for some other future project.

Also, if you need a particular test case to execute some other test case, you can simply call (link) the existing test case in pre-conditions or at a specific test design step.

#12. Maintenance & Updates

Okay, for this one plenty of pointers have already covered above (in point #11)!

It’s of umpteen importance to make sure that the Test Cases are always updated as per the newly introduced changes in the application they apply to.

Reiterating my point about reusability, in case of any changes to an existing journey or functionality, you MUST consider updating the existing Test Cases instead of writing any new Test Cases hence avoiding redundancies to the existing set.

This also makes sure you always have updated Test Cases for any journey in your application.

#13. Post Conditions

Post-conditions basically specify the various things that need to be verified after the Test has been carried out.

In addition, post-conditions are also used to give guiding instruction to restore the system to its original state for it not to interfere with later testing.

For example, this is quite useful if you mention the changes to be made to a test data for it to be used for a later Test Case for the same functionality.

CONCLUSION:

It’s a huge task to write effective test cases with all the required details on them. As long as you make sure to think from the end users’ perspective, know the application end-to-end, and follow the test case writing best practices I have mentioned here, you are gonna be fine! 😉

Here in this list, I have tried to cover the most simple and useful tips which you can apply while you are in the test case design phase.

I have tried to prepare a comprehensive checklist you could follow while designing test cases – it took me several sittings and many hours to compile this list – just noticed, the article has grossed well over 2500+ words 😉

I HOPE this list helps you!

Now that you know how to write test cases (at least I trust you do!), get back to designing the best test cases and break the app during execution!

If you found this checklist useful, please do support my efforts by sharing this article on LinkedIn, Facebook and Twitter.

Best of Luck and Happy Testing!

Is there any such tip that you follow and is not covered on this list and would like to share with fellow QueSTers? Drop a line in the comments below and I would love to add it to the list.

You can also drop me a line with your suggestion and feedback here.