The value contributed by automatic business process check it is undoubted, especially if our business is alive. Mobile application tests ask us go to the next level: to be able to reuse those automatic tests that have already ensured progress in the software build cycles, # logical right?
Reusing evidence is not a mythological challenge,
it is a testing strategy.
Test strategy, yes, yes, that goes before you start coding tests like a beast. This is how the return on investment in Software Quality Assurance (SQA) is maximized, this is how we add value to the business.
What if our business depends on mobile applications?
More of the same, it is a strategy.
In fact, the conversion rates of mobile devices increase month by month, so that the reliability of applications ("apps") on mobile devices is already a determining factor in monthly sales, in addition to brand image. We already have the transmedia narrative peering into business processes.
The pressure to deploy in different channels usually requires the coexistence of different platforms, some to generate native mobile applications ("iOS apps" "Android apps"), others for adaptive web applications ("responsive web") and others for hybrid applications , Another nightmare for the SQA process!
And so far we have arrived with today's theory 🙂
If you want to get started or delve into automation of business process tests and test strategies, of course, we recommend our starting point challenge to go further with software test automation (its eight questions show you our pilaris to automate tests with guarantees to last).
Okay, let's go to practice! (Inspiration # 101PanelTechDays total).
Caso: We want to expand the scope of our SQA process towards platforms and mobile devices.
First, we will continue with our strategy of automating business processes and We will adapt your automated tests so that they can be launched on mobile devices.
In addition, in order to maximize the reuse of automations, we seek to abstract from the underlying technological layers:
- At the Operating System level (Android / iOS):
- For hybrid applications and mobile web: we want a high degree of abstraction.
- For native mobile applications: we seek at least to be able to reuse part of the development carried out, although it is necessary to deploy specific software for each platform.
- At the version level of the Operating System: again the objective is a high degree of abstraction, although there are some dependencies between the different versions.
- Device to use: we want to completely abstract.
For example, What does "abstract from the web browser" mean? It means that we can launch the same test in different web browsers, without recoding it.
To speed up start-up, we cheat and rely on Zahorí as a framework because it supports the strategy of automating business processes and quickly provides us with technological abstraction. Trick or Treating!
Finally we can get down to work! We have achieved that the bulk of the effort does not depend on the number of Test Cases («Test Cases») or devices to automate, but rather the complexity of the business flow that you want to check unattended.
Thus, we will focus on extending the execution of automatic tests to mobile devices, connecting with Appium in our practical case, because we benefit from the effort dedicated to specification of regression tests, business flows to be covered, necessary data, validations to consider and, especially, we take advantage of the work already invested in the development of automatic tests with architecture oriented to business flows. #Sustainable
We will normally materialize this effort in regression test run cycles of mobile applications on emulators, physical devices or cloud devices. These regression tests can be launched daily, before the publication of a new version or, even, on production elements (they are the most valuable Availability Probes).
And what do we have when calm finally reigns?
The deliverables are the assets with which it is ensured to maintain the return on investment and that in this practical case will be: the source code of the automations, the configuration of the execution environments and the documentation associated with the development carried out. Versed and by hand.
With this we take our mission for granted. We have managed to reuse automatic tests that we had already used in the software build cycles to test the mobile web version, like the good ones.
Let's go for the next challenge!