Optimizing your mobile app QA testing: Traditional versus proactive test design

, Dog owner, expat, gin lover. Allegedly wise to the ways of digital marketing, PR, and social media. Currently waging a war on mediocrity in communication and storytelling.

In QA software testing, the user is the boss.

When software developers and testers get together to build a new feature, it’s easy for them to get bogged down in the details. I once worked on a project that would make your phone flash rapidly while taking pictures. It looked like the paparazzi was after you. It was great, and it didn’t work. The reason it didn’t work, was because it had only been tested in normal lighting. By the time it made it to the wild, it was quickly realized that the flashes didn’t match up with the taking of pictures. Cool scene in a club? Doesn’t work. Taking a candid set of shots in a dim restaurant? Nope. Wedding parties? Sorry.  

The thing is, everything was tested correctly. It passed all of the mobile QA tests we gave it, but once it gets in the hand of the user, your original idea is no longer yours. Users will use what you’ve built the way they want to and you need to adjust as new use-cases come up.

Butterknife screwdriver

If you’ve ever used a butter knife to tighten a screw, you know what I’m talking about.

Using an iron in college to make a grilled cheese? Guilty. But that led to the invention of the sandwich maker. It’s very difficult to realize what will happen with your product or feature when it gets into the hands of the general public. That’s why the software development life cycle (SDLC) requires a more agile way of producing what the user wants.

QA to follow suit

QA testers need to look at what is happening to a product and adjust their tests accordingly. By asking for feedback from actual users, testers can better predict which ways their product is actually being used and adopt future test for additional features. A new slimmed down version of the butter knife? We should probably test to see if it will still work as a screwdriver. Not because it was intended to be a screwdriver, but because that’s how users are using it and it’s what they’ve come to expect.

If it isn’t broken, don’t fix it

In a nutshell, the ultimate goal of QA software testing is to keep your product from annoying your users. Sounds simple, but as I’ve pointed out, you won’t catch every use-case. So what should you do? How can you be more proactive in your approach to agile QA testing and design?

Bring your QA team in early! I know I say this a lot, but that’s because it’s so important. Most development teams start testing late in the process, to the frustration of QA managers. The QA perspective is worth its weight in gold and if you make the QA team a part of the requirement reviews or the designs, you’ll be able to spot potential problems at a much earlier stage. Developers also have the added advantage of getting extra eyes on the project. This ultimately leads to a much better final product and a better experience for users. By implementing test cases earlier – before the code is completed – you’ll be able to reduce costly fixes to the code.

RELATED: How to write the ideal test case

Traditional versus proactive test design

So what is QA testing? The answer isn’t as cut and dry as you may think.
Traditional software QA testing is the process of designing a set of tests that need to be executed to prove the code does what it says on the box. The problem is, with QA teams usually coming in late, they are often forced to use a subset of the tests available. Teams then determine the most critical cases to test to get a result.

Proactive test design starts on the other side. Actively prioritizing risk and building tests from the most to the least risk. Instead of writing test cases late in the process and then testing and sorting based on risk, the new, and arguably better way, is to analyze risk first and work down.

If you’ve worked in software development, you know when you hit a showstopper bug. These are the major ones that can kill a users good-will and enthusiasm for your product. They can render your software useless.

Traditional requirements testing will only test the design. Often missing showstoppers in the process. If you miss it in the requirements, by design, you will miss it in the testing phase. Proactive design looks at the risks, and designs test accordingly. They are also implemented much earlier, so there’s a better chance that you’ll spot the design flaws before they become an expensive fix.

By involving your team early and designing to look for risks first, you’ll reduce the overall build and testing time.

About the paparazzi app? It ended up being a big hit at kids’ birthday parties but was never big in it’s designed use case. Sometimes those things happen.