To do QA well, you need to do more than just QA
To be great at QA you need to be a CEO, Product Manager, Designer, and Developer. Why? Every feature is a multi-disciplinary effort, and each piece equally benefits from testing.
Well shit, my job just got a lot more difficult. I didn’t realize I had all that work to do. My first act as CEO should probably be to fire myself. Before that, let’s ponder a bit.
Why is this important, if QA’s job is only about ensuring quality? The answer lies in a game we all played as children: broken telephone.
The game starts with a thought. One child whispers it to another participant, who in turn whispers it to another, who in turn... etc.
A round of broken telephone ends with a comparison of the original thought and the most recent whisper. Almost always, the thought mutates and transforms through the repeated whisperings.
The workplace version of broken telephone often looks something like this: CEO’s vision > product > design > development > QA.
Frustratingly, as adults we’re still just as likely to fall out of sync as the kids. Don’t believe me? Try playing a quick round of broken telephone with your office.
My life as a faux designer/PM/developer
Prior to Rainforest, I QA’d a mobile messaging app. It was a great experience, and the first that taught me the necessity of stepping beyond being the world of QA.
Android, iOS, and Windows all live in their own distinct universes. Working on mobile, I quickly realized how important it is to know the ins and outs of each platform. How did I do that? I read the design guidelines. I built silly projects using the “getting started” guides for developers.
This was immensely useful. Building a mobile messaging product, we’d often bump into feature requests like “Can we add badges to the iOS and Android apps?” Sure we can, but first… – what’s a badge?
If you use an iPhone or iPad, you’re probably familiar with badges. Imagine your Home screen. See the tiny, numbered, red dots on your app icons? Those are badges. In Android? I wasn’t so sure. I asked around.
I found designers used the word “badge” to mean both the red dot and the default profile picture for new users.
To developers, a badge is just the default profile photo. Uh oh, broken telephone.
Fixing the telephone
There's a way to identify and short circuit this type of confusion: context. Learn a little bit about every domain.
I'd read through both iOS and Android's design guidelines. With that context, it's easy to spot the disconnect over the word badge.
"So, to be great at QA I need to be great at all these other jobs?"
If you’re anything like me, you’re quite bad at all of the above. So, why try?
Being bad is infinitely better than not trying at all. Bad gives you a shared language. It provides context. It triggers alarms when you see something that doesn’t quite match with best practices.
Being bad, more often than not, is good enough.
Let the learning begin
Context! Let's get some. Here are a few links that helped me step into the world beyond QA.
The only caveat: be patient. You won’t learn it all in a day.
“Good designers copy, great designers steal” A high-level take on where good design comes from. My takeaway from this? When QA’ing design, look for consistency.
Android Design Work on Android? Your app should probably follow these guidelines. If you diverge, there should be a good reason.
iOS Human Interface Guidelines The same goes for iOS. If you’re working on an iPhone app, you should probably adhere to these guidelines. If you don’t, have a good reason.
“Good Product Manager/Bad Product Manager” Ever wonder what a product manager does? I sure have, and I’ve been working with them for years.
“No Silver Bullet” A high-level philosophical look at how software is built. Is it even possible to ship bug-free code?
“Out of the Tar Pit” What should your engineering infrastructure look like? What principles should we adhere to? “Out of the Tar Pit” is an opinionated look at what works and what doesn’t.
The Twelve-Factor App Strong opinions on how your apps should be built and deployed. A great read if you struggle with faulty test environments.
Codecademy Don’t know how to code yet? Mosey on over to Codecademy. They offer a gentle way to ease in.
Learn Code the Hard Way Don’t let the name throw you. Zed Shaw’s guides are actually quite easy, and pleasant to step through. If you prefer nitty-gritty details as you learn, give these a look.Filed under: qa and testing