Software testing is a difficult task, and testing mobile apps, particularly consumer-facing ones, can be an art unto itself. Wildly different mobile operating systems, device sizes, and usage scenarios can make testing a daunting task. Here are a few suggestions to make your mobile testing, and ultimately your app deployment, more successful.

Testing won’t “just happen”

Tools from mobile programming frameworks to management methodologies often imply that testing is part of the app development process, and might cause you to think that testing naturally occurs during the build process. This is decidedly not the case, any more than modern manufacturing processes replace the need for product testing in the physical realm. Testing can be costly and time consuming, but that cost should be weighed against the hard and soft costs of delivering a product that doesn’t work correctly.

Go Agile early

Most mobile development gurus suggest a rapidly iterative approach to mobile app development. This not only speeds the development process, but can resolve many of the user experience problems that plague a mobile app. If your developers and designers are frequently collaborating, everything from copy changes to font sizes can get squashed before you enter a formal testing cycle.


It’s tempting to assume your internal test team and beta testers will capture the vast majority of defects in your app when simply left to their own devices. This is often not the case, however, and some preliminary planning, ideally referencing your app’s functional requirements list, can allow you to map out critical and exception scenarios you want to test. This seemingly tedious task can save time later, since each app upgrade, new device, or OS update can be subjected to the same battery of tests. Grow this library of test scenarios over time, or even automate a large portion of it, and you’ll be set for rapid regression testing.

Cross-platform really isn’t

One of the great frustrations of the current state of mobile app development is that cross-platform app development tools simply don’t produce consistent code across different mobile operating systems. Even a fairly rudimentary app developed with cross-platform tools may manifest defects that only exist on Android or iOS. Covering one platform in your testing doesn’t necessarily cover another when using cross-platform tools.

Involve all parties in defect triage

Most test leads for mobile apps come from a design or development background, and are biased toward that area. A lead with a coding background might perceive a functional tweak as a critical defect, while a design-oriented lead might consider a font problem or color tweak equally critical. Make sure that you involve representatives from the product, design, and technical sides of the process when you determine which defects you’ll attack now, and which you’ll defer, particularly as your release date nears.

Tools will help, but won’t save you

There is a wide variety of tools available for mobile app testing. At a rudimentary level, screenshots and spreadsheets can be effective and fast. However, even an uncomplicated app will generate a large number of defects that must be prioritized, assigned, tracked, and eventually retested, so equipping your test team with helpful tools will certainly benefit them. These tools cannot replace effective management, status reporting, and communication between product owners, designers, and developers. Augment a high-performing team with tools, but don’t expect tools to turn around a struggling team.

Many of these recommendations can be broadly applied to everything from product testing to traditional software testing. However, in the mobile app space, compressed timelines, unreasonable expectations, and market pressures obliterate the slack that can save a test team that’s not performing at the top of its game. Taking the time to plan an appropriate test effort for your mobile app can make the difference in a highly competitive marketplace that’s growing increasingly intolerant of substandard products.