Fringe testing, or edge case testing, can uncover significant defects
Your testers likely cover most of the expected application functionality and workflows during a regression testing cycle. Granted, they probably don’t test absolutely every function, but they thoroughly cover the happy path — what the user sees and the application uses to perform. When QA teams are pressed for time, regression testing can boil down to only testing the main functionality within a specified workflow sequence. If you only test the main user workflows, you’ll undoubtedly leave many defects undiscovered prior to release.
Edge case testing, or fringe testing, assesses how the application works when you go off script. Fringe testing can include testing out of sequence, twisting the expected workflow, or discovering functions the application performs that it was not designed for. When you test edge cases, you’re using creativity to get the application to perform functions it’s not intended to do, and figuring out the results.
The idea here is simple: human beings, as a whole, rarely follow the rules. This is why you need edge case testing to validate beyond the planned path. Because, rest assured, people will certainly stray from that path.
Edge test case scenarios are those that are possible, but unknown or accidental features of the requirements. Boundary testing, in which testers validate between the extreme ends of a range of inputs, is a great way to find edge cases when testers are dealing with specific and calculated value fields. However, testers find edge case defects most often when creatively testing the application and its integrated components in an end-to-end or system test method. It’s like exploratory testing the system end to end, including all of its integrated parts, like the API connections, database, and messaging systems.
But there’s a downside to testing for edge cases. Edge case testing is not easy, and it does take time. Let’s discuss how to find, prioritize and test edge cases in an application to expand coverage beyond the happy path.
How to find edge cases
How does a QA tester identify edge test cases, or find edge case defects? The best advice is you find edge cases by looking for them. Basically, testers use creativity and critical thinking to find edge case defects during any test cycle — regression, functional, or at any point in the development cycle. Testers try to find edge cases all the time, or as much as they can spend the time on — that’s the reality. Once the application system is connected and developed enough to do an end-to-end test, testers should plan some time to find those hidden, often obscure edge test cases.
An experienced QA tester can instinctively find where the application tends to fail, especially the longer they test a system. Additionally, the more they understand the customer workflow, the better equipped they are to find edge cases.
Testers often find common edge cases in familiar places. Think integration points where the application saves to the database or processes incoming data from messages. How else can they find edge cases? Think about what the customer uses the application to do, then consider how to perform the functions without following the expected path. Better yet, how can they use that function to have the application execute an entirely different, or unexpected scenario?
For example, let’s say your application processes income tax forms for residents in the U.S., France, China, and the U.K. There are then four distinct sets of tax rules and calculations, one per country, and additional rules per state or area. Now, say you go in and edit the tax rules for the U.S. and manage to create a totally new country with a new set of rules, but using the existing dataset of customer accounts. You set all user accounts on the system to pay their dividends to your offshore bank account. While this is an extreme example, if the test proves successful, you just found a significant security edge test case.
Many edge test cases are smaller or less significant. Sticking with our security-based example, say you’re testing the login workflow for a user to access their tax account. Think of yourself as the U.S. customer whose work involves keeping the tax rules updated with the latest changes. You are authorized to only view the U.S. account. You log in with a valid username, but enter an incorrect password. The system displays an invalid login error. Here are some questions that might explain how to find edge case defects for this example:
-
Can you double-click on the frame of the window and circumvent the login?
-
If you click quickly several times outside the login window, or on the edge of the screen, can you gain access without logging in?
-
Once you login, do you have access as a system admin or super user?
-
If you’re logged in as an admin, do you now have access to all accounts?
How to prioritize edge cases
Once testers find edge case defects, they must prioritize them for triage. Typically, the organization prioritizes edge case defects slightly differently than defects reported during a regression testing cycle. In the previous examples, we are testing security and authentication — any possible way I can attempt to get around it directly within the UI. You might find and test edge case defects anywhere in the application workflow. To effectively prioritize edge case tests and defects, consider how often the issue is found, as well as the potential business outcome for your company and your customer.
Think about our previous examples. If I can circumvent the login process using the UI and gain access to all accounts, that’s a significant defect that the organization would have to address immediately. But less-severe edge test case defects might not get fixed in the code right away, especially if the product or development team does not believe someone would actually follow that path. This is why prioritization is so important — severe edge case defects must be fixed immediately, but minor defects might be put on hold.
Edge test cases are difficult to defend because they are uncommon or unexpected. However, the organization should review and prioritize edge cases not as if they are an uncommon occurrence, but as a defect that will occur at some point, depending on the craftiness of the user. Maybe they don’t click around and go outside the workflow. But what if they do? Hackers spend a great deal of time testing edge cases and exploiting defects. They test all aspects of a system that no one considers important. If you want to keep customers’ trust in an application, edge case testing is a high priority.
Remember, too, that you can find edge cases at the device level. There are many Android variations, so edge case defects will exist on one version, but not another. When it comes to prioritizing edge cases, consider which devices your users own to make a decision on whether it’s worth the effort to fix that bug. There are simply too many device/OS combinations to address all defects at once, so a prioritized approach is necessary.
In short, don’t ignore edge case defects. Work fringe testing into your overall QA plan.
How to test edge cases
Developing tests for edge cases fits naturally with other forms of test development. The difference is that you must allow time for QA testers to use their creativity and imagination to test off the happy path. Prioritize edge case test execution and mix it in with your regression tests, or, if time does not allow, you can assign part of the QA team to execute the tests post-regression. Wherever you test edge cases, they are a critical aspect to include in an overall QA testing plan.
Edge case testing is difficult to do. The fringe testing process requires time, thought, creativity and exploration. However, keep in mind that edge test cases represent what users do to manipulate your application — intentionally or not — which might gain them unauthorized access to data and systems. It’s not only about security; consider an edge case defect where it’s very difficult to scroll without accidentally pressing a button. That’s not about malicious intent, but it’s a poor experience that will drag down customer satisfaction and loyalty. Think like a customer or a hacker; that’s how to test edge cases and uncover defects. Fringe testing requires patience, but it’s critical to an application’s success and your business to ensure edge case tests are developed and executed.
If you can’t test edge cases internally, you can choose a software testing partner you trust to efficiently and securely handle this task. Applause provides software testing services and solutions all throughout the software testing life cycle to ensure organizations provide exceptional digital experiences. As it pertains to edge case testing, Applause’s global community of digital experts can track down defects within the scope you define, on the devices you prioritize, and validate that apps deliver a secure, consistent experience for users.
Ultimately, organizations test an application to provide high-quality experiences for customers. To retain trust, testers must validate that an application can perform both the standard workflow and all possible edge test cases that otherwise harm the application or expose customer data and systems. Testing edge cases is worth the time spent for the business and its customers.
https://ift.tt/3ulaEFp
Case
No comments:
Post a Comment