Quality Assurance. QA. Two letters which may strike fear into a developer’s heart. The knowledge that someone is rigorously testing the App that you’ve built, creating more work for you, getting some sadistic joy in finding problems with your code…
I’m going a little overboard here but you get my point. Not everyone is exactly excited about testing software after it’s written, but that’s my job. And I love it.
QA for me isn’t just about finding bugs in some code. In fact, that’s my least favourite part about it. As much as our amazing devs at PaperKite (PK) might appreciate what I do, I hate having to tell them that there’s a bug. They then have to redo a portion of their code which may have taken weeks. No, the parts of QA that I love doing are more involved in the Quality side of things, by asking myself: “Is this App a Quality App?” The difference between a good product and a great product is ingrained in how the user experiences it. If they like it, they will keep coming back to use it again and again.
What keeps a user using your app?
Let’s take two imaginary bits of software, and call them App Q and App A (I’m an analyst, not a creative consultant). Q and A both do the exact same thing, whatever that may be — they came out at the exact same time and have had the same marketing. Q has 5,000 users, while A has 1,000 users. What is it about Q that means more people use it instead of A? What makes it ‘better?’
It all comes down to the user experience of your App. Sure, functionally it works and does what it’s supposed to. But if it doesn’t feel like a pleasure to use, your users are going to go elsewhere. It’s important to keep this in mind during the QA process. It’s why someone outside of the development team should be doing the testing — that person will have a very different way of interacting with the App — rather than just checking that the code does what it should.
Apps have feelings
But what makes an App feel good? The thoughts I keep in mind while testing go a little something like this:
- Does it crash?
- Is it intuitive?
- Do I innately hate the way something works? (This is a big one — trust your gut when testing!)
And, most importantly:
- Do I know how to use the App before I open it?
The average person with a smartphone is generally pretty busy 90% of the time. They’ve got things to do, they don’t want to be spending any of that time trying to learn how to use an App. They are going to expect it to work as soon as they download it. They don’t want to traipse through a massive amount of tutorial screens either. They have to know how the App works before they install it, otherwise they will uninstall it, and you’ve lost what could have been a beneficial user.
I like to call this feeling ‘Quality’, with a capital Q. The capital is important because it is different to ‘quality’. ‘Quality’ is that awesome feeling you get when you download and open an App you really like. It looks great. The interface is simple to use. It does everything I need it to do. You can’t just solely focus on ‘Quality’ though. As much as an App may have the greatest design, if it doesn’t work then it’s not going to be much use to the end user.
Which one should I focus on in my testing?
It’s an ongoing battle. Function vs Feel. Features vs Usability. ‘Quality’ vs ‘quality’. Focusing too much on one and neglecting the other will result in less users. Get it right and you’re a millionaire! Well, not quite – but you will have happy users. And if there’s anything I’ve learnt in my short period of time in this industry, making all your users happy is a near impossible task…
If while testing you come across something that feels unintuitive let your product owner/dev team know! As much as QA is something that has to be done, it really is incredibly important. You have the power to stop a ‘crApp’ from hitting the market! It could be the difference between having a marginally successful product and a hugely successful one that you will tell your grandchildren about.