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.”

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.

#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.

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.

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.

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.

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.

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.

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…

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.

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