Continuous Integration is an application development practice where members of a team integrate their work frequently. Each person integrates at least daily, leading to multiple integrations per day. A team of developers are all coding. They will update their code, or make a new code for something, and upload it to a centralized Continuous Integration server where every individual step is integrated with the entire project.
Continuous Integration Benefits
Continuous integration makes a DevOps team so agile they can go from one build a year to at least one build a day. This is vital because the platforms mobile applications execute on, such as devices, operating systems, networks, browsers, etc. are all continuously expanding their capacities. This demands that applications continue to expand their abilities to make the most of what each platform offers to continuously offer the user the best experience possible.
Originally, application development wasn’t agile. Each developer would work on one piece of the puzzle, then they would put all the code together and throw a switch to see what would happen. The inevitable bug would appear and a team would have to spend painstaking hours locating the cause of the problem. Then you needed testing to see which solution worked. It took as much time to locate the problem as it did to fix it. Applications were released once a year.
With the introduction of continuous integration (CI), everything can happen all at once. A CI platform monitors every step in the process. When a new feature is needed, a developer codes it in his own programming environment. Once he is done he updates the new feature to the CI platform, and passes it off to the quality assurance (QA) analyst. In some cases, the tests will be run automatically. If there is something wrong, the tests results will immediately halt the development process to alert the DevOps team exactly where the application isn’t working. If everything is working, the CI server can redeploy the new build to market immediately.
Continuous Integration and Continuous Delivery
The CI server has 2 roles:
1. Create a new build of your app based on each update.
2. Run the necessary tests for each build to confirm that the specific update has no errors.
This is the added value: Many developers can update their code all at once. The process evolves into an agile operation where instead of integration being limited to each developer putting their piece into the entire puzzle only to wait for every other developer to do the same before moving on, each developer can constantly update their piece into the build and the server will continuously test and update everything to determine exactly what is working, and what needs to be fixed and tested further.
If one piece of code isn’t working, or one update is incompatible with a series of updates performed by other developers at the same time, the server will halt the entire process. If a test fails the CI process is stopped, and developers are told exactly at what point the new build failed. It will not proceed until that specific update is fixed.
Bugs can be repaired immediately where they appear. The testing phase accompanies the development phase, rather than waiting for it to be completed.
Continuous Integration and DevOps for Mobile Applications
Continuous Integration enables continuous delivery. As long as you are developing, testing, and verifying every step in a build, you can do the same for every update. You can complete a version of your application, then continue the process to market deployment. You can add updates to your app to keep up with ongoing updates to the platforms your app works on like operating systems, browsers, and the mobile devices. The continuous improvement and continuous delivery of your app will maintain the highest standard of quality.
Continuous Integration and Automated Testing
The developer enters the source code into the source code repository. The CI server is triggered to work once a day, or as periodic as you want. It takes all the new code blocks, updates everything, and rebuilds your mobile application based on all the changes. The process is automated. It can happen in the middle of the night while the office is closed.
An executor agent passes the app to all the devices it needs in order to conduct adequate mobile testing. The tests will be run concurrently over a matrix of devices. They can be devices connected directly to the executor agent (the machine the untested version of your app is being run on), or they can be connected through the cloud.
Once the tests are run, you get the test results. They will go straight to the developer, who will see the results, determines exactly what went wrong, and makes the necessary fixes. If the mobile application passes all the tests, the CI can move the new version of your mobile app to the app store for deployment to market.
Mobile demands speed. End users expect faster response time. Frequent external environment changes like new OS versions, and new devices demand apps constantly keep up. As a result, there is a high adoption of Agile methodology in R&D.
Mobile testing is the longest part of the process because you need to test over at least 4 different mobile operating systems, hundreds of devices of varying shapes, sizes, and processing speeds, and you need to test these scenarios over the 400 local wireless networks across the world. This demands Agility in your DevOps process.
The CI server will tell you which step failed. A good mobile tester is more exact. It will tell you which part of the step failed, enabling you to know exactly where to fix. This is what breaks the bottleneck of the old development model and lets you upgrade at breakneck speed. But to do this you need an automated testing tool. You need an automated testing tool that speaks the same language as major CI platforms Jenkins, QTP, and the rest.
The challenge of mobile testing is the test coverage is always expanding, with new versions of operating systems, new devices, and new networks coming up all the time. There are over 20,000 different devices, 400 local cell phone networks, and 4 operating systems all with different versions that make up a test coverage of over 50 million combinations. This turns mobile testing into the bottleneck of the DevOps process.
The Ideal Mobile Continuous Integration Process
Build the app. Code the application, and send the code to the source code repository. It will upload to the CI server, which will build your app. The output of the process is a URL. The CI gives you a URL where you go to download the application by the executor.
Prepare the Application. You need to test the app. It can be in instrumented mode with more control and capabilities. It can also be in non-instrumented mode. Your test automation tool should enable unattended, on the fly instrumentation. It should perform instrumentation on the same machine that is being used for automation.
Reserve the Right Devices without Creating a Bottleneck. Once you are conducting testing on a cloud of devices, it can be up to 100-200 different devices. However, these devices are also used for other projects. Other apps are using your cloud to do their own testing. Manual testers reserve these devices for their own QA. You need to use these devices without interrupting other projects, or having other projects interrupt your CI process.
To dynamically reserve a suitable device, you need a dynamic query so you can get the right device at the right time. One method is to set criteria which requests a set of devices that meet these requirements, rather than reserve a specific device.
For example, you can query ‘android’ and ‘version number > 4.2’ and ‘manufacturer=’htc,’ rather than requesting a specific device. Setting criteria says to the cloud, “find me any device within a range of devices,” rather than saying “get me this specific device.” The cloud can now select what is available without disrupting other projects.
Deploy your application on the device you selected. Once the new build is made, you are left with a URL representing the new build of the app. You need to download the new build onto the devices for testing. You need a mobile testing tool that can take full control of the device and of the application installation, and instrumentation.
The Right Mobile Testing Tool Hits the Sweet Spot of the Continuous Integration Process
The primary tool you will need to include mobile testing in your Continuous Integration process is an automated mobile testing tool. You will need to create test scripts, and run them automatically on many devices at once. Your automation tool will have to run on all major ALM environments and be able to integrate into the major CI platforms like Quality Center, and Jenkins.
You will also need a cloud testing tool that enables you to build a mobile device lab. A cloud tool that enables you to connect to all your devices, reserve the devices you need, and that enables a manager to prioritize devices according to different projects. You will need a mobile cloud testing tool that accommodates queries in ranges of devices as well as specific device requests.
Your mobile testing tool must have monitoring capabilities that include generating a screenshot of every step, determining what exactly worked, and what didn’t. The Continuous Integration process will halt if a new build wasn’t developed properly. It will indicate which build needs to be fixed. It is up to the mobile automated testing tool to show you what step within that build failed, enabling you to pinpoint exactly where you need to troubleshoot your mobile application to complete the new build.
Experitest’s SeeTest Suite, which features SeeTest Automation and SeeTest Cloud include all of these features. With SeeTest, a DevOps process that originally took months can be reduced to hours in identifying a problem in a new build and moving it towards a rapid completion. SeeTest tools operate on all ALM environments, and easily integrate into all major CI platforms like Jenkins and Quality Center.
Get Updates on Software Quality Assurance at
our Experitest LinkedIn Page