Negative testing or destructive testing tests what a software is not made to do or boundary testing which can break the software functionality. In other words, what "Should not" defined under the requirements.
Let's take an example, if a text box under the label "Name" can take only alphabets then when a numeric or special character is entered, it should be able to handle that properly by throwing an exception which could be an error message on the screen or a pop-up box saying “only alphabets allowed”. Another example could be: an input box which can take numeric value range from 1-99, so giving 0 or 100 as input would be considered as negative testing.
When we want to build a quality product, both positive and negative scenarios play an important role. Without negative testing, we would not be able to know what makes the application crash and its limitations. I am going to list down three main advantages of doing negative testing.
Advantages of negative testing:
1. Quality: When we know that the application handles boundary cases well and throws proper exceptions wherever necessary then quality of the application would be considered better than those applications on which negative testing is not executed.
2. Performance: Negative testing can determine the performance of the application. If application crashes often than expected, negative testing can determine what is the root cause and how to deal with it. For example, a music application crashed when "forward" button was pressed more than 5 times which was a negative test case scenario and was fixed in the next release.
3. Limitations: When we know what our application is capable of doing and what are the limitations beforehand, it becomes easier to let end-user know how to use it and what could be expected if he performs some negative functionality. This is an important step for building customer's trust on the product.
Writing negative test cases:
Let's do some work now! I am going to take an example and show you how to write negative test cases based on the requirements. I have an application under test which is related to a bank and I have to test the login screen.
Requirements:
1. Username can be Email or user generated username at the time of signup.
2. Password cannot exceed 10 characters in total.
3. Minimum characters should be 6 in Password.
4. Password should be a combination of alphabets, numbers, and one special character.
5. Special characters allowed are @,$,& and !.
Test cases:
1. Put invalid username or email id.
2. Put all special characters in Password field.
3. Put all alphabets in Password field.
4. Put all numbers in Password field.
5. Put invalid combination in Password field.
6. Exceed the 10 characters for Password field.
7. Put password which is less than 6 characters.
8. Login with wrong credentials.
In above 8 cases, we covered boundary values and also, values which are not allowed. In all these cases, exceptions should be handled gracefully without affecting the performance of the application and user's experience. This was the simplest example, we can apply the same steps to any other applications under test.
Conclusion
Negative scenarios are mostly based on "out of the box" thinking and have no limitations on how many scenarios you can create. Bugs found during negative testing are always high priority since they are found by keeping real end-user in mind. This requires experience and better understanding of the application under test to get maximum negative test coverage.
Let's take an example, if a text box under the label "Name" can take only alphabets then when a numeric or special character is entered, it should be able to handle that properly by throwing an exception which could be an error message on the screen or a pop-up box saying “only alphabets allowed”. Another example could be: an input box which can take numeric value range from 1-99, so giving 0 or 100 as input would be considered as negative testing.
When we want to build a quality product, both positive and negative scenarios play an important role. Without negative testing, we would not be able to know what makes the application crash and its limitations. I am going to list down three main advantages of doing negative testing.
Advantages of negative testing:
1. Quality: When we know that the application handles boundary cases well and throws proper exceptions wherever necessary then quality of the application would be considered better than those applications on which negative testing is not executed.
2. Performance: Negative testing can determine the performance of the application. If application crashes often than expected, negative testing can determine what is the root cause and how to deal with it. For example, a music application crashed when "forward" button was pressed more than 5 times which was a negative test case scenario and was fixed in the next release.
3. Limitations: When we know what our application is capable of doing and what are the limitations beforehand, it becomes easier to let end-user know how to use it and what could be expected if he performs some negative functionality. This is an important step for building customer's trust on the product.
Writing negative test cases:
Let's do some work now! I am going to take an example and show you how to write negative test cases based on the requirements. I have an application under test which is related to a bank and I have to test the login screen.
Requirements:
1. Username can be Email or user generated username at the time of signup.
2. Password cannot exceed 10 characters in total.
3. Minimum characters should be 6 in Password.
4. Password should be a combination of alphabets, numbers, and one special character.
5. Special characters allowed are @,$,& and !.
Test cases:
1. Put invalid username or email id.
2. Put all special characters in Password field.
3. Put all alphabets in Password field.
4. Put all numbers in Password field.
5. Put invalid combination in Password field.
6. Exceed the 10 characters for Password field.
7. Put password which is less than 6 characters.
8. Login with wrong credentials.
In above 8 cases, we covered boundary values and also, values which are not allowed. In all these cases, exceptions should be handled gracefully without affecting the performance of the application and user's experience. This was the simplest example, we can apply the same steps to any other applications under test.
Conclusion
Negative scenarios are mostly based on "out of the box" thinking and have no limitations on how many scenarios you can create. Bugs found during negative testing are always high priority since they are found by keeping real end-user in mind. This requires experience and better understanding of the application under test to get maximum negative test coverage.
Comments
Post a Comment
Share your feedback