If your company wants to become mobile-friendly (or even go mobile-first), being able to test mobile applications effectively is critical. If you can’t do proper mobile testing, the rest of your mobile software development and deployment will fall short.
However, testing effectively for mobile applications is sometimes easier said than done. This article identifies the challenges that organizations commonly encounter when working to add mobile testing to their delivery chain, along with tips for addressing the challenges.
One big hurdle that hangs up many teams is picking the right test automation framework. There are a plethora of options on the market, and there is no one option that will address all of your needs. Commonly used frameworks include Appium, Robotium, and Espresso.
Things to consider when you are selecting a framework are whether you want it to be cross-platform, or to address only one type of platform (e.g., iOS or Android). Do you want to do UI testing or just component testing? Do you need data-level testing? Do you want to be able to virtualize services? Do you want to be able to simulate network latency and packets dropping?
Perhaps the greatest challenge in this category is the cross-platform vs. application-specific question. The advantage to using a cross-platform solution is that you can potentially reuse all your test cases more or less unchanged. On the other hand, a cross-platform testing solution makes it more difficult to perform platform-specific tests. It can also provide a false sense of security by leading your engineers to overlook critical tests for a specific platform or environment.
Remember, however, that perfection is the enemy of progress. There is no such thing as the perfect testing framework. Pick the best fit for you, even if it is a combination of two or three frameworks, and start building tests.
Under the Agile development mantra, there can be the perception that functionality comes before everything else. While working in smaller increments definitely allows for delivering working functionality on a much shorter timeframe, Agile does not mean that structure isn’t needed to ensure an application can be maintained and improved over time.
Putting the introduction of a test framework in the first sprint or two allows for faster cycle times later on as testing for previous sprints will be automated, and manual validation can be limited to current changes. Skipping the inclusion of a test framework at the inception of a mobile application may deliver the first working component a few days faster, but as the technical debt builds and the number of manual tests increases throughout the sprints going forward, the time gained up front will be quickly lost.
In more established companies, one of the biggest hurdles will be working with any existing centralized teams which currently handle DevOps or similar build and deployment pipelines. Unless a pipeline already supports building mobile apps, especially iOS ones, it will take some time to get everything integrated and the kinks worked out to make builds and deploys seamless. Ideally your team would get an exception or be allowed to build a net new pipeline using Continuous Delivery principles to support mobile app builds and deploys.
Regardless of whether you are a small or large shop, having builds and tests running on a centralized service will ensure that multiple developers can all work on the app together and that the build is repeatable if something were ever to happen to a developer’s laptop or workstation. This could be as simple as having a dedicated Mac Mini running Jenkins that handles builds based on a WebHook from GitHub.
ITIL is not something the average startup will have to deal with, as it is a framework used by larger organizations to make sure their operations teams are following a standard set of best practices. In a typical enterprise setting, once a mobile application will need to engage any part of the support organization, it will be asked to follow the same model for tracking and auditing purposes.
The best part about this hurdle, while it may seem daunting, is that ITIL Change and Release Management is all about consistency and reproducibility, which are what a proper continuous delivery pipeline provides. It is even possible (depending on the ITSM toolset involved) to automatically create all required documents and requests inside the ITIL framework as part of each build, including the release notes and test results.
You can become the poster child for how easily changes can flow through the system, which helps everyone.
As shown, none of the hurdles listed in this article are insurmountable. They just take some dedicated cycles to address, and once the hurdles are cleared, your mobile development life cycle will be world-class.
Vince Power is a Solution Architect who has a focus on cloud adoption and technology implementations using open source-based technologies. He has extensive experience with core computing and networking (IaaS), identity and access management (IAM), application platforms (PaaS), and continuous delivery.