QA: The ugly duckling.

QA is like the gym.

We’re all trying to be our best selves. We want to be fit, healthy and looking svelt for our sultry-summery-tinder-dates. So, we join a gym. We feel unstoppable. We’re now “gym-rats” — pumping iron — ONCE a week — maybe TWICE — who is to say.

It’s now been 3 weeks since we joined (between us — our main motivation was the free pizza and $1.50 annual membership at Planet Fitness) and we somehow stop going. In our heart-of-hearts, we know we should continue but alas, we do not…

Similarly, we know we should be going to the “gym” of product development: QA. It’s vitally important for the health of our product. It makes sure our pixels are chiseled, our flows are fine, and our backend is looking taut ;)

But for some reason, it’s often the least-codified and most-overlooked stage of the product-development process. Why is this you ask? I mean, I’m no scientist but my best guess is because….it sucks. Now, this is just my personal opinion, but rarely have I seen a face light-up when chatting about QA.

I believe this is because QA is frustrating for everyone.

To take a deeper look as to why — let us slip on our teammate’s shoes…

Engineer:

As an engineer, I’ve just spent the past x-amount-of-time — sweating this new feature out. A sigh of relief fills my somber-soul as I send it off into the ether. In my mind, I have finished what I set out to do. My Kanban board is looking sexy-as-hell and I’m ready to start on some fresh — new tasks.

Oh, wait! Just joking — JK smiles. The rocks are shaking around my trembling feet. I turn around and a stampede of bug fixes are pummeling towards me — pounding their aggressive hoofs all over my innocent backlog. It’s Lion King up in my workspace.

I now have to go back and fix a LARGE number of teeny-tiny issues. I slog — one-by-one — crawling through Jira issue…after issue…after issue. The whole time, trying to reproduce and decipher what these tickets actually mean. As time-ticks-forward — I slowly morph into Tom Hanks in “The Da Vinci Code,” trying to crack the “code”… but deep down, I feel like Nicholas Cage in “National Treasure 2.”

Designer:

I’ve been impatiently waiting to see how my vector-based creations will debut on the big stage: the world-wide-web. I’ve interviewed users, slapped sticky-notes on the walls, sketched the sketches, wired the wireframes, proto-ed the prototypes, critiqued the crits, packaged-it-all-up, and handed-it-off.

And now, the moment has arrived. I get to see the beautiful creation I spent weeks perfecting. I’m thrilled. That ding and shuffle of the Slack notification rings in my ear. I race to it — with an open heart and an outstretched-arm — I click that magical staging link…

Hm…

Well…I mean it’s great…

But…it’s a little off…

Now, I’m left with one of two — unfortunate — options:

Sit next to an engineer (or vid-chat) and go through everything — pixel-by-pixel. Now, this can be great in some instances — don’t get me wrong. But, it’s also awkward-as-hell. You’re sitting over their shoulder, telling them to bump the margin from 7px to 8px. Bad.

OR, I can go into inspector > tweak an element > take a screenshot > go into Sketch or Skitch and draw all over it > save that > drag it into a spreadsheet or Jira ticket > assign it > leave a comment > repeat five thousand times. By the end, I’ve created 16 trillion tickets and feel like an ass.

So, instead, I refrain from giving all the feedback I have. You can call it a compromise but it sucks. It’s not what I designed, it adds to our ever-growing inconsistencies, and in the end, hurts the end-users experience.

I’ll stop here with the role-playing. I’ve never been a QA-tester, Copywriter, or Product Manager in any official capacity, so I won’t fumble my way through that. I do believe similar feelings apply to those roles though.

QA is just uncomfortable. Each person on the team is combing through the product — searching for discrepancies between what it should have been and what it is in reality. It can feel as if you’re grading someone on their work. Passing out the exam in front of the whole-class with BIG red-lines — marking it up-and-down…

This (to me) feels like a problem. QA is one of the most important areas of the development process. It’s the final-line-of-defense before your customers actually interact with your product. Yet, QA can feel like you’re on chore duty — dragging the trash to the curb, mumbling curses under-your-breath the whole way there.

This is a tricky problem though. I don’t have a snazzy Buzzfeed-like checklist to slap into a workflow and all will be better (at least not yet). Working with other people, communicating ideas, having a diverse and opinionated dialogue is tough — but is what’s needed to make great experiences.

I do believe, however, that there are ways to make this form of collaboration and feedback easier. Ways that can help people who speak somewhat different languages — all get on the same page.

This is the problem we aim to solve at Toybox. We believe QA should not be the neglected, ugly-duckling we don’t mention to Grandma at Thanksgiving. QA should be a topic and process that’s continuously discussed and iterated on…

— — — — — — — —

As you can probably tell, our New Years Resolution for 2019 is QA. We’ll be writing about what we’ve seen, heard, and tried to implement. Our aim is for QA to be a beautiful-duckling or Equinox or SoulCycle or whatever other workout classes that people actually want to attend.

— — — — — — — —

Thanks for reading!

If you have any ideas or QA processes that work for your team — I’d really love to hear them. If you’d like to chat — please DM me anytime on Twitter :)

P.S. if your team is looking to improve their QA process — checkout Toybox, the fastest way to gather feedback and report bugs on your site!