How to write Test Cases for applications effectively

A test case is a set of conditions defined by the tester to determine whether the system performs or not under the given condition. The test case is written so that to check the working of an application under different constrained environment. This ensures that each and every feature is of the application is working
In today’s blog, we will see in detail on how to write the test case effectively. Below are the 11 factors that have to be considered for writing a test case effectively.
1. Naming the test case
Naming the test case plays a major role in making it perfect and easy to access. It is always a good practice to name the test cases in a way that it makes sense to anyone who is going to refer the test cases in future. A best practice is naming the Test Cases to represent the module name or functional area we are going to verify in that test case. This can be explained with an example.
Consider a project called “Online” which has a functional area named “Login”
Now, we 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, we could use the below-naming convention for our 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…
Quick Note: 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. This will really help the peers or new testers.
2. Test Case Description
The description of the test case is where we mention all the details about what we are going to test, and the particular behaviour being verified by the 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.
We should enter as much information as possible in the Test Case description! Mainly, we would find the below information in a well-written test case description:
• Test to be carried out / behaviour 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
3. Assumptions and Preconditions
While writing test cases, we 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 we 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?
We should add as much information as possible for any conditions to be met before running the test case.
Quick Note:  Include as much information as possible for any conditions to be met before executing the test case.
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 testing cycle. It may sometimes need we create a test data afresh as creating a new data might take lesser time compared to identifying it
Also, we 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 we won’t have to hunt a new test data every time we need to execute the test.
If the test only involves some values to be verified, we can opt to specify the value range or describe what values are to be tested for which field. We can do the same for negative scenarios as well. Testing with every value is impractical so we can choose a few values from each equivalence class which should give good coverage for the test. We 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 to projects where the test data keeps on changing as multiple teams use it and may not be in the same state when we use it the next time.
5. Cover all Verification Points in Test Design Steps
Another important part of a well-written test case is the properly defined Test Case Steps covering all the verification points for the behaviour under test.
The Test Design Steps should not only cover the functional flow but also each verification point which must be tested! By comparing the Test Case steps with the artefacts (Requirement Documents, Use Cases, User Stories or Process Maps) given for the project, we can make sure that the Test Case optimally covers all the verification points.
6. 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 we expect as the outcome of that verification step.
So, while writing test cases, mention in detail about the page/screen we expect to appear after the test and, any changes we expect to be done to any backend legacy systems or Database. We can also attach screenshots or specification documents to the relevant step and mention that the system should work as outlined in the given document to make things simpler.
7. Divide Special Functional Test Cases into Sets
For effective test case writing, we should consider breaking down the Test Cases into sets and subsets to test some special scenarios like browser specific behaviours, cookie verification, usability testing, Web Service testing and checking error conditions etc.
For instance, Test Cases that check error conditions should be written separately from the functional test cases and should have steps to verify the error messages. While writing these scenarios into sets, a particular feature has a lot of input combinations, we can separate the test into sub-tests.
For example, if we need to verify how the login feature for any application works with invalid input, we 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.
8. Legible & Easily Understandable
While designing Test Cases we should always consider that these Test Cases will not always be executed by the one who designs it.So, the tests should be easily understandable, legible and to-the-point.

9. Review
With Test Cases playing an important role in Software Testing Lifecycle, 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.
Test Case Review can be done by peer testers (termed ‘Peer Review’), BA, developers, product owners or any relevant stakeholders.However, we 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!
10. Reusability
We should write test cases keeping in mind that they could be re-used in the future for some other project/teams. Existing test cases which were written earlier around the same module can be updated instead of writing new test cases so that for any journey we always have the updated test cases in place. This might not apply if we are a new project, however, we can try to write test cases in a way that they could be re-used for some other future project.
Also, if we need a particular test case to execute some other test case, we can simply call the existing test case in the preconditions or at the specific test design step.
11. 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 we mention the changes to be made to a test data for it to be used for a later Test Case for the same functionality.

These are the 11 factors that have to be considered to write a test case effectively. It is important to perfect a test case so that it gives the necessary results.

Blog reference:

Amandeep’s Quickway of testing blog.

 

Testing Team,

Mallow Technologies.