stress cases, pt. 1

Stress cases acknowledge the human element of using our software. Often, we say that something is an “edge case” or a “corner case”, which really ends up meaning that we don’t want to fix it or won’t fix it. That’s fine for some things, but when we consider whether it’s a stress case, as in, a person under stress trying to do something with our software, those “edge cases” transform into real use cases. Edge cases are marginal uses of our software, but stress cases recognize that people are not marginal.

An example: ride-sharing apps probably don’t consider what happens when the user has low battery. It’s the user’s problem, right? But it’s not really an edge case to need a ride late at night when your phone has been discharging all day and is low battery. If you’re in an unfamiliar part of town at 2am and have less than 10% battery, do you want to see what’s new, or do you want to get through the flow as quickly as possible to allow you to get home safely? This is not an edge case, but a stress case.

Sara Wachter-Boettcher and Eric Meyer have written some absolutely fantastic material on this. One of their books is Technically Wrong, another is Design for Real Life. In both, Eric recounts his harrowing experience with Facebook’s “Year in Review” in 2014. The essay can be found here. In short, he was confronted with the face of his dead daughter in his “great year” worthy of celebration. Other people saw sonograms of miscarried children, posts about breakups, pictures of house fires.

Facebook assumed, that first year, that everyone had a good year, that their most popular posts were positive ones, and that they wanted to remember the year. These three assumptions were faulty, and forcing celebration on people left them feeling bruised and hurt. That’s not a great way to go about creating software.

Identifying stress cases helps everyone, much in the same way caring about accessibility helps everyone. When we acknowledge the human element, and when we plan for that in our software, we build better software. Identifying the stress cases adds information to the conversation and unleashes creativity in problem-solving.

So what can testers do? It’s hard, but gathering the information is important. When we are stressed out, our cognitive function is diminished. We don’t think as clearly, and our fine motor skills are less accurate. Put yourself under stress before you test something. If you have a hard time getting up in the morning, set an alarm for 4am and do your testing then (record it if you don’t think you’ll take good notes). If you don’t like math, do twenty minutes of hard math problems before you start testing. If you’re prone to anger, go argue with someone on the internet… or read the comments on, well, anything. The point is to put yourself in a position where you aren’t thinking with a clear head. Make sure your flows make sense at that point, that your buttons are big enough, your text readable, and your interruptions not maddeningly intrusive.

People will use our software on really bad days, possibly on the worst days of their lives. We don’t know who just had to put down their dog, or who is worried about a diagnosis or their personal safety. But someone probably is using our software when they are severely under stress. If we assume someone is having a bad day and still needs to get things done with our software, we make it better for everyone.

This is the first of what I hope will be many posts on this topic. If you’d like to hear more, check out the Testing  Show’s April podcast, come to Agile Testing Days USA, or stay tuned here!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.