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?


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 and the WordPress apps. I spent roughly the first two years working in the 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 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 Josephus Problem: How math teaches us to solve problems

When I was in school, I always thought math word problems were a little funny. I understood that the point was for me to apply math to solve real-world problems, but the problems never felt real. However, these days I truly appreciate all of the ways that math taught me how to think about, break down, and work through problems.

Numberphile has a wonderful example of how to approach problem-solving with the Josephus problem:

These are the same skills you can use to solve a problem in support, as well:

  • Gather data about the problem
  • Look for patterns
  • Make a conjecture
  • Test your conjecture

As noted in the video, it’s also incredibly important to tackle small, discrete parts of the problem and work from there to the larger solution. If you stare at a big problem, it can look impossible to solve. But if you can prove theories about small parts of the problem, the larger solution can become clear.

Thank you to all of my teachers and others who encouraged me to learn and practice these skills — although I don’t do much pure math these days, I use these skills every day!