The best way to test edge cases?

Question

I am currently trying to improve an existing design of an Android app that has been already published.

• The current design's information architecture and design is highly influenced by web service output provided by third-parties who may or may not be prompt in making changes, or cooperative.
• The current design has obvious flaws with the current flow of the screens (e.g., asking for criteria that clearly would make the remaining controls on the page useless most of the time).
• The previous designers did not explicitly mention how to handle edge cases in their prototypes. For example, because of their decision to ignore edge cases, in the existing application, for the case of no connectivity, a simple dialog with merely a simple message, and an OK button appears only after the long connection timeout occurred. And no caching has been considered for the case at which web services fail to fetch more-or-less static information, so little has been done for preventing errors for the most used operation in the application: calling web services.
• The UI elements do not closely match with the familiar elements used throughout the OS. iOS UI standards were in mind during development.

---

I revamped the screen flow, and design with Sketch. I later converted them to lower fidelity prototypes (by making them grey scale and making elements less pretty), and sought to test out my prototypes with users. But I'm facing a problem:

• How can I test for edge cases effectively and efficiently using prototypes? I have created HTML versions (made of series of images with hotspots) of my prototypes for testing, but given the size of the application, creating multiple branches for multiple edge cases will be very time consuming. I don't find much on techniques regarding testing edge cases effectively with users.

If there is a tool made of this that would save me time (as there are hundreds of screens), that would be great. Otherwise please provide pointers on how I can effectively test my designs with edge cases in mind.

Answer 1

Unfortunately, many of these edge cases cannot be tested automatically. So an extensive manual testing is needed to ensure that the application works well.

For most business and consumer programs, the world is a better place when you handle the main case seamlessly and fix edge cases only as they arise, rather than annoying every user with every edge case that might ever exist.

https://msdn.microsoft.com/en-us/magazine/ee336120.aspx

Unless you get some responses similar to the MS Word’s auto-correct feature (which automatically converts the “hte” that I typed into the “the” that I really meant) saying, “No, Plattski, that’s a really bad feature. Sometimes you actually mean “hte,” like when you wrote that column, and auto-correct gets in the way. Word shouldn’t do that, because sometimes it’s wrong.”

Handling all edge cases might seem like cluttering your code. It will be filled with if-clasues, event handling, “retry pending” constructs, and what not.

A few quick checks you can do are:

• Test the page without CSS
• Disable JavaScript in the browser
• Test your app with low speed internet connection
• Disconnect the internet while in middle of some task, and see how your application reacts to the situation.

---

Managing Edge Cases

Having focused on rapid prototyping for most of my career, my temptation was to aggressively apply the Pareto principle; focus on the core interactions and leave the edge cases to chance, or let the developers decide what to do.