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.

Test Case Writing Tips

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!)

Quick Tip: As a best practice, name the Test Cases to represent the module name or functional area you are going to verify in that test case.

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.

Quick Tip: Enter as much information as possible in the Test Case 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?
Quick Tip: Make sure to add as much information as possible for any conditions to be met before running the 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.

Quick Tip: The Test Design Steps should not only cover the functional flow but also each verification point which must be tested!

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.

Quick Tip: If while writing these scenarios into sets, a particular feature has a lot of input combinations, you can separate the test into sub-tests.

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.

Quick Tip: Test Case Review can be done by peer testers (termed ‘Peer Review’), BA, developers, product owners or any relevant stakeholders.

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.

Quick Tip: Always consider updating the existing Test Cases before you start writing new test cases!

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.


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.

Liked this post?
Sign up now and I will send you more awesome posts like this.
I agree to have my personal information transfered to AWeber ( more information )

Similar Posts

Leave a Reply

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


  1. Great article and very helpfull. Would you give examples for the cases that you mentioned.

    Thanks for the great job

  2. Authentic blog … It will help those who are in the software testing field and also those doing software testing training…

  3. The way in which you describe how to make effiicient test case is very good. but is possible to give example on that point so we understand more easily.

  4. Hi Amandeep,

    Great!!!! Very Good Article you have written. It is highly useful for beginners & experienced people also.

    Thanks for sharing the article with much more details.

  5. Well written Aman. these tips should keep reminding to keep the basics clean.

    With the world moving to adopt Agile way of building software in increments many a times the entire feature is not broken down to well defined stories which are picked up each Sprint. Test Analysts are now working to verify and validate a part of the complete functionality built with a lot of unknowns and assumptions. Tests have to be written and updated across sprints to finally achieve a state of completeness.

    Have you or any of the readers here faced this? How are you working around this in your work space?

    I will work on a write up and post here soon as to what we are doing. Meanwhile I wanted to throw this question out to the community.


    1. Hi Manish, you have made a valid point here.

      The whole point of agile is to break down requirements (User stories) into smaller chunks of deliverable features (minimal viable products). Ideally, if we as a scrum team feel that a user story is huge to be delivered in the sprint, we try to break it down into smaller user-stories or sub-tasks.

      This is done assuming if the project/scrum would come to an end, this particular feature could still be release live and still add value to the application. This is precisely what we do in our scrum team.

      I would love to see your write and it would be great to publish it on QST for other readers to provide their version how they handle such situations in their teams. You can send your write-up to aman[at]quicksoftwaretesting[dot]com or upload it here.

  6. Excellent article i have ever seen for test case writing. It will helps in every stage of testing career. Thanks for everything. Cheers!

  7. exhaustive mention of good test case writing! , good for beginners :).
    But can you suggest good tools apart from excel(as most organizations use)which we can be used for writing test cases preferable opensource and which can help in re-usability also .

  8. Hi Amandeep,

    Thanks! for the meticulous article on writing effective testcases . Never knew there are so much points to be considered when writing testcases until i stumbled upon this article.


  9. Hi Amandeep,

    I want to know ,during test case creation fallows which documents (like name, etc) and how to gather information about projects ,and who test case create. please help me.given my email Id if possible.

    thanks By
    U chauhan

    1. Hi Umakant – first of all, my apologies for replying to you this late… got a little busy…

      Regarding your query, any artefacts produced as part of the project shaphing phase (like BRS, DRS, Designs, Wireframes, Use Case documentation, User Stories) will all contribute towards Test Case creation during Test Design phase.

      Information about projects again would be available from pre-planning meeting or if your project is past the shaping phase, you can get most of the details in Sprint planning meetings.

      I have tried to answer your questions based on available details in your query.. if I havent been able to answer your query completely, please do let me know and I will try to help in the best way I can…


  10. Hi Aman

    Very good article.

    I see that you promised to upload sample test cases. Did you upload any sample pack? I can’t see any.


  11. I am new to software testing. The article written is very good and informational. Kindly mail me few sample of test cases so that I can understand it more and it will be more helpful to me.

  12. Hi,amandeep this is really help full for me but please shear an example of any test case to understood everything.

  13. Hello sir,,Today I jst go through the article …its really impressive nd listed very clearly which helpful to improve the writing test case skill.
    actually i want to know the real scenario behind all this testing activity…could u plz list out the steps.

  14. These are some great suggestions for writing test cases! We have also written a post about test cases, which covers a few different points from yours and include templates. Check it out here – bit.ly/1CbHEhL

  15. Great Article,
    I’m also a Fresh QA engineer and obviously this helps me and want read next article about how to write automatic testing scripts besides the automatic testing tools.

    Thanks Amandeep Singh.

  16. Hi-ii Amandeep,

    I liked your article and this is really helpful to me. And I also waiting for sample test cases.

    Thank You!

  17. Hi Amanji,
    Sir it’s Very nice article .Could you also share us a sample test cases for the above mentioned points.

  18. Hi,

    Really nice and useful information indeed. Could you also share us a sample test cases for the above mentioned points and also, if there are any good websites available from where we can refer?

  19. Nice one! Written in simple way and highlights the importance of test cases. It’s a real skill to write an effective test case.

  20. very good article!!! highly recommended for beginners and as well for testers who need to understand the process about test design phase