Why test if it should be working? Mobile Quality Assurance – a tester’s perspective

What does the tester’s work look like in an Agile project?Why are tests carried out by developers not enough to produce a reliable, user-friendly applications?

Table of contents

1. What is the software developer’s job?
2. Quality Assurance on all levels
3. Why then, after completing this series of checks, we still find a bug or an error in the app?
4. You can’t test everything
5. So why should not the programmer take over the role of the tester?
6. The problem of being a specialist
7. What does a tester do in a mobile app project?
8. Manual tests
9. Creating test scenarios
10. Summary

What is the software developer’s job?

The programmers’ role in a project is to produce and implement app’s functionalities as per given requirements.  Their main task is to ensure that the parts of the app they create work as intended. The extent to which they test their code is another matter. 

Let’s assume the following events:

• The added function works well on its own, but doesn’t cooperate with the rest of the application or causes issues interacting with other components?
• Works only on one device (brand, screen size, internet connection type etc.)?
• The function stops working when you turn off the internet?
• Works only in a basic way – with cases where the functionality doesn’t work properly or, what’s worse, closes the whole application.

To address these issues, a software development company hires  QA (Quality Assurance) engineers. Their role, complementary to programmers’ is to test and analyze the operation of  mobile applications from the end user’s perspective and to identify bugs, errors and any other issues causing the quality of the mobile app to be compromised.

Quality Assurance on all levels

QA engineers’ work doesn’t relieve the programmers from the responsibility to produce working functionalities. The testing should take place at the coding stage as well as at implementation in apps and delivered for testing by QA  teams. The developers should verify the operation of the written content.

There is a variety of tools and processes to help them achieve this. Unit tests – referring directly to the added part of the content; integration tests of the code – checking how the added part interacts with the rest of the application; tests on a physical device or simulators / emulators – all these help mobile app programmers deliver well performing functionalities. 

Why then, after completing this series of checks, we still find a bug or an error in the app? 

The tests refer to the mobile applications’ business logic itself. They do not include eg. testing for visual errors that occur only for smaller screen resolutions or other, device-specific issues.

In case of already existing apps, when a team gets old code for reviewing and QA, test the backend, API etc.. , the typically recurring issue is the lack of up-to-date documentation. The mobile app may seem to function fine, but when the programmers explore the functionality of particular elements, having no data to refer to creates a lot of extra work.

You can’t test everything

Mobile quality assurance tests are usually performed on a limited number of physical devices. This mostly depends on the developers resources and needs of a particular project. In case of lesser known, generic, cheap devices and non-standard screen sizes, errors and issues occur quite often. These are caused by imperfections in the mobile device itself, rather than by the app’s developers.

These device issues are not (or are very poorly) documented by manufacturers so the only way to test and address issues before launch is by choosing a representative sample of devices used by the target market of the developed app.

The developers only check the most basic functionalities they create and they do it in “lab” conditions. In real life though, the working of mobile apps is affected by factors like the internet connection, incoming phone call, low battery etc…

So why should not the programmer take over the role of the tester?

The iOS/Android developers writing mobile applications have complete knowledge of the relations between various elements of the program. Consciously or not – they expect failures in certain events. This is not an undesirable phenomenon in itself, as with this knowledge, they are able to refine and improve produced functionalities. However, it carries with it the danger of falling into  “closed thinking”, making it much more difficult to think outside the box or take on the User’s perspective.

The programmer knows all the processes taking place in the app- why and how things happen. The User only sees the “front” of the app and are unaware of the background processes that actually make things happen on their screens.

This is where mobile Quality Assurance engineers come in with their “black box” testing. The tester here assumes the role of a User – a person completely unaware of the mechanisms inside the program – all they “know” is the type of data to enter and what to expect in return. Just like buying a ticket in a parking meter – we throw in a coin and expect to receive a printout. We do not need to know the intricacies of the device inside the booth.

The problem of being a specialist

Developers create software using various technologies and solutions. Their fluency is usually restricted to a choice of tools they use on a daily basis. They create mobile applications using self developed strategies and techniques. The result is the development of unique processes, including  for testing of their code. Because of this, there is a good chance that when checking another developer’s code, many potential errors will be missed. 

For a QA engineer, testing is free of such dependencies, as they regularly work with code built in a variety  of techniques by multiple programmers. Working with a wide variety of styles makes bug and error identification easier with growing experience.

What does a tester do in a mobile app project?

• Analysis of collected documentation, from design, where projected behaviors are drafted,  throughout all stages of the implementation is crucial for QA.
•  Alerting of all types of behaviors that are potentially dangerous, illogical or dysfunctional
• Protecting the unaware end-User from problems caused by bugs, errors and unexpected events

Manual tests

Manual testing is not based on a rigid plan. Taking loose suggestions of what the application should perform like, the tester attempts to identify errors in the application by simply using the app on a physical device. 

At this point, you can rely on boundary situations as well as use previously prepared profiles of the final recipient. These are records showing the characteristics of the alleged person who will use the application in the future.

When creating an app for stock trading, we imagine our User as a young trader brandishing a middle/upper class phone. The speed, reliability and stability of the mobile app she’s using will be important to her, while consistency, extra social functions or battery life will be of lower priority.

Let’s say our User – Jenny starts her day with turning off the alarm clock and launching a mobile application to view stock exchange rates. On her way to work, when her phone goes from WiFi to GSM and receives data signal switching between transmitters, Jenny checks her app again. For these events to be seamless and User-friendly, it’s key to ensure speed, reliability and consistency of the apps operation.

Creating test scenarios

Based on experience, documentation and other information collected, the testers draft how they will check the application. This allows  to look at the entire team’s methodology and early identification of potential threats. It also ensures the same tests can be performed after corrections. It is also a clear visual representation of the work done on the program for both the client and the software development team. 

Summary

Without the tester on the team, no app will be properly checked. It is important to focus on what a User could try to do in the application and verify any possible scenarios and events that may occur. The testers, with their experience and flexible thinking, are able to find and eliminate problems that could affect the market reception of our application.

However, the tests do not confirm the functionality of mobile apps 100%. They do however confirm that they operate in particular ways under certain conditions. They also provide information for business clients as to adherence to requirements.