At the time of writing scenarios, we always tend to write the positive flow to check whether the functionality is working fine and as expected. This is obvious, but as a Quality Analyst do you think this is the right way of adding scenarios? Don't you think we should first try to break the functionality?
Here is where "Negative scenarios" come into the picture.
What is Negative Testing?
Positive testing is to check if the system is working as expected but negative testing is used to determine how the system handles the unexpected behaviour. We should always think about the negative side of the application to break the application. Developers are building the application as per the given acceptance criteria so it is obvious that the functionality will work fine in most cases. So it's the responsibility of the Quality Analyst, to think out of the box in terms of breaking the application.
Negative Testing Scenarios
Consider an example of searching for a product on the website
In this case, we will search for one product (maybe of a single keyword, to finish up my testing) and check if it displays the results or not. Which is what we often do when we try to test something in a positive way.
This is not enough and we should not stop here!
Going further, what if we search for the two words which are not displaying the results as expected. One possibility might be that the keywords are not accepting AND/OR combinations. Or the tester doesn't have the idea of thinking in that way while writing the scenarios.
- What if we add 2 keywords in the search box
- What if we add special characters in the search box
- What if we add numerics in the search box
- What if we add fewer characters in the search box
Consider an example of the image upload functionality of a web application
In this case, if we have a requirement where the image upload field is only accepting file formats like .jpg and .png. Now to break this functionality or check how it behaves if we try to upload files with extensions other than the approved ones mentioned above we should try to upload other files such as:
- Unaccepted image formats like, .jpeg, .webp, .gif, etc.
- Unaccepted file formats, like .pdf, .txt, etc.
Consider an example of the credit card payments
In this case, if we have one of the requirements where it accepts only VISA card, then we should consider below negative cases such as:
- Use other card types like Mastercard
- Add incorrect digits
- Invalid CVV number
- Incorrect expiry date
- Invalid name
Common examples of Negative Test Cases
- Skip the mandatory fields in a web form and try to submit the form
- For date fields in the application, try to enter past dates or invalid dates
- Verify the numeric input ranges for negative values like -1 are acceptable or not
- Verify the phone numbers and pin code inputs when added in a different format
- Enter the larger value than the allowed field size.
Best practices for Negative Testing
When writing negative test cases, we should always consider the boundaries and equivalence partitioning techniques. Set up your requirement test data in positive-negative input values before writing the negative test cases. To think about the negative scenarios, you should have a good understanding of the requirements. Unless and until you don't dig into the requirements, you won't get the negative cases. Always consider the field types for testing negative scenarios. For example, if the input field is accepting only numerics then try to pass the string values.
Conclusion
Negative and positive testing are equally important in building stable and reliable applications. Identifying the negative test cases is a time-consuming process but quite essential. Once you are done with it, the rest is a cakewalk. Thus, Negative testing is a must as it helps in capturing defects before UAT, ensuring a good quality product delivery.