Solving Puzzles is like Testing

I have always loved a good puzzle. You know there’s a problem, and a solution, and you just have to figure out how to get from one to the other. Lately I’ve been especially enjoying puzzle games where the problem itself is part of the mystery — you’re given some information and have to figure out where to start.

My brother is especially good at finding these kinds of puzzle games. For Christmas, he gave me a subscription to Hunt a Killer. It’s a detective game in a box, but no one tells you what you’re trying to solve. You just get puzzles and clues to put together, and each month (for 6 months) a new box arrives with more details. There are “aha!” moments when you solve an individual puzzle, and the slow burn of fitting together clues and piecing together theories about the underlying story.

Another game that came from my brother is Gorogoa, a computer puzzle game with beautiful illustrations and simple yet incredibly clever gameplay. Once again, you enter the game with no idea of what’s happening, but as it continues you get a sense of the logic and storyline. This one is relatively short but full of enjoyable moments.

In many ways, this is similar to how I approach testing. I want to know just enough about what I’m testing to have a purpose, but not so much that I am just blindly following someone’s directions. I try things out, see where my intuition leads me, and watch for the places where I get stuck. I look for the story, the journey taking me from one screen to another. My challenges turn into opportunities to improve the product, and my “aha!” moments are the places where I see why I’m having trouble. In my testing I may not always arrive at a solution (although I enjoy being part of those discussions, as well!) but the satisfaction is in the hunt, in putting myself in the right frame of mind to uncover what I’m looking for.

Do you enjoy puzzles? Any good ones you’d recommend?

Advertisements

Right-to-Left Testing in Mobile Apps

Did you know that both iOS and Android have easy ways to build your apps for localization testing?

As someone who loves languages, I’m used to just switching a test device into another language for testing and dogfooding over a longer period of time. But even I get a little scared that one day I’m going to switch my iPhone’s device language to Arabic and never find my way back to the language settings. And for teammates who don’t speak another language, it can be even more intimidating. Here’s where iOS and Android come to the rescue with build options for localization testing.

Screenshot of WordPress for iOS app with RTL pseudolanguage displaying backwards English text.
RTL Pseudolanguage on iOS

In Xcode you can select a pseudolanguage in your build scheme. For regular localization testing you can choose Double-Length Pseudolanguage to see how your app works in languages with longer strings. (My teammate Eduardo also suggests using the iOS text size settings as another way to test this on the fly.) But for RTL testing it’s especially handy — choose either Right-to-Left Pseudolanguage to get an RTL layout with regular English strings or Right-to-Left Pseudolanguage with Right-to-Left Strings to see the English strings backwards in the RTL layout. Build your app and you can test out the RTL experience, no language classes required!

For Android, you can enable pseudolocales in your build.gradle file. Then, on your device or emulator, go to the device language settings and select English (XA) or Arabic (XB). (If you don’t see those languages, make sure developer options are enabled.) The first language gives you lengthened strings and all kinds of exciting accented characters, but the second is where RTL testing kicks in — you get English strings backward with an RTL layout.

Now, off to file some GitHub issues for the localization bugs I just noticed … 😉

Wrangling Excellence

Today marked a big change for me at work.

For the past 4+ years, I worked as a Happiness Engineer supporting WordPress.com and the WordPress apps. I spent roughly the first two years working in the WordPress.com Support Forums, and I found that I loved providing public support and troubleshooting the incredible range of issues that arose there. I spent the past two years supporting the WordPress apps, and over time I got more and more involved in testing them as well.

As I spent time developing on my own manual testing approach, working with beta testing communities, exploring the support/development feedback loop, and encouraging my coworkers’ troubleshooting skills, I also kept an eye on a team being formed at Automattic around automated testing and bug prioritization. I worked with and learned from them as more discussions arose around testing and quality within our fast-paced, distributed environment. And although I enjoyed helping people use WordPress, I discovered that my favorite work was helping development teams understand our customers’ needs and identify what issues most needed their attention.

Earlier this year, I finally decided to build on my existing coding skills to try my hand at automated testing. With some guidance, I developed the first suite of UI tests for a new editor (codenamed “Aztec”) for the WordPress for iOS app. Later I added a suite of UI tests for the same editor for WordPress for Android. I also worked with a coworker to automate screenshots of the WordPress.com signup flow in multiple languages, to help our internationalization team review those localized flows. Some of this work was part of a trial, as I applied internally to change roles.

That work and study paid off, and today I started my first day as an Excellence Wrangler. I’ll be automating tests, doing manual testing, triaging bugs reports, and generally helping our support and development teams communicate and prioritize to create the best experience possible for our customers.

And if that excitement wasn’t enough, I also had a delivery that I’ve been waiting on since I hit my four-year anniversary at Automattic — a new laptop with the WordPress logo:

2017-08-07 21.00.15.jpg

The Problem with Averages

If you’re interested in inclusive design, I’d recommend listening to “On Average” from the podcast 99% Invisible. From the episode:

So in 1926, when the army was designing its first-ever fighter plane cockpit, engineers measured the physical dimensions of hundreds of male pilots and used this data to standardize cockpit dimensions. Of course, the possibility of female pilots was never considered. Of course.

The size and shape of the seat, the distance to the pedals and the stick, the height of the windshield, even the shape of the flight helmets were all made to conform to the average 1920’s male pilot. Which changed the way the pilots were selected.

You basically then select people that fit into that and then exclude people that don’t.

Designing for the average and excluding anyone who doesn’t fit that average isn’t, well, inclusive. The episode goes on to discuss how design (including in the military) has become more inclusive — but it’s still something we struggle with.

From what I’ve seen in software design and development, one of the challenges is deciding which user personas and scenarios will be considered in your design, and which issues are only edge cases. Where and how do you draw that line? It’s also a matter of just remembering to think outside your own perspective, to consider cases that you haven’t thought of already. (As designer and fellow Automattician Mel Choyce pointed out, it’s about challenging your own biases by seeking out and really listening to users with different perspectives.)

As a linguaphile, I tend to notice when software design struggles or forgets to include non-English languages. For example, designs that aren’t responsive to languages that take up more space (ahemGermanahem) or that don’t consider right-to-left languages end up excluding entire populations of potential users in other parts of the world. It can be hard for monolingual designers and developers to know how their products work in other languages, and it’s always satisfying when I have a chance to test a product and suggest language-based enhancements, so people can use our products in any language. It’s one small way I can help democratize publishing for users around the world.