stress cases, pt. 2: peppy messaging

I wrote about stress cases a couple months ago (, and since then, I’ve thought a lot more about stress cases and given a keynote at Agile Testing Days USA about them. (It was a great conference, and I’ll write about it another time.) I thought I should flesh out some of the ideas here too. Today’s topic is peppy messaging.

When we talk about stress cases versus edge cases, we look at the impact on a person, rather than just the steps that got them there. We look at how a person under stress could be frustrated by our product, and how a product can cause additional stress to a person.

One way that our products can cause stress to a person are through peppy messaging. For instance:

This man had written a tribute to his recently-deceased friend on Medium, a blogging site, and he received an email with “fun fact: Shakespeare only got 2 recommends on his first Medium story.” This may be appropriate in some circumstances, like people talking about skateboarding or the antics of kittens, but there are many circumstances where peppy messaging is inappropriate.

We know, generally, the pain points people are trying to solve when they come to our products. We should not be causing unexpected pain in the form of peppy messages. Companies do not need to show off personality or quirkiness in their messaging.

So… how do we test for this?

Read all your copy out loud. All of it. Grab a colleague and have them frown at you. Have them imagine that their dog just died if they need to. If you can read all your copy to a frowning colleague, then it’s okay to put in your product. If it makes you uncomfortable to say it, or if your colleague looks taken aback, rethink the copy.

If you have bad copy, advocate for better copy. Be bold, tell a story about a person who could be affected by it, and make sure the extent of the hurt it can cause is understood. As testers, we are situated in a place where we see things at the beginning, the end, and all the middle places (hopefully), and we have a critical eye that notices things. We can, and should, advocate for better messaging.

So this was round 2 of stress cases. I’ll keep writing about them.

virtual reality testing (stay tuned)

I was in Reef Migration, a virtual reality experience for the Vive, and it got me thinking about testing virtual reality. (A video of Reef Migration is here.) Reef Migration is one of three underwater VR experiences in TheBlu, and the others have a blue whale and then angler fish at the bottom of the ocean. They’re all visually compelling. This one has you on a coral reef, and sea turtles, jellyfish, and lots and lots of fish swim by. You’re surrounded by anemones and coral, and the sun shines down through the water. It’s beautiful but buggy.

Unlike TheBlu, which is visual only, in Reef Migration, you can interact with the environment, notably by punching jellyfish and tickling anemones. It’s certainly entertaining. However, the jellyfish don’t always respond as expected, and a couple times during a session, fish will glitch out and entire schools will suddenly be several feet away from where they were before. Sometimes fish move through you instead of around you.

This has my testing instincts buzzing. How do we test virtual reality? For games, is there much difference from regular game testing? How much does network speed affect the level of bugginess? What are the weaknesses that are common to all VR experiences? How is augmented reality (AR) different?

I’m going to find out. I’m thinking of getting my testers at work involved in this too as fun skill-building. Keep an eye on this space for this new avenue of exploration!

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!

new board games rundown

I spent the better part of five days last week playing the newest board games at a convention in Seattle. It was quite a change from the board game convention I usually go to, where players have about 40 hours to get through at least 30 games. This one was more relaxed time-wise, but the games were considerably more intense. I played a lot of “heavy” games, which took up to about five hours for one game. Altogether, I got through 27. The games were of a much higher caliber than my other convention too, so that made me happy.

Here’s the rundown of the games I played:

Gùgōng – Players swap cards with the board to take actions, including moving on tracks and placing workers. The play mechanism is straightforward, and there is enough variety on the board to keep any one person from getting too far ahead.
Underwater Cities – Players build… underwater cities. Those cities need to connect to the main city to score, and they can have buildings around them that provide additional resources. People were comparing it to Terraforming Mars, which I’ve never played, but I thought it was a good game with a lot of strategy.
Barrage – We played a demo copy of this game, which is currently on Kickstarter. The game is based on hydroelectricity, and players build dams and equipment, release water, and fulfill contracts requiring a certain amount of energy. This game was built around the theme instead of the other way around. Each player has a different board which optimizes a certain mechanic. One guy kind of ran away with it towards the end, but I think it would be more balanced if the rest of us had figured out our boards faster. I really enjoyed it, but our game was easily five hours to play. I think future games will go a lot faster.
Obsession – This is set in Victorian England on estates. People who don’t differentiate between centuries say that it’s Downton Abbey in boardgame form. Play takes place over sixteen rounds, four of which are just scoring rounds (“courtship” phases). Players try to increase their reputation, throw the best parties with the best guests, and build the best estates. The rules are a little dense and sprinkled across two rulebooks, but I thoroughly enjoyed the mechanics, and the theme is awesome. The downside is that luck can vary wildly in one of the decks, but the game designer took to BGG to offer up variants that mitigate the luck.
Tsukiji – Players wager to determine the market price of different kinds of fresh seafood, and then buy seafood to sell at the end of the game. It took us a couple rounds to figure out the strategy behind the wagering, where you can end up manipulating the price to increase or decrease victory points that each type will be worth at the end. It’s a light game with a lot of replay value, I think. I really enjoyed it.
Concordia Venus – It’s been many years since I played Concordia, and that was only once, but as we were playing this new game, I had a hard time thinking of how it was actually different from the original. It was fun enough, and I would definitely play again. I probably don’t need to add this to my collection though.
8Bit Box – The theme of the box is playing video games, and each game is a different one. We played 8Bit Pixoid, basically Pac-Man. One player played Pac-Man, the others ghosts. It was cute and light, and the design elements are really nice. Players use consoles with which they program movements. I don’t think I need the game, but I enjoyed it.
Fuji – This is a cooperative game where players are trying to escape from an erupting volcano without getting in each other’s way. We messed up a few times, inadvertently preventing each other from moving, but we won in the end. Like other co-ops, there are different levels to increase or decrease the difficulty.
Cerberus – This is a semi-cooperative game where you’re trying to escape from Hades. Players try to advance themselves and each other and fend off Cerberus, but if they’re caught, they become a servant of the three-headed dog and try to get the others. I got to play a corgi, complete with corgi meeple, and I was the first to fall. It’s a unique game, and I thoroughly enjoyed it. This would also make a good drinking game.
Cupcake Empire – So pink. So cute. I managed to get three guys to play with me, one of whom wanted to hide the rules so no one would see the pinkness. The play is straightforward, and there’s more strategy than luck, which is nice. It’s a very cute but surprisingly in-depth game that I would recommend if you like the theme.
Architects of the West Kingdom – Players collect resources that stack based on how many workers they already have there, and then use those resources to build cards out of their hand or build on the cathedral. It’s a fun game with a unique mechanism in how meeples are removed from the board. I’m not sure I need the game, but it was really good.
Symphony No. 9Players are patrons of musicians, trying to get compositions and have composers’ works performed. It’s a wagering game, with some backstabbing elements. I was really excited about the theme, but the game ended up not being as great as I wanted it to be.
Men at Work – Players are on a construction site, placing workers and girders. If a player causes an accident, another one cleans it up, hopefully without causing another one. It’s a dexterity game, and I dislike dexterity games.
Solenia – Players place their cards next to an airship that moves periodically. The game board itself moves after every turn. Players gather resources and fulfill contracts. It’s a simple game that moves quickly, though that means the board is in constant motion, which can be annoying. It was an okay game, but I wouldn’t play it regularly.
Forum Trajanum – Players compete to build their own Forums (Fora?) to meet conditions, gain area control on a central board, and hire workers to help boost their actions. It was a fun game, quite engaging, though it moved a little more slowly than I like. We did realize a couple days later that we had a rule wrong, and so we should have had a little more flexibility. I’d play it again, gladly.
Azul: Stained Glass of Sintra – Similar to last year’s hit, Azul, in Sintra, players collect colored squares to fill in stained glass windows this time. The catch is that the glass can’t just go anywhere, and it can take a turn to open up spots. It’s plenty of fun. I don’t need both, and honestly, it’s a toss-up as to whether I would recommend going with the original game or this one.
Captains of the Gulf – Players are shrimp boat captains in the Gulf of Mexico. This game makes it clear that the life of a shrimp boat captain is hard and frustrating. And possibly painfully slow-moving. The rondel was probably a pie wedge too big, the pie wedges were oddly ordered, and it was hard to get anything done or purchased. I don’t want to be a shrimp boat captain, IRL or in board game format again.
Railroad Ink: Deep Blue Edition – Players draw highways and railways with dry-erase markers based on the faces of dice, and the player who connects edges, makes continuous paths, and other such things wins. It was a different kind of game that was a nice break from the heavy Euros.
Dice Fishing: Roll and Catch – This was a cute wagering game with dice. Players bid how many dice they require to meet a condition (catching a fish might require a total of 13 with one of the dice being a 5), and the person who bids the fewest dice gets to try first. It was fun and quite light, though requiring at least a feeling for statistics, if not a full grasp.
Valparaíso – Players are based in a main city, where they can build for bonuses, travel for trade, and ship goods for permanent benefits. We weren’t sure if we were playing the game correctly by the end, because I ran away with it, but… well… I enjoyed running away with it. 🙂 It was a fun game where victory points are very hard won (18 triggers end of game), and I would definitely play this again.
Arraial – This is tetris in board game form. I think people liked it, and I don’t quite understand why. Players take pieces and try to place them to complete rows, gaining dancers if they do so. I don’t know what would make this fun.
Teotihuican: City of Gods – This is a heavier rondel game where players age their workers (dice) by having them gather resources and perform actions like building a pyramid. There were so many rondels this year (if you need info, here), but this was a good one. It’s apparently a lot like Tzolk’in, but without as much emphasis on the tracks. I enjoyed it quite a bit, but it’s not a board game I need.
Mesozooic – Players are building a zoo with dinosaur enclosures and topiaries. Players draft cards, then shuffle them and place them in front of them. They then have 45 seconds to rearrange the cards to create scoring combinations. It was a fast-moving game that I mostly enjoyed, though it’s a little bit of dexterity and spatial reasoning, which are not my strong suits.
Reykholt – Players seed, harvest, and collect vegetables to advance along an Iceland tourism track. This was a gentle and sweet game, and it’s vegan, if that’s your thing! No slaughtering of animals here. The pieces are really well-made, and the artwork is simple and nice. I really liked this lighter game, and I hope to add it to my collection.
Altiplano: The Traveler – It was my first time playing Altiplano, and we played with this expansion. It adds a traveling meeple that gives additional actions to the base game. I really enjoyed the game, though I don’t generally go for expansions. I’m not certain the expansion for this is necessary, but if you play the base game a lot, it could be a fun addition.
Chartered: The Golden Age – We got to play a demo copy of this game. Players build warehouses for goods, buy stock in different goods, and try to merge warehouses to get payouts and make stock more valuable. It seemed pretty unbalanced, and the person who won doubled nearly all of our scores, because he got lucky at the right time. I don’t plan on backing this or buying it.
Blackout: Hong Kong – This is a deck-building game and area control game. Players are trying to hire workers and dominate areas of the board to gain victory points and such. It was really popular at the con. I liked it well enough, but the theme was completely irrelevant and didn’t make much sense with the game mechanics. And the more I think about it, the less I liked it. It’s apparently a lot like Mombasa, another Alexander Pfister game.

So you may be wondering what came of all of this. Here are a couple of lists. These are just my opinions, and they don’t necessarily track with the hot games at the con.

Games I Want to Buy (Soon):

  • Barrage
  • Underwater Cities
  • Tsukiji
  • Obsession
  • Gugong

Best Light Games:

  • Cupcake Empire
  • Dice Fishing
  • Azul Sintra
  • Cerberus
  • Reykholt

Best Heavy Games:

  • Barrage
  • Gugong
  • Teotihuacan
  • Altiplano

Let me know your thoughts!

pair testing adventures

Last week, I finally did what I’ve been wanting to do for months (years) and engaged in pair testing three times with some differing results.

what is pair testing?

Pair testing is a lot like pair programming, where you have two sets of eyes and two minds engaged in the same problem. There can be a lot of benefits to it (Lisa Crispin talks about it here), such as increased creativity, better quality, and more exploration, but, just like pair programming, it can be difficult to start and requires a lot of focus and energy. I wanted to learn strong-style pairing, as it seems to involve the most engagement from both people.

learning with Maaret

First up was a lesson with Maaret Pyhäjärvi, and absolutely amazing and well-known tester who publishes and speaks on testing regularly. I had confessed to her that most of my bugs feel like the result of serendipity rather than skill, and I told her that I wanted to work on my exploration as well as pairing. She was kind about it, even writing a post about serendipity.

We started at 7am my time, and for the next hour, we talked and tested a “simple” application that consisted of a text box, a button, and text outputs. As we tested, we talked about assumptions, tools, resources, and how outputs are inputs and can be manipulated (using tools or fiddling with the html itself).

Maaret taught while she tested with me, and, I have to admit, I was rather star-struck and honored that she gave me her time (do I sound too much like a fangirl?). It was a wonderful experience, and I left for work on a high that lasted all morning. I felt energized to bring what I had learned to my team at work immediately, and I convinced the other tester on my team to pair test with me in the afternoon.

practical application

In spite of the high from the morning, work was not stellar that day, and by the time the afternoon rolled around, I was slightly grumpy, my normal afternoon walk with a colleague-turned-friend had been canceled because of meetings (and I guess I was reluctant to go alone for no good reason), and I was low energy. But I decided to push through it and pair test with my colleague.

It was rough. I did a poor job of explaining why I thought we would do a better job testing together. It was a form in one of the features I’m responsible for testing (which is a topic for another post), so we tested inputs and buttons. I felt like I was generating all the ideas, and though I was trying to nudge towards more creativity, the testing felt flat and generic. When I asked what my colleague thought about it, the response was, “I think you could have done the same work on your own and much faster, and because we have a deadline, this wasn’t really a good use of time.” I came away from that experience disappointed and disheartened. (Maybe I’m too easily swayed by experiences and need to work on emotional resilience, but that’s a different post as well.)

a “stop” with Lisi

Anyway, not one to be defeated by something, I had signed up for a “stop” on Lisi Hocke‘s testing tour. Saturday morning, I worked with her for 90 minutes, and it turned out amazing as well. We tested a sketching program, an application neither of us had seen before. We started out broadly, exploring what happened with various features, and focusing for probably 10-20 minutes on areas where we saw weird things. We talked the whole time about what we were seeing, both unexpectedly positive things and “weird” things. It started out looking like a good application that I might consider using, but then we saw the save function, and that made the entire thing seem like a terrible user experience.

I liked the positive energy that both of us had, and Lisi is such an engaging person. I also liked that we used a timer to switch off who was driving and who was navigating. We had 4 minutes at a time before we switched. It relieved a lot of the pressure, because towards the end, as my mental focus was waning, I knew I just had to think of ideas for another minute or two before I would get to drive and let Lisi tell me what to do, which then opened up new areas for exploration and such. I felt like we were really working together, and I felt the benefits of pair testing in a new way.


I think one big difference was that Maaret and Lisi are so experienced in pair testing that they made it easy to include me and guide me when I needed it. I’ve now done it formally a total of three times, and for one of those, I was the one responsible for keeping the energy up and extolling the benefits of it. That was rough, as I am both inexperienced in the practice and somewhat insecure about my own testing abilities, and thus apprehensive about letting colleagues see what I perceive as my ineptitude.

One thing that I have been unable to figure out is how to effectively take notes through a mind map when we’re working on the same machine. I didn’t want to interrupt the flow of the session to work on the map, but I also didn’t want to just write down notes on paper and then have to transcribe those into a consumable digital format later. This will be something to experiment with.

Next time, at work, I will use a timer and not be so timid. I may also press for testing together in the morning, before the day has a chance to get to me. I’ll be more attuned to my mood and energy, and I may try to write down some ideas before we start so that I at least have some direction or goal for things that really have to get done, not just areas that seem neat.

All in all, I’m really glad that I finally dove into this. I’m proud of myself for asking for help and for trying something new, and I want to continue learning and experimenting. Stay tuned.