Two months ago, Matt Heusser organized Test Retreat and I attended, along with 27 other testers open to new ideas and wanting to change the world. Sound a little ambitious? Let’s find out!

My first blog post in this series is about Michael Larsen‘s Testing For Humans, which he was unable to live blog due to presenting. 🙂 However, Michael did post Alessandra Moreira‘s notes in his live blog of the event.

Fortunately, I was able to live-tweet the talk that he described as:

Testing for Humans: It’s Sticky, Messy and Very Satisfying

Abstract: Software development is a beautiful thing. We often create amazing ideas and features that would be wonderful… if only those pesky humans that end up using, abusing, and mis-understanding our brilliant code weren’t part of the equation. Unfortunately, we’re all in the business of developing software for people (yes, even when it’s machine to machine communication, it serves human beings somewhere. What are some ways that we can approach testing software outside of the theoretical ideals, and actually come to grips with the fact that real human beings will be using these products? How can we really represent them, test for and on behalf of them, and actually bring in a feature that will not just make them happy, but represent the way they really and actually work, think and act?

Expected Deliverables: An excellent debate, some solid strategies we can all take home, and some “really good” practices that will be helpful in a variety of contexts.

My take-aways were:

• People are imperfect so ideal users aren’t enough for testing.
• By definition, a composite of many people (e.g. user persona) is a model.
• Too many user descriptions based on small differences is overwhelming, not practical for testing.

On Wednesday night of this week, I joined Christin Wiedemann‘s regularly scheduled Skype test chat with some other lovely wonderful tester folks and we focused on empathy in testing. We wrestled our way to some working definitions of empathy and sympathy, which was much better than shallow agreement though it took a bit of time to establish. We agreed that testers need to observe, focus on, and understand users in order to serve them better. We find that empathy for our users and passion for our testing work go hand-in-hand since we care about helping people by producing good software.

Then we struggled with whether empathy is an innate trait of a person testing or whether empathy is a learnable skill that testers can develop through deliberate practice. (Go watch the video behind that link and come back to me.) We concluded that knowing what others are thinking and feeling, getting inside their skins, in the context of using the software is essential to good testing, though this might require a bit of perseverance. This can go a long way toward avoiding thinking we have enough information just because it’s all we know right now.

As I mentioned in the chat, I’ve found that user experience (UX) design is an amazing ally for testers. One tool that helped me to develop more empathy for my users is user personas. (Later, I found that forming user personas of my product teammates helped me to develop empathy for them as well.)

I immediately took to (end) user personas as a natural progression from user stories. After all, user stories are focused on value to and outcomes for a particular group of users. Describing those users more specifically in a user persona dovetailed nicely. Rather than some sterile requirements that never name the user, identifying a role – or, even better, a rich symbol such as a named primary persona – focuses the product team’s efforts on serving someone by helping us to understand the purpose of the work we do.

We also discussed interviewing users, visits to users, and experiential exercises as techniques to help us call upon empathy when we are testing. In my work history, I’ve been fortunate to hear about my UX team’s great work in a collaborative design workshop, to contribute to designing ad hoc personas for my product, to participate in a UX-led contextual inquiry, and to log actual usability sessions led by my product team’s UX designer. (Yes, my fast fingers came in handy. Yuk yuk.) My innovation days team developed a usability logging product that evolved from an existing solution I tested/used in those usability sessions, so I was a natural fit to test it. I’m curious about empathy maps but haven’t tried them myself yet.

It’s fair to say I’m a UX-infected tester. More than fair. I identify with the curiosity I see in the UX profession and I admire the courage to kill their darlings (carefully crafted designs) when evidence shows it is time to move on. After all, we’re not building this product to marvel at our own cleverness but instead to serve humans.

Image credit