Automated testing scheme for mobile terminals in financial industry

Parag Kulkarni has served as a core member of the test automation team in SQS, India, since 2008. He specializes in automating the use of various tools. His core competencies include automated framework design and mobile automation. For the past eight years, he has been extensively involved in the fields of CRM, publishing, banking and telecommunications.
Today, financial institutions are using multi-channel methods to service their customers, and more and more are beginning to use mobile technology. Customer service for the financial services industry requires highly reliable grassroots software. The need to sync with customer expectations, the short release cycle and the need to provide high-quality software are the challenges of developing mobile software-especially in the app store where poor quality is seen and has an impact on the reputation of the bank. Therefore, testing, especially regression testing, is one of the most important tasks in app development. But if you don't give your customers "bank standard smart machines", how do you meet those expectations? Mobile test Automation using multiplatform methods is one way to address this challenge. In this article, we will show you the details of an instance project that we have successfully used for this method.
Project Content
An Austrian bank is looking for mobile automation solutions to test multiple apps on multiple platforms, such as Android and iOS. They also want to well cover the phones and tablets that their customers use most often. Based on this information, we came up with a customer mobility test strategy to answer the following questions:
--what kind of app must be tested.
-which device types and models must be overwritten.
--How many test cases must be overwritten.
--How much the regression test has done so far--how it works for the framework of the project.
Our mission is to experiment with two apps that cover the automation of mobile testing. The first: Web apps, which have to be tested on mobile phones or tablets, are tested on Android and iOS. The second: hybrid apps, tested on Android and iOS, are tested on four handsets and four tablets. Why there is such a difference. Web apps rely only on Web browsers, and hybrid apps will need to be more thoroughly tested on more device models, considering the more features of the underlying system. The equipment is selected according to the analysis of the equipment used by the customer.
Challenge
We're running a regression test with 60 test cases, with two-thirds covering the Web app and the remaining One-third covering the hybrid app. The regression test was performed four times a year, that is, 2 kinds of app,60 test cases, 1 years 4 times. But it's not that you're going to automate these test cases in the first place; it may also mean the exact opposite--stick to manual, group testing--without the following "but" words:
1. We are talking about banks. Banks are not keen to outsource their tests to clouds or groups. A test service provider is sufficient.
2. The experiment covering only 60 test cases was conducted once a quarter-but it was just an experiment. In short, we'll be able to reuse our test code for more than 10 apps. Repeatable use is important.
As for the technology covered, we have to test app--on iOS and Android platforms, of course, in a cost-effective way.
Plan
Doing experiments does not just mean automating the tests. It also means a carefully developed experiment that will build the foundation for a year-long successful test automation. Therefore, throughout the project our project plan has the following four phases:

Tool selection is an important theoretical step in selecting one or several candidate tools for a multifactor analysis. The second stage is to select the most appropriate tool for a particular project or customer and make a practical evaluation, setup and first-time proof-of-concept. proved that the technical tool can be used in the project, the actual automation is to test. The automation phase can overwrite the complete set of test cases only if the test case selection is overridden in the first proof-of-concept. Automation means software engineering, which does not exist without a test (at least), so the automation phase covers the execution of the first round of automated test cases. The final step is to prove whether the method is effective for the management of service methods, and the need to industrialize the software, that is, to make it standard and enforceable in a predictable manner.

We narrowed the seven preselection tools to one that (theoretically) fully satisfied the needs of our customers. In order to prove the theory, we took 9 representatives from 60 test cases, set up the test environment and carried out the concept validation (PoC). Regardless of setup work, often, the concept of partial customer background verification is a time to spend a lot of experiments. You can easily see the effect of POC learning: No need for a second environment setting, with POC experiments, we can easily increase from 3 weeks to 9 test cases to 4 weeks 60. Ultimately this is the speed of automation in the actual project. The last four weeks of the experiment were condensed into a standard one-week test cycle.
Implement
We had seven candidate tools at the beginning of the experimental phase, and we finally decided to use Calabash. Calabash is an open source testing framework based on behavioral-driven Development (BDD) ideas. BDD detached the actual functional test work from the "Behind the code." This allows the test work to be divided into the following two:
--Domain Experts (SME): SMEs understand the functionality of the app, but in most cases the code is largely out of the picture.
--Test automation expert (TAE): Taes understands the code, but in most cases it knows a lot less about the expected behavior of the app.
With the BDD tool, domain experts can determine the capabilities of test cases in human-readable form. Such a "story" has the following form:

In this example, we found a hybrid approach to test automation, which is often recommended for testing automation. The "hybrid approach" means that the Calabash test automation method mixes the verb based test and the data-driven test. Each row in the previous example can be seen as a verb that describes a behavior such as "I pressed the go button," which is too low-tech to be understood by field experts. Data-driven means that we don't need to write new test cases for each combination of data that we want to try. Instead, we use the parameters of the test case itself.

Use the Calabash Mobile test automation structure, such as the ' when I enterinto ' user ' field ' line--and a single datasheet that explicitly considers the data combination (the table in the following example).
Of course, test cases do not run exactly the same as above. In the second step, the test automation expert performs the actual execution:
They write technical code triggered by verbs to control the app from a technical level by sending information or clicking on GUI elements, collecting feedback from apps and evaluating feedback. Here is an example:

When parsing the "Test story" code, Calabash tries to use regular expression matching to find and execute the matching code. This code is triggered by the ' when I enterinto ' user ' field ' line. For the first-round test, the "test123@example.com" is replaced with the first data value of the mailbox address in the test datasheet. When this code is invoked, the variable text is set to the first paragraph of the variable text, and the variable text field is set to the name of the text field that we want to access (the user). The code then waits three seconds to sync with the Web app and set the text for the Test123@example.com user field. Then Calabash continues to test the next line in the story.
In order to provide effective test automation for a large number of test cases and mobile devices, it is necessary to create a concise generic test automation library (see Figure 3). Using CALABASH3 's mobile test automation structure. The library contains all the reusable step definitions, and note that those step definitions are reusable for different devices so that they can be used transparently in test stories. This avoids the cost of having to write and maintain the same test case multiple times for different devices. In addition, reusable step libraries should be fully modular to distinguish verbs for specific products, specific product lines, and branches. Modularization of the Automation library in this way can reduce the share of the same libraries in different projects and again minimize the development costs of testing automation. Calabash meets all of our cost-saving requirements (it is an open source tool that is free at first) and supported platforms (iOS or Android). It can also easily expand customer function. This is good for us because Calabash is the best solution-but initially it only supports local and hybrid apps, and it's not perfect. To enable it to support Web apps, we created a Web browser that can be controlled from within the Calabash. This means that we can fully meet the needs of customers.
Experience
For the four successful phases, we propose a comprehensive project plan. The most important phase is the experimental phase of the selected solution, a Calabash-based test automation framework. We have found some obstacles, but it can be fairly easy to solve them by using simple Calabash extensions. Repeatability has become an important issue for our customers as well as cost savings. With Calabash, it's possible to write automated test cases for iOS and Andriod apps and reuse 80% of test code for two platforms. Web object code can also be reused for Web apps and hybrid apps, which dramatically reduces automation again.
Copyright notice: This article originates from SPASVO Software test network http://www.spasvo.com/news/html/201569155907.html
Original works, reprint, please be sure to hyperlink form to indicate the original source, author information and this statement, otherwise it will be held accountable.