Negative test cases are an integral part of any testing activity. They work by aiming to break an application with invalid data as a means of evaluating behavior.
For the basics, read an explainer on negative testing, but here we are discussing how to approach some of the more important negative test cases to be executed while testing the applications.
Executing negative test cases is the method by which we determine an application’s ability to work in unexpected scenarios that can affect the stability of the system. If such scenarios are not explored and managed during testing, they will occur in the live environment and affect the reputation of the businesses. Listed below are the test cases which every tester should consider during testing.
12 Negative Test Cases
Text Using Apostrophes
There will be various text fields in the application where developers allow the input of plain text. It is good practice to check those fields accept text that contains an apostrophe, often called a single quote mark, which denotes possessive form and to indicate an omission. For example: Let’s learn something from TestLodge blog or Chris D’Mello.
Data Validation Error Messages
It should be clear on a functional specification document which fields are mandatory to be filled. It is good practice to test the specified fields by supplying invalid data to validate the error messages and specify to the end-user that they need to enter valid data to proceed further.
Field Data Type Validation
There are various fields applications which require the input of specific types of data, such as zip code, cell phone number, date, and time. It is a good practice to provide invalid input to validate the correct error messages to force the end-user to supply the correct inputs.
Field Size Validation
In any application, some of the text fields should not exceed a specified limit. Often, developers omit to make the character limit for end-user, so it is the responsibility of the tester to validate these fields, which will be listed in the functional specification document. It is recommended that the user should not be able to enter more characters than the specified limit, rather than being shown an error message.
Boundary Value Validation
There are certain fields found in financial applications that can have a critical impact if they are not tested properly. One such example is the accrual of interest rates on a product where the field should not take a negative value or a value outside the range. It is good practice to try entering both negative and positive values that are outside the specified range, to make sure the user is notified of the fail.
Date Bound Validation
It is a tester’s responsibility to validate fields that store dates in the database. For example, a restriction or a validation message should be in place if the user tries to input a future date mistakenly.
Calendar/Date Validation
Date fields are important in any application. Testers should validate the date format by providing invalid input to check whether the error message is in place or not. For example, 1.09.2019 is an invalid format, so an error message should be in place to guide the user to provide a date in a valid format. We also know that a date such as 30th February does not exist, so testers should verify with erroneous dates as well as leap years.
Unicode/Special Characters Validation
Some global applications accept Unicode/Special characters in their fields. For example, if the user logs-in to the application using Facebook and their name contains Unicode or special characters, then there is a chance that the name won’t appear accurately. A tester needs to verify such scenarios to provide a smooth user experience.
Name Validation
Similar to the above scenario, there will be situations when users from other cultures can join your application, and their language scripts will be different. For example, a user could sign-in to your application via Facebook, and their name will appear in the Mandarin script. A tester should try using scripts from a range of different countries to test the specific functionality of the application.
Web Session Validation
Whenever a user is logged in to the application, the app authenticates and maintains the session of that particular user. To validate the app’s behavior in a negative situation, a tester should try to open a page or any form and copy the respective URL and paste it into another browser. If the authentication is not in place, then the user will be able to gain unauthorized access, but with proper authentication, whatever the URL is, the user should be navigated to the login page.
Inspect Elements
Consider a scenario where the application has predefined pricing for a list of items, and that particular field is disabled so no one can change it. As a tester, your approach should be to inspect the particular element from the browser’s developer tools to try to enable the field by manually entering any value before proceeding with the process to complete the transaction. If the transaction takes place with the value you have entered manually, it is a huge defect. Otherwise, if the transaction proceeded with the actual value, then you are good to go. An easy way to check whether you are successful with manually entering the value through elements is to check the database where you can validate the value being processed.
Roles Authentication Validation
Often in applications, there are various roles such as Admin, HR, Finance, or Employee, which all have restricted access according to their defined modules. To validate the authentication of each role, a tester should try to login with one role at a time, copy the URL and paste it into another browser to see whether they are accessible with or without login. Another thing a tester can do is to try to copy and paste the individual role’s URL into another session’s browser. For example, when logging into the HR module, copy the URL, and later replace it with the URL of Employee’s module to see if the roles switch in that way.
Conclusion
Negative test cases are the real life-savers in any testing activity. They are destructive in nature but help us by preventing unwelcome situations in the production environment. It is the responsibility of a tester to design negative test cases that keep in mind the scenarios mentioned above, which will ultimately provide effectiveness at all levels.
