Top 13 Tips for Writing Effective Test Cases for Any Application

Posted by Amandeep Singh

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 resource and believe you me, 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 post: Do you need to write test cases in agile testing?]

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

So, writing test cases which 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 in the first attempt…

Effective Test Cases writing is a skill and you can acquire it only with practice and 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, lets briefly understand, “What is a Test Case?”

A Test Case is simply a list of actions which need to be executed to verify a particular functionality or feature of your application under test. Check out the Wikipedia definition here.

Here is the list of top 13 tips/guidelines which you can keep in mind during test design activities to write test cases which are effective, easily understandable and reusable! So here we go…

Simple tips for writing effective Test Cases

#1. Test Case Naming Conventions

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

It’s always a good practice to name your test cases in a way that it makes sense to anyone who is going to refer the test cases in future (including YOU!)

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 check whether the user is able to login 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 so that it gives a brief idea of what the test is for just by looking at its name.

  • TC_01_Online_Login_Success or,
  • TC_01_Online_Valid_Case and likewise…

Just try to 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!

I hope this one was pretty simple. Okay, let’s move on to the next one!

#2. Test Case Description

Description is where you mention all the details about what you are going to test, and the particular behavior being verified by the test.

The ‘description’ of a test case should define “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 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 a times test data preparation takes most of the time in a testing cycle.

It may sometimes need you create a test data afresh as creating a 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 a new test data every time you need to execute the test.

A few pointers:

  • 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 are properly defined test case verification steps covering all the verification points for 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 artifacts (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 (check: 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 artifacts 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 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 sub tests 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 are ubiquitous.

Imagine a scenario where the person who wrote all those Test Cases leaves for some reason and you have a completely new team to work on the Test Case execution, the entire effort spent during the design phase could go down the drain.

If you are the one leaving the organization, you are better off 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. Review

With Test Cases playing an important role in 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 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 do 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 Jacobson’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 really 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 (like ALM or QC).

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 re-used for some other future project.

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

#12. Maintenance & Updates

Okay, for this one a 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 re-usability, 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 it. 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 crossed well over 2300 words 😉

I really 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, please do 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.

Did you like this post?
Sign up now and I will send you more awesome posts like this every week.
The following two tabs change content below.
Aman is the founder and editor, QuickSoftwareTesting. Having spent plenty of years in Quality Assurance, he decided to share his knowledge with the testing community and that is when QST was born! You can also catch him on Facebook and Twitter.

65 Comments so far. Feel free to join this conversation.

  1. bhushan shah November 3, 2016 at 10:07 AM - Reply

    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.

    • Amandeep Singh December 1, 2016 at 4:13 PM - Reply

      Hi Bhushan,

      I know it has been pending with me for so long – I need to really do it and add the details here.

      Thanks

  2. rahul saxena October 11, 2016 at 11:13 AM - Reply

    THANK YOU SO MUCH SIR FOR SHARING THIS IMPORTATANT INFO…IT WILL BE REALLY HELPFUL FOR US

  3. Stephen September 13, 2016 at 4:25 PM - Reply

    Great article!

  4. EkonaBoy July 15, 2016 at 2:31 PM - Reply

    This was a great read and very educative.
    Awesome article sir !!

  5. Chandu June 27, 2016 at 5:55 PM - Reply

    Add some examples of each point, do’s ant dont’s,
    give sample Test case template at end

  6. Rohit Gupta February 17, 2016 at 5:55 PM - Reply

    Amandeep truly appreciate all this points.
    All are the important things which is required to create complete understandable test cases. thanks

  7. Adinath February 12, 2016 at 1:09 PM - Reply

    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.

    • Amandeep Singh February 12, 2016 at 2:29 PM - Reply

      Thanks for your comment, Adinath 🙂

      Stay tuned for more and do subscribe to my free newsletter not to miss a single post…

      Cheers!

  8. sanjeev chauhan February 11, 2016 at 12:38 PM - Reply

    its very good article..i will follow it in future …thnks sir

    • Amandeep Singh February 11, 2016 at 12:49 PM - Reply

      Thanks Sanjeev – keep coming back for more 🙂

      Cheers!

  9. Manish Shah January 4, 2016 at 2:34 PM - Reply

    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.

    Regards

    • Amandeep Singh January 19, 2016 at 7:39 PM - Reply

      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.

  10. Kalpesh December 18, 2015 at 10:33 AM - Reply

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

    • Amandeep Singh December 24, 2015 at 6:42 PM - Reply

      Thanks for your comment, Kalpesh. I am happy that this check-list helped. I hope you will share it with your friends and colleagues to support my effort 😉

      Cheers, Aman

  11. Pravin patil October 4, 2015 at 3:59 AM - Reply

    thanks dear aman this very good article, please guide us on Soapui automation.

  12. Dileep kumar July 30, 2015 at 9:59 AM - Reply

    its a wonderful article,
    i enjoyed it.

  13. Claudio July 23, 2015 at 8:15 PM - Reply

    It is very interesting. I think you describe a best way that how we can create good test cases

  14. Kasi June 3, 2015 at 7:05 AM - Reply

    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.

    -Kasi.M

    • Amandeep Singh June 3, 2015 at 1:44 PM - Reply

      Thanks Kasi, I am glad this check-list helped you 🙂

  15. Umakant chauhan May 22, 2015 at 12:51 PM - Reply

    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

    • Amandeep Singh July 24, 2015 at 2:39 PM - Reply

      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…

      Thanks
      Aman

  16. VN April 15, 2015 at 7:45 AM - Reply

    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.

    Regards

    • Amandeep Singh May 12, 2015 at 4:16 PM - Reply

      Hi VN,

      Yes, it was planned and somehow got delayed. I will soon upload some sample test cases for a sample/public application.

  17. Aroosa April 7, 2015 at 7:46 PM - Reply

    its really usefulll……thanks alooottttttt

  18. sangeetha February 2, 2015 at 9:34 AM - Reply

    super very useful messages.. Kindly inform me if any job opportunity in testing im a fresher for this software testing..

  19. Anchit Bansal February 1, 2015 at 5:40 AM - Reply

    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.

  20. Mohan December 24, 2014 at 8:17 AM - Reply

    Hi Aman,
    It is easy read and understand, I simply need examples.

  21. aftab alam December 19, 2014 at 5:59 PM - Reply

    Hi….
    Really u have share a very useful & meaningfull info

  22. Krati sharma November 6, 2014 at 5:59 AM - Reply

    for freshers its easy to understand..

  23. Rahul Nalya November 2, 2014 at 9:11 AM - Reply

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

  24. radha October 28, 2014 at 10:19 AM - Reply

    Really its a useful article.

  25. Tarun Singhal October 22, 2014 at 8:54 AM - Reply

    Dear sir

    Plz give me testing martial

    Cheers
    Tarun Singhal

  26. chandan kumar October 15, 2014 at 2:19 PM - Reply

    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.

  27. siddheshwar October 15, 2014 at 6:32 AM - Reply

    Hi, Amandeep- It’s helpful for me but i want give me one example of the who to write the test case.

    • Amandeep Singh October 30, 2014 at 5:44 PM - Reply

      Hi Siddheshwar,

      Please let me know and I will try to help in the best possible way…

      Thanks!

  28. Sachin Patil October 14, 2014 at 8:01 AM - Reply

    Nice artical. Very useful for us.
    Thanks Aman.

  29. Amanda October 3, 2014 at 6:33 PM - Reply

    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

    • Amandeep Singh October 6, 2014 at 12:19 PM - Reply

      Hi Amanda – That’s really useful as well; thanks for sharing the link with our readers.

      Thanks,
      Aman

  30. Krishna kakri September 11, 2014 at 9:01 AM - Reply

    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.

    • Amandeep Singh September 25, 2014 at 1:11 PM - Reply

      Hi Krishna, I am glad this article helped you.

      Yes, definitely that’s a good suggestion and you will soon see a similar article for automation as well.

      Cheers
      Amandeep Singh

  31. Nidhin Kannath September 8, 2014 at 2:52 PM - Reply

    very useful for freshers like me………….thank you 🙂

  32. Upma September 3, 2014 at 11:34 AM - Reply

    Nice Article!..easy to understand and implement

  33. Gopi August 30, 2014 at 10:23 PM - Reply

    Very Good Article. It is very useful for me.

    • Amandeep Singh September 25, 2014 at 1:13 PM - Reply

      Thanks Gopi – any feedback you would have for this list? Any point you see missing here?

  34. Pooja Jagtap August 30, 2014 at 8:23 AM - Reply

    Hi-ii Amandeep,

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

    Thank You!

  35. Neha August 25, 2014 at 12:22 PM - Reply

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

    • Amandeep Singh August 29, 2014 at 11:34 AM - Reply

      Thanks Neha…

      As many readers have requested this, I will add a section for sample test case to this post soon.. kindly bear with me till then…

      Cheers!

  36. Carolyn Venable August 25, 2014 at 5:06 AM - Reply

    Nice breakdown analogy of the procurement of writing a good test case, awesome job!!!

  37. Manjeet June 30, 2014 at 9:00 AM - Reply

    How can I write better cases kindly guide me.

  38. varsha June 27, 2014 at 1:42 PM - Reply

    Nice Article..

  39. Sujit June 12, 2014 at 2:13 PM - Reply

    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?

  40. puneet aneja June 3, 2014 at 6:28 PM - Reply

    Very nice Article Aman.

  41. Ruma Dak May 18, 2014 at 11:07 AM - Reply

    Good one!

    • Amandeep Singh May 18, 2014 at 12:14 PM - Reply

      Ruma, I am glad you liked this list…

      Cheers,
      Aman

  42. aaryan April 12, 2014 at 8:55 PM - Reply

    gr8 . plz provide me some good examples of different test cases in software testing.

  43. Meenal March 27, 2014 at 12:37 PM - Reply

    This article is really usefull and helpful for anyone who wants to know how to write effective test cases.

  44. Pavithra S Ramanathan January 24, 2014 at 10:18 AM - Reply

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

  45. Rohil January 24, 2014 at 12:00 AM - Reply

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

Leave A Response