June 6, 2014
When I became a software tester in Zula, the app wasn’t yet released, and the job description was simple enough – play around with this app on your phone for a bit, mention if something looks wrong to you, and get paid for it. Summer jobs this easy don’t just fall into your lap very often, so I took it. That was almost one year ago.
I now realize how fortunate this decision was. I had been given the rare opportunity to get a peek at what a real app, a full product aimed at an audience, looks like in the making. Zula has come a long way since the first bug I discovered, and I sometimes find myself stumbling onto historical screenshots of the app and saying, “Wow! This was so different back then!”
One of the exceptional things about working in Zula (and you’ll hear the same thing from other employees) is that the product is aimed at the exact type of work that goes into making it. This means that a lot of things that normally require external tools, which might be a little clunky sometimes, become incredibly streamlined: were you just greeted by a big, smelly bug when opening some drawer? No problem, just snap a screenshot, slap it on a post in the space dedicated to test work, and ping the dev you think is to blame. This immediate access often gets things done quicker and more effectively.
Bugs are pretty complicated beasts, and software testers know this just as well as entomologists. When you find one, you have to study it as thoroughly as you can, and bring back a report with as much detail as possible. That makes it easier for the coding folks to find where it’s hiding, and root it out quickly and painlessly. That means spending time to study the bug in it’s natural environment, and trying to answer questions about it: where can you find it? When does it come around? What do you need to do to see it?
Sometimes this is as simple as “In any Event screen, anytime, look smack dab in the middle.” But that’s the best case scenario. A lot of bugs barge into your life in a storm, and leave behind more questions than answers; they can cause many days of frustration and disappointment as you chase your own tail trying to make it happen again, but never seeing anything wrong. Turns out there is such a thing as “too perfect!”
Of course, Quality Assurance isn’t just about bugs – it’s about quality! This means the QA team has to make sure everything in the app behaves just right, with no nasty surprises or weird behavior that would confuse or get in the way of a normal user. Again, Zula’s nature makes it much easier to pretend to be a normal user compared with other tools, because Zula addresses such a fundamental need: a continuous and accessible stream of communication, a way to share with others your words, your eyes and as many of your senses as can fit in your pocket (and a few megs of data), and to get the same thing in return- all toward the goal of transferring what you have in your mind to reality. When a rough edge in the app makes it hard for someone in the team to do this, he or she can just use the app to express it. An interesting thing Zula does to extend this to the users is giving them a “support space”: when users see something they don’t like, they don’t need to open a support ticket for it somewhere – they have this space available to them from the moment they sign in, and it connects them directly to the Zula team for quick feedback and help.
Working in Zula is a great working experience, both because of the team and the product itself. Beyond that, it’s an absolutely fascinating exercise in design, innovation and the way they serve one another, and an exciting chance to participate in creating something that can change the way we communicate and what we experience when we Team Up!
– Amit, QA