Express Computer
Home  »  Columns  »  Mobile application testing is becoming a matter of risk management

Mobile application testing is becoming a matter of risk management

0 430

By Robin Molnar

Let’s face it, given the wide range of devices, with their own factory or user customization, it’s becoming ever harder and more expensive to test mobile apps, so a new approach to testing mobile apps is needed, especially on Android, with its plethora of screen sizes and resolutions.

- Advertisement -

While obvious, it may not be immediately transparent that a “one-size-fits-all” solution cannot exist. Thus, a business-specific, business-oriented and business-relevant testing approach must be defined so the matter of testing mobile apps is not reduced to a mere “test until it is good enough” – which, in some cases, may be enough, but not always – which implies some different approach.

Testing, in general, is required for risk management. Application testing was always related to risks. For this reason, we test so that applications don’t easily fail. We test and enhance applications so that the chances they fail become smaller with each passing iteration. Simply put, application failure is a risk, so testing for failures is a means to manage this sort of risk. However, risk management is a lot broader than testing for failures, because this sort of testing is just a tool – out of many other tools – to get somewhere, whereas risks can also be non-technical, or not application-related, but I digress.

- Advertisement -

In the context of mobile app testing nowadays, risk management is becoming more closely tied to testing than it used to be five years ago. For instance, years ago, risk management was driving app requirements, which drove testing requirements and that was it. Nowadays, risk management drives app requirements, driving testing requirements and, then, the output of the process is, again, consumed by risk management which, again, may produce new requirements.

One can’t test everything on all mobile devices, and “test until is good enough” may not be suitable enough. So, by understanding the business needs, the business process and the business model of the application, it is indeed possible to define a testing approach that not only ensures the maximum quality for a given cost, but also the minimum business risk in this context. Simply put, as we can’t control everything, we can control the software development process in order to minimize risk by testing properly.

For this, the testing approach should switch from “testing the mobile app” to “testing the mobile app in the most business-relevant context.” Well, one should always test in the context that is most relevant for the mobile app, but by enunciating this principle it becomes easier to focus on what is business-relevant rather than what is just technically-relevant, as these two usually do not overlap.

By embracing context in testing, by being focused on what is business-relevant first, it becomes easier, albeit not easy, to define a strategy for testing mobile apps that produces good results. Of course, this means that the testing team needs to understand the business, not just the app, to understand the context, not just the business and, on top of that, to understand the vision behind the mobile app. So, layers upon layer of expertise are required for effective mobile app testing. This is why it’s so beautiful and fun. Because, let’s face it, reducing risks is fun, that’s what drives us to build a better (technical) world. So this endeavor satisfies both, a human and a business need, for all parties to gain something.

The author is senior QA engineer at 3Pillar Global


If you have an interesting article / experience / case study to share, please get in touch with us at [email protected]

Advertisement

Advertisement

Get real time updates directly on you device, subscribe now.

Subscribe to our newsletter
Sign up here to get the latest news, updates delivered directly to your inbox.
You can unsubscribe at any time
Leave A Reply

Your email address will not be published.