Mobile application testing

This method is applied when it is cheaper and faster than manual testing. This is not suitable for all projects, so we provide this service to our largest clients. For example, DMV Genie testing was automated (the group includes 14 applications). Automation was a necessary step to reduce testing costs on this project in the future.

The goal is to optimize the testing budget and free up the tester’s time to work on more complex cases.

The name hints that this type of testing involves a lot of manual work. Indeed, testers go through most of the scenarios manually. So we can get data on the state of the product very quickly and influence them promptly.

The goal of this testing is to obtain a complete picture of the product’s functionality and track dangerous points in time.

The stage takes place before the development. We study documentation and requirements and conduct a technical review of layouts.

The goal is to find bugs in the designed logic before development and fix them.

Testing without case design based on functional background information is provided.

The goal is to test the product without documentation promptly and effectively.

We make a list of test cases for the product. They should cover business logic, transition states, and bug handling.

The goal is a full test coverage of the project with clear expected results, digitization of the project knowledge base.

Deep testing of product functionality is provided. This may be required if the project has been refactored.

The goal is full testing of all described cases in the project.

Run of brief test on the main project functionality when the code has been already changed.

The goal is to make sure all basic functionality works and new changes don’t crash anything.

We check each platform for its display and correct collection of analytic data and events.

The goal is to find quickly the section of the application that works incorrectly.

The testing is used if a significant change has occurred in the database and it is necessary to check the deployment i.e how the release build lays on the one published in the app store.

The goal is to make sure that the application could process information from a new database.

Pixel Perfect is a special coding technique that screens match layout pixel by pixel (100%). We compare screenshots from real devices with a file in Figma and ring the alarm in case of any smallest gaps.

The goal is to get a perfect match between the layout and the app.

This type of testing is suitable if there are no clearly defined cases.

The goal is to test a product’s performance as fast as possible.

Stress testing of the app is provided.

The goal is to find the place where the app stops working properly.

We review all texts before release so as not to miss typos. There is the testing of localization, translation literacy, and correct text display.

The goal is to clear the application of stupid typos and weasel words.

We make build reviews and compare layouts and actual screen states.

The goal is to test the build on different devices to make sure that it works fine and matches layouts.

Test the product for compliance with the API documentation and design.

The goal is to make sure that the documentation and the product release are consistent.

Server health monitoring.

The goal is to make sure that API implementation is stable.

Correct client-server interaction check.

The goal is to make sure that data exchange between the client and the server goes as planned.

All functionality that could be affected by changes in the product is tested.

The goal is to check that fixing bugs in the application did not lead to appearing of new bugs in related parts of the app..

The main functionality which should work a priori is tested.

The goal is to check that any work in the application did not affect the performance of those parts of the application where no work was performed.