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.
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!)
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.
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 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.
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.
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
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.
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.
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.
Latest posts by Amandeep Singh (see all)
- 40+ Super Useful Chrome Extensions for Software Testing [2017 Update] - February 24, 2016
- Writing Test Cases for Brochure/Catalog Based Websites [Checklist] - December 29, 2015
- Latest trends in Software Testing 2015 – How the World Tests? - November 19, 2015