When it comes to testing, positive or happy path testing is the norm. Every product team practices it. Here’s generally how it goes- when a testing user enters the right value, it is accepted; if the wrong value is entered, it is rejected. Voila! The product is officially tested. But that’s just one part of the story! What about other scenarios, especially the plethora of ‘what if’s’?
Everyone involved in the testing journey is a human being, who are prone to human error. Therefore, there is no one specific approach or path that will ‘always work’. Massive product failures can only be avoided if all possibilities are tested, not just the ‘most obvious’ ones.
If you want a robust product, you need negative testing as part of your Software Development Lifecycle (SDLC). Negative testing ensures that the software application will remain stable in any condition and not crash, even with invalid data input. With imagination, creativity, and foresight into user behavior, you can increase the stability and reliability of your product like never before. What’s more, you can even automate it.
In this blog, we will walk through a few examples of testing failures and the best negative testing techniques to avoid them.
Situation 1: Hacked Mobile Banking App
John was flabbergasted when he learned his mobile banking app was hacked. Surprisingly, there were no hackers involved. Instead, it was his 5-year-old daughter! When John’s daughter entered the wrong password 10 times, she could not log in. She simply got redirected to the login screen. However, when she tried for the 11th time, it allowed her to login. The app should not have allowed a login after 10 incorrect attempts, but it did! Why? Simply because it was not tested 10+ times with an incorrect password. All it took for the ‘hacked’ login to occur was a saved username on that phone. This is how a toddler hacked into a secure mobile banking app.
Use these techniques to better secure your applications:
Technique 1: Boundary value breach
The boundary value breach technique tests values that are outside of defined boundary limits.
Supposedly, if a user has attempted to login three consecutive times, his/her login should be locked. To implement this rule, quality assurance engineers need to test for 3+ attempts.
Similarly, for a banking app which has a transaction limit between $100 to $500, then functionality tests should be conducted with values <$100 and >$500.
Technique 2: Equivalence Partitioning
This technique is also known as Equivalence Class Partitioning. Under this technique, input data units are divided into equivalent partitions that can be used to derive test cases. The smaller number of test cases help reduce testing time considerably. You can apply this technique where there is a range in the input field.
Simply said, suppose a café lets you order only 10 pizzas at a time. This means your order will be accepted if you choose any number of pizzas between 1 & 10. But your order will be rejected with an error message for any number of pizzas between 11 to 99. Similarly, your order will be rejected if the number of pizzas is between -1 to -100 pizzas.
Combining both the above methods i.e. Boundary value reach + Equivalence portioning would have negated the ability for the toddler to hack her father’s bank account and provided a more secure mobile bank app to their consumers.
Situation 2: E-Commerce Cart Errors
Here is another example of product failure that could have been prevented before its release.
Kathy was comparing 2 sets of headphones on a newly launched e-commerce site. She wanted to do some quick research before purchasing one of them. The site did not have an ‘Add to Wishlist’ option so she added both products to the cart.
Upon further review, Kathy ultimately chose not to buy either set of headphones she had earlier shortlisted. She removed them from the cart, but in a hurry, she deleted them thrice. She then paid for other items in her cart without checking the final amount. Later, she realized that the site had charged her for one set of headphones but would not be delivering them to her. She contacted the company to register a complaint.
The site developers examined the issue. They found out that when Kathy deleted two products thrice, the quantity of headphones seen in the cart was -1 instead of zero. Thus, she got charged for the product but did not receive it. This error occurred because site developers did not test the site for any negative paths.
How does negative testing help avoid these types of issues? It is with a technique called ‘Invalid data entry’.
Technique 3: Invalid data entry
Invalid data entry tests when an entry or deletion is made for a value that is more than the permissible value. For example, when 2 is allowed, test using a value other than 2. Considerations when testing include:
- Decimals and separators used in the Spanish language utilize a dot (.) If your system is designed for the dot as a separator, you should test what occurs if a comma is placed instead of a dot.
- If your system is designed to handle numbers with two digits post the decimal point value, check what happens if there are 3 or 4 digits or any number >2.
- If the password accepts only alphanumeric character, test for special characters.
- Enter invalid data into mandatory fields and validate the error messages which ask the user to enter valid data to proceed.
- Enter invalid data (alphabets) to specific data type fields like zip code, cell phone number, date, and time and repeat.
It’s not just invalid data entry that can cause product failure or bugs. It’s invalid role-based authentication too. In the next example, we learn why validating role-based access is also critical to business processes.
Situation 3: Unauthorized budget approval
Rachel submitted a required budget to higher management for a project and was awaiting approval. What happened surprised her. All budget expenses were approved for her project; and by the new junior accountant in the team!
Fortunately, the IT team quickly came into the picture and rectified the situation. It seems the new accountant was granted full approval rights instead of limited system access and review only rights. Only Rachel and her superiors should have had access to the system to submit and supply final approval respectively. The new accountant didn’t realize he had inadvertently approved her budget when he approved expenses. This access error could have resulted in a large unauthorized expense for the organization.
These challenges, even though they have quick solutions, can cause major business problems if not rectified. Here is a negative testing technique that could have eliminated this risk.
Technique 4: Roles Authentication Validation
Use the roles authentication validation technique to validate what occurs when multiple users are logged into a system at once.
- If one role user has logged in, what happens if another role’s session URL is copied to the same browser.
- Check what happens when a role tries to exercise rights that he or she is not assigned.
Advantages of Negative Testing
Product teams working on strict deadlines sometimes skip this important process as it can be time-consuming. In such cases, historical data combined with risk-based testing can be leveraged to prioritize and accelerate negative testing.
While the techniques of negative testing are numerous, so are the advantages including providing an error-free user experience that drives high customer satisfaction. Isn’t that what quality assurance and testing is all about?
Learn more about Bridgenext’s Quality Assurance services.
