Manual Testing for Mobile Applications

“It takes less than 30 seconds, for a user to delete a slightly buggy application.”

We all know that this is true from our lives and most of the time the application doesn’t have to have any bugs. We can delete it just because it is slightly inconvenient. As mobile app users, we don’t accept anything below perfect. This is exactly why companies have testing/quality assurance departments.

As quality assurance professionals, we are the first customers for the app. If anything is wrong before publishing, we are the last chance to prevent it that our company has.

In this article, I would like to introduce the very basic yet solid steps a top e-commerce company takes to make sure that their app isn’t going to be deleted in the first minute.

Steps of Overall Test Process

1. Analysis of Requirements

In this process, the product owners have shared with us the desired improvement in writing. The works that come to the planning meeting as a list of priority are discussed. It is discussed what can be tested and what is risky. The contribution of the desired improvement to the user experience is questioned. Prepared analyzes are noted in order to look back when needed.

The questions to be asked to the Product Owner before going beyond this point are as follows:

• What purpose does this development serve?
• Are data, links (APIs) that can be tested ready?
• What are the places and pages the user will be affected?
• What should the user expect as a result of development?

We question the Product Owner, so to speak. Once we have entered the testing process, the answers to these questions should be ready. The clearer the answers to the questions, the smoother and more accurate our test result will come out.

2. Creation of Test Cases

Cases are simply scenarios that the user will follow. It is the document on which ways the user can go and what they will encounter.

Although it may seem like a long job, it is actually a very time-saving step for the next steps. Because this document is written once, the whole test proceeds through this document.

After the analysis of the development to be made, every action that the user will take is written step by step. These written scenarios are also shared with the developers so that they can facilitate the development phase. The purpose of this document is to record the point where the error is encountered. It saves us the trouble of telling the developer where to look for the error. In retrospect, it easily provides us with reference.

A Test Case consists of three main headings:

• Acceptance Criteria
• Description
• Script/Steps (Action — Reaction)

2.1 Acceptance Criteria

Before the test steps are written, the acceptance conditions (initial conditions) of this test are determined. It means that the test is valid only as long as these conditions are met. Unless these conditions are met, any bug encountered will not be recorded and will be deemed invalid. Although it doesn’t mean that, every test phase must have an acceptance criteria. Some features may not include it.

It should not be forgotten that our aim is not to find the bugs of the “whole application”, but to find the bugs in the “region”, which are only determined/ limited by acceptance conditions. Because our project is huge and our time is limited.

The time will come when we test the entire project, it is called the “Regression Test”, which I will refer to in my next articles.

Example:

In our scenario, “Order Date field should be added next to Buyer and Amount field on My Orders page.” let’s say.

According to this scenario, the acceptance criteria is when the user logged in. Since the user can access the My Orders page as login, this test is not expected to run while in Logout state.

2.2 Description

A short explanation is written about what the test scenario says. The purpose of this description is to explain at a glance what this test does before running the test.

Example:

• The “Favorite” icon on the list page becomes passive
• The item added to the cart appears first.

2.3 Script/Steps (Action — Reaction)

We start writing our script step by step here. The steps that the user will perform in the application are written. “What will happen when you click on which button?” Answers to such questions are given. Best approach is to write first the action taken then corresponding reaction received from the app.

Example:

In our scenario, “Order Date field should be added next to Buyer and Amount field on My Orders page.”

Steps according to this scenario:

According to the steps above, the test case preparation process is completed and these tests are run during the feature test.

Moving on to testing without this planning will cause us inconvenience, including but not limited to:

• To forget where the bug came out,
• To forget where we were and reluctantly start again,
• Doing the same operations over and over again,
• Disruption to our work during testing.

The issues whose development is completed are transferred to the “Ready for QA” field in the issue track application (eg. Jira).

3. Taking a Build

The application is being compiled. While compiling, it should be ensured that it is compiled without any problems. It should be noted that the app build is from the correct branch (KAN-53, IOS-143, AND-44 etc. ) and the correct environment (Stage, Pre-Production, Live, etc.). Staying in touch with the developers is one of the important elements in order to avoid problems that may arise during build.

While the application is compiled, the build must have the APIs accordingly. It can be tested using Test, Live or Both APIs. This is decision is not the Tester’s to take, this has to be taken into consideration before sent to “Ready for QA” column. The developer is requested to configure the project according to the APIs suitable for the requested test.

If you have the chance, it is better to build on a physical device than to build on the simulator. Testing from a physical device allows us to understand the experience of the end user and to debug and note errors correctly.

The stability of the tested environment is another important factor that affects the healthy functioning of the tests. If Internet slowness, device problems may interfere with the test, this should be avoided. Make sure that your device has enough charge and your usb cable is working properly.

4. Testing

Now is the exciting part. It proceeds by following the prepared cases step by step. You cannot go out of prepared cases. During the test, new cases may come to mind. We return the new cases that come to mind and add them to the test scenarios.

We are on bug hunting right now, like hunting dogs in movies. We opened our noses and eyes. We are looking for wrong position, slipped, overlapping keys, over spelled labels, an unexpected text in the cell, a wrong picture or the most important one a crash.

Let’s say a bug has been encountered. A bug record is created on the board where the issue is followed and the developer is informed. This bug record is created not after the entire test is over, but when a bug is encountered, because creating a bug record after the entire test is over causes confusion for both the developer and the tester. These bugs, which are opened one by one, are expected to be resolved by the developer during the testing phase.

When opening the bug record, a draft can be followed so that it can be fully and easily understood by the reader. As these bug records are opened, the most ideal draft will be created by itself.

What should be stated in the bug description:

• Is the working environment, test or live environment?. “Environment: Test”.
• The device being studied can be specified. “Device used: Samsung s6, iPhone 6s, etc.”. If the bug is specific to a device, it is noted as “This bug is device specific”.
• Acceptance criteria are indicated, if any.
• Test steps are written as “action taken — reaction received”.
• At the point where the error was encountered, the desired situation was not met. The desired situation is indicated here.
• Visual media are very useful for understanding the error. If available, photo and / or video is attached.

Example:

5. Bug-Fix Process

The bugs registered during the test phase are resolved by the developers. It is checked again whether the bugs that are solved work as desired or not. To do this, switch to the related branch of the resolved bug and build again on the device.

When you are sure that the bug is resolved, the bug recording is closed. If there is another bug record opened for the relevant job, a switch is made to the relevant branch.

When all the bugs of the work to be developed are completed, they are passed over for a final check.

6. Review

The tested job may have one or more bugs and the bugs are recorded. The bugs resolved by the developers are checked and the issue is closed if they are resolved as desired.

It is the healthiest thing to briefly review whether all individual bugs spoiled the overall app or not. Transition is made through the analyzes and test cases prepared. The job can be completed as desired by the product owners.

Among the detected bugs, those containing lessons to be learned are shared with the relevant teams.

Thank you for reading, I hope I was able to help you today.

You can see these steps similar to where you work. If your workplace doesn’t have a testing department or procedure, using above steps is a good place to start.