Skip to main content

Negative Testing and Writing negative test cases

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.





Comments

Popular posts from this blog

Benefits of Early and Frequent Feedback in Agile development

One of the reasons why Agile is preferred over traditional development method is "Early and Frequent Customer Feedback". This is not only helps customer to get what he wants but also helps development team to understand the requirement better. There is no room for misunderstandings and delays. so no BAD CUSTOMER SERVICE! In this post, I am going to discuss about some of the major benefits of early and frequent feedback in Agile. One way to get the early feedback is "CI" or Continuous Integration. There are many tools available in the market like Jenkins which help in running automated tests when a change is introduced in the build and give the feedback on the build performance or quality. Below are some of the advantages of early and frequent feedback: Early and regular feedback helps in clearing out the misunderstanding of the requirements. Unlike in traditional method, fixing the issues or requirements change is a lot less expensive. Customer get to see the...

Remove Blanks from Excel Sheet when Excel doesn't recognize field as blank

This is one of the tricks which always helped me in removing the blank fields from an Excel sheet especially when the values are copied from other sources. I have added screenshots of a sample data to show you all the actions step by step. Here are the steps to remove blanks by using one of the special functions in excel: 1. Select your data-set (Select the column which has blank values) 2. Press F5 3. Select "Special". You will see below screen: 4.Select Blanks and click Ok as shown 5. All the blank fields are now selected, you can proceed and delete all of them by selecting "delete" from the home menu.   Here is the final result: I hope this was helpful. Share this with your colleagues and friends to help them out.

All About Continuous Integration in Agile

In my last post,  Benefits of Early and Frequent Feedback in Agile development  I mentioned how Continuous Integration helps in early and frequent feedback. In this post, we are going to go deeper into the concept and see what exactly it does, how it does and its benefits and challenges. Continuous Integration is an automated system which wraps configuration management, software build, deployment and testing into one repeatable process. The best practice is to run the whole set of set into the new build (with all the new code check ins) at least once a day. This gives a feedback on the  build quality. If all the automated tests passed then the build can be used to perform deeper testing. Below are some of the activities carried out by CI: Code analysis Compilation of code and generating an executable file Perform Unit testing Deploying the build onto the testing environment Performing integration testing Generating reports In our project, nightly build and...