Tag: software testing

Wrangling Excellence

Rachel4 Comments

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

Advertisement

The Problem with Averages

Rachel4 Comments

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.

Embracing Openness

Rachel

An exciting part of working at Automattic is the open source philosophy. It’s thrilling to help open source projects like Calypso (the new WordPress.com), even in a small way. I spent a chunk of time last year reviewing open bug reports, enhancement requests, and the like before the project was open sourced — it’s fun to see (and help with) new issues that come up as more people work with, get inspired by, and contribute to Calypso.

Open source isn’t just about developers, either — I do a lot of my day-to-day work in the open. I used to mainly provide support out in the open, helping users in the WordPress.com forums. These days I spend most of my time in the WordPress app repos, reporting and testing issues in the open there. (If you’d like to get involved, I also started posting calls for testing the WordPress apps over at Make WordPress Mobile.)

In the spirit of open testing, Automattic also recently released the WordPress.com Automated end-to-end tests into the open. I’m so glad we can share the awesome work that our QA and testing folks are doing. I’d also highly recommend checking out my coworker Alister’s blog WatirMelon for more testing talk.

Openness can really be part of everyone’s work — from open source, to open testing, and open support. Being open helps us learn from each other, inspire each other, and keep us aware of and oriented toward the wider community in which we work.

Multilingual Testing

Rachel

As a polyglot and a former translator, I am a huge advocate for software localization, which also means testing software in multiple languages. Code that works flawlessly in English can totally break down in another language — whether it’s due to missing translations, translations that don’t fit into the space provided by the UI, or bugs that only pop up in other languages. (I found examples of all three while testing the WordPress apps today.)

But that’s not the only reason I like testing in other languages. As soon as I switch to one of my non-native languages, I’m forced to slow down and take a fresh look at the interface. Is everything where I expect it to be? Am I seeing what I’m supposed to see on this screen? Do all the buttons work the way they should? Working in another language can help you look at the software with a fresh set of eyes and find bugs that occur across languages — even in English.

Give it a try! Pick another language you speak — or one you’re trying to learn — and use it while you test. I’m trying to spend at least one day a month using WordPress.com and the WordPress apps in another language. It’ll help my testing, and I’m sure it’ll also help my language skills. 🙂