Mobile OS release cycles
A great example of such a drastic change that has revolutionized the industry is the release of the iPhone X and iOS 11. These were the first two mobile phones featuring new safeAreaInput values, gesture interface, a display shape aka “screen fringe”, artboard size, pixel density, new typography, and so on. What seemed rather unusual and even redundant at first very soon became a permanent feature of modern mobile hardware. Now, most any recent phone has one or all of these features. This highlights the significance of staying on top of the trends and balancing out new OS versions with older ones.
Unlike iOS, which is exclusively distributed by Apple Inc. and runs only on Apple-branded mobile hardware such as iPhone, iPad, etc. without customization, Android’s policy is far more democratic when it comes to customizable OS features. Hardware producers who choose to build their products on Android are allowed to create custom user interfaces, hiding the core Android mobile architecture beneath any design patterns of their choice.
The most known custom user interfaces based on Android include One UI by Samsung, EMUI by Huawei, and MIUI by Xiaomi. These interfaces not only differ in aesthetics, but they also perform differently and have a different speed. Understandably, when it comes to Android app testing, QA teams need to spend extra time checking performance and usability on different custom user interfaces in addition to devices, screen sizes, resolutions, and OS versions.
Open and closed systems
In terms of codebase accessibility, the two operating systems also have drastic differences. iOS is a closed-source system based on the XNU kernel. Programming languages prevailing in iOS are Swift, C, C++, and Objective-C. Apple’s mobile software development standards are rather strict, and adhering to these standards is among the key responsibilities of iOS app testing teams.
Android OS, in turn, has an open-source codebase owned by Google, with the OS core being mostly based on Linux and written in C and C++. Google’s policy toward software development and Android application testing has always been rather open and welcoming for engineers. This doesn’t mean that Android mobile app testing and development standards are lower, but they are certainly more lenient for Google Play contributors. For example, in iOS mobile testing, application updates rarely get approved by Apple’s App Review team after the first attempt, while in Android testing, this isn’t such a rare case.
Due to the fact that Apple maintains its mobile operating system strictly unified, the deployment process with iOS apps is usually faster compared to Android. This is because Apple is trying to keep optimizations and performance similar across all versions of iOS currently in use. Obviously, the phase of preparing your iOS app’s build to be uploaded to the App Store will still have lots of steps to follow, but because they will be more or less the same for all iOS versions, the process will be expedited considerably.
As you have guessed, this can’t be said about mobile devices running on the operating system by Google. Any smartphone or tablet that didn’t receive the latest OS version or runs on a custom UI will require much more extensive testing. To streamline this process, testing teams can engage more sources and incorporate automation tools.
Application updates are an important part of mobile software development and testing. However, they don’t just go to the store like that. Both Google Play Market and App Store have established review and approval processes to validate the updates before they reach users’ devices. In the case of Apple, this usually takes from 24 to 48 hours, while Google may take from 4 up to 6 days.
While it takes a bit longer with Google, the Apple review process is more rigorous, meaning you won’t necessarily get approved on the first try and may end up waiting longer. Therefore, if you’re planning a synchronized update for iOS and Android devices, it’s important to ensure that your app is vetted for bugs and errors and can be reviewed and approved on both platforms at the same time.
Mobile Web Development Stages and Corresponding Mobile App Testing Techniques
App quality assurance can’t be discussed separately from software development, as both activities are interconnected. In fact, if we take the Waterfall model that was used by the majority of companies just a few years ago, testing there is included as yet another phase of the development lifecycle that can’t be moved or replaced. Here is how it looks:
- Research and conceptualization;
- Project planning;
Over time, the “develop first, test later” approach has discredited itself by being inefficient for many IT teams. Now, it’s being gradually replaced by Agile, offering a holistic approach to software quality assurance. The main concept of Agile is that testing should start as soon as the team begins developing a digital project – and, in many cases even far before the actual programming. This way, teams can detect poorly functioning code and high-level errors affecting the whole application.
Following that concept, here are the steps the mobile development process is divided into and the corresponding testing techniques for each of them.
Application prototyping and concept testing
The first step in app development is creating a prototype. A prototype serves as an initial blueprint that offers a tangible representation of the future application with basic features and functionality.
Prototyping testing allows teams to assess the usability of a future product, its core functions, and the validity of the concept as a whole. Unlike the ready-made application, a digital prototype has no large codebase behind it, which means it doesn’t take long to create one. In fact, you can easily make one in design programs like Figma or Invision.
MVP & key features testing
MVP is a software development method used to “test the waters”. As the name implies, the product has only the core features that make it viable and allow it to be launched into the market. The idea behind an MVP is to collect user feedback, understand what they like and don’t like about the product, and whether it’s needed at all. If the MVP is successful, the team can proceed with further development, expanding its functionality with new features. This way, your application reaches users (or a focus group) faster without wasting time or resources on major rework.
Unlike prototypes, the MVP has an actual codebase that can later be used as the basis for the final version. When it comes to UI/UX design, it usually doesn’t focus much on aesthetics, though you can also test the overall style and color scheme of your application at this stage. In terms of MVP testing, QA specialists not only test the shortened version before deploying it but also follow it up with the analysis of feedback from early adopters.
Release & functional testing
When people think about QA, most don’t think it is just functional testing. However, functional testing is, without a doubt, the fundamental step of mobile QA testing. The purpose of functional testing is to compare the functional requirements of a product to what is actually developed. It focuses on accessibility, core functionality, basic usability, potential bugs, and how to fix them, and it is done in conjunction with the other types of testing.
Post-release support & regression testing
The work of development and testing teams doesn’t end when the app hits the App Store or Google Market. Regular updates of mobile applications are just as important as a successful launch. However, even the slightest glitch in the codebase can lead to serious errors and even program crashes. This is when regression testing comes into focus.
Mobile regression testing is the process of checking whether new code conflicts with old software or causes lags. Compared to desktop testing, regression testing of mobile applications can be more difficult to perform due to the many technical combinations (application architecture – native or cross-platform, mobile platform, its version, etc.).
What Features Are Analyzed in Mobile App Testing
As we’ve mentioned earlier, it’s unrealistic to test every single feature of an app. Firstly, the deadlines are usually quite rigid. And secondly, comprehensively testing every feature may simply be impractical given resource limitations. Therefore, testers are expected to focus on the features that are the most important to the audience. Generally, the most critical features of an app are:
Let’s take an eCommerce app. Its core features would be the catalog, shopping cart, and payment mechanism. If we take an e-learning course, for example, we’d be looking at the features such as content accessibility, user interface, and the functionality of interactive elements like assessments and quizzes if they are implemented in the app. These are the key features that need to be tested thoroughly because any lags or glitches in these areas will detract from the user’s experience or – worse than that – make the use of an app impossible.
Ideally, your testing team should have a diverse expertise in testing applications from different industries to be able to determine which features are most important quickly. At the same time, it’s always a good idea to engage with a control group of potential users, seeking their opinions on the features they deem most significant. This strategy ensures a comprehensive evaluation that aligns with both industry standards and user expectations.