Building the right app is the first step, but the bridge between development and market success is ensuring that the app is usable, bug-free and competitive. Testing is the undeniable key to this win.
Statistics show that the average phone has around 80 apps. Another statistic states that over 3000 new apps hit the Google Play store every day. Think about it; one bad experience for a consumer, and there is nothing to stop them from uninstalling the app instantly. There are just too many alternative options.
So clearly the first pit stop before launching your application is to make sure your app, basically, works. Not just that, ensure that it doesn’t drain the battery, is safe to use, is fast to respond, is usable, is navigable, serves the purpose, doesn’t block other features on the phone, works across basic network ranges and so much more. But how do you, as a developer who is excited about your first app or excited about your hundredth app, know that you have got it right?
The Holy Grail of Test Case Design & Delivery
The answer lies in testing. You need to thoroughly check if post-testing, you can answer with a yes to all the points raised above and on many other aspects. But even seasoned players in development don’t have ready-made solutions to these questions. The holy grail of testing is the answer to 3 questions; How can I test everything about and around my application? How can I do it fastest? How can I know, down to the last detail, what works and what does not?
The World of Testing
Without going in too deep, let’s understand at a very broad level the world of testing. You start with defining what all needs to be tested. For this, you create a comprehensive list of things that need to be checked. If each check is counted individually, an app could have anything around eight to nine hundred such individual test cases. If possible, you automate these tests, or you run them manually. At the end of which ideally, you should end up with a clear list of things that work, or that need to be reworked.
Now, all of this can be both tedious and daunting. Any app has a core purpose or functionality for which it exists. Testing for whether or not these features are good to go is not enough. There are a number of parameters which impact the user experience and can shift your app from being one that is used to one that is removed. Some of these things include Navigation, Interruptions, Notifications, Localization, Performance, Compatibility, Security, Network conditions, API, Ads/Events, Database.
Each of the above has further sub-sections or areas where focused testing needs to happen. And the bigger challenge, post-testing, is to get a one-view output which clearly highlights areas of concern. Getting this data upfront, without navigating through reams of data in excel or any other tool is a very important aspect of a successful outcome.
Reusable Test Case Solution
What if there was a solution where a huge chunk, almost 60% of these test cases are already written and ready to use. Further, if there were clear pointers and indicators on what are the common other functionality related areas. Refer the image below for a quick understanding.
Fig 1.1 Common areas of testing
A blank sheet of paper is daunting for most of us. Imagine a scenario where more than half the work of writing is already done, a chunk of that is also automated and with minor tweaks is a plug and play reality. Here comes in the Reusable Test Cases solution, which establishes reusability of test cases and reduces redundancies across projects.
With this solution’s introduction, QA teams can reuse common scenarios across domains (Ecommerce, Health Care, BFSI, Education), and across projects within their operations. If we were to look at each area of focus as an individual block, maintaining a repository of test cases will ensure that the entire set of test cases, across blocks, can be written in a very short time.
~60% of the test cases can be reused and plugged to a new project by utilizing the existing blocks of test cases. Further, if the tests of each of these blocks are automated, it would phenomenally save on execution time as well.
Fig 1.2 Indicative numbers of test cases across blocks
Fig 1.3 Top-level view of block health
The Perfect Dashboard
Well, let’s take this thought further. We have the application, we have the 900 odd test cases, and we have executed them all. A meagre 10% have failed, which is a great scenario. But then comes the nightmare of sifting through them all to find out which ones have failed.
You must remember that a test case is like a single line check item, collecting a list of 90 such line items would require reverse mapping of each, to the original blocks and sub-blocks to know which area is truly not working well. Here comes the perfect view, a single sight colour-coded dashboard which can give you all this information at a glance.
Fig 1.4 Detailed Test Case Dashboard
Anything that is ‘red’ needs urgent attention, ‘green’ is ready-to-go, ‘yellows’ are areas where decisions can be made on whether to tweak or plan for a future date.
On the face of it, this solution is both simple and game-changing. But when you think about it, it is also non-obvious and seemingly non-viable, till it actually comes true and becomes a life-saver for many application developers.
Given the reality that over 90% of applications on Google Play Store and Apple App Store are actually free, applications cannot risk to displease customers. So getting it right, the first time, is an absolute necessity in an increasingly competitive market space. In addition to this, getting your application out fast is another absolute necessity where newer players are already working on and launching, perhaps, similar applications in the same marketplace every day.
Concept Design – Vikas Kanago, Jyesh Ranjan, Shaily Jain