How We Ensure Your App’s Quality: QA Best Practices

5.0 / 5.0
Article rating

Weak quality assurance can kill your app. While I always encourage testing from the client’s side, I also know that amateur testing is often not enough to ensure that an app won’t break and irritate users. In this article I’ll give you insights into the professional testing process and tell you about pitfalls you might encounter if you test your app by yourself.

Manual testing is rather subjective. Something that one person will suggest is a bug another will consider a feature

Can I test my app myself?

The short answer is probably not.

The long answer is this.

Manual quality assurance is often neglected by people who want to create their own mobile apps. Companies overlook it, and this results in low-quality apps that are sadly abandoned in the pit of applications with low ratings and no downloads. I often hear “we can do testing ourselves” from clients, which usually means internal acceptance by stakeholders.

While internal acceptance testing is important, it’s only one part of a complex testing process.

Manual testing is rather subjective, of course. Something that one person will suggest is a bug another will consider a feature. The human factor is present in any type of work performed by a person. But still, manual testing is currently the most reliable and high-quality form of testing as it covers all possible cases.

The role of the client and QA specialist

The quality assurance engineer becomes involved at the earliest stage of the development process: the planning stage.

At this stage, when there’s nothing to test yet, the quality assurance engineer is already participating in the project. As soon as a business analyst creates a technical specification, a QA engineer creates a test plan based on this technical document.

Clients often refuse a test plan not because they want to reduce development hours but because they don’t know what it is and why it’s important

A QA engineer also creates additional documents like checklists and test cases. Checklists are small and lack details, however they accelerate the testing process. The test plan is a big and detailed document that can include:

  • The test plan identifier
  • Introduction
  • List of test items
  • Features to be tested
  • Features not to be tested
  • Testing approach
  • Item pass/fail criteria
  • Suspension criteria and resumption requirements
  • Test deliverables
  • Testing tasks
  • Environmental needs
  • Responsibilities
  • Staffing and training needs
  • Schedule
  • Risks and contingencies
  • Approvals

A test plan is optional: some clients don’t want to create one, but the best practice is to have both a test plan and a checklist. From my experience, clients often refuse a test plan not because they want to reduce development hours but because they don’t know what it is and why it’s important.

But having a test plan for a project, especially if the project is big, is vital. The test plan gives you a clear and detailed roadmap, which is great both for a QA engineer and for an app owner. If a client has no IT expertise, they’ll still be able to understand the details of the testing process as a test plan explains all terms and abbreviations.

As a client, you also get to decide whether a QA engineer will be able to suggest changes to the UI and design.

Our quality assurance process depends on the stage of development at which we step in. Generally there are two cases:

  • We start testing at the very beginning of the project.
  • We start testing an existing app.

Let’s talk about both of these cases in more detail.

Testing from scratch

Depending on what features are in priority, a testing specialist creates test cases specific to each feature. At this point the involvement of a QA engineer is significant: they know exactly what features will need to be tested and what potential test cases can appear in the process.

The risk of missing some particular test cases is way lower when a QA engineer performs testing. App stakeholders could also perform quality assurance if they delved into the project deeply enough, but usually this doesn’t happen.

quality assurance
The bigger the project is, the more quality assurance it needs, as new features can interfere with the old ones, and everything has to be checked before the release

When development starts and the architecture has already been decided, the first features appear — for example, personal profiles and onboarding. The QA engineer then tests these features.

Then it’s time for the next features: payments, push notifications, a catalog… The quality assurance engineer tests these as well, then tests the personal profiles and onboarding again to check that the new features haven’t harmed the previous ones.

This means that the bigger the project, the more testing it requires.

Testing an existing project

If you come to us with an existing project, the first thing one of our QA engineers will do is full regression testing. Regression testing checks all existing functionality. At Mobindustry, we don’t start working on a project until full regression testing has been done.

Full regression testing allows us to understand how the app works and check if there are any issues we need to fix. Then when we implement new features, we check the app once again to see if these new features have interfered with existing functionality.

We use checklists to perform full regression testing, but we test new features with the help of test cases and testing tools we carefully choose.

QA best practices

We follow best practices that increase the quality of QA activities and allow us to release the best application possible.


Concerning documentation, it’s a great practice to have both a test plan and a checklist. The first will give both you and your QA engineer valuable information about the process of testing your app, while the checklist will enable quick testing of the whole app.

Work process

If the project is large, we also change QA engineers periodically. Why do we do that? Let me explain.

There are two types of test cases: positive and negative. A positive test case describes what should happen in the app after the user takes some action. For example, if the user types in their email and password and taps on Log in, they should be directed to their profile.

But what happens if the user types in a phone number instead of an email address? This is a simple example of a negative test case. So a negative test case is a case that shouldn’t happen but probably will as a result of unexpected user input, errors, and so on.

quality assurance error management negative cases
If a user types an unexpected value, your app should give a clear response. If there are no negative cases, or they weren’t checked properly, the app may simply crash

But why do we need to change QA engineers from time to time? QA engineers create negative test cases themselves, relying on their wits and experience. When one QA works on a project for a long time, they start to lose sharpness and perspective. That’s why it’s useful to let another QA have a fresh look at the project and make sure nothing has been missed.

Continuous integration

Continuous integration is a practice when development and quality assurance happen simultaneously and both developers and QA engineers have access to a shared repository where they’re able to review and merge code, create builds, test them, and so on.

continuous integration quality assurance
Continuous integration allows to provide high-quality code in less time by providing code and checking it in small bits

We use Jenkins to create SDKs and check them afterwards. This is a common practice at our company — it optimizes development time and delivery so you get builds faster.

Regression testing and retesting

The best practice is to perform regression testing before releasing an app to the app stores and delivering ready builds to clients.

There isn’t always a need to perform full regression testing of the whole app after each retest. A QA engineer can check only one part of an app

Unlike regression testing, retesting checks bugs that a QA has already found. It works like this: A quality assurance engineer receives a build and finds some bugs in it. The next step is to inform the developers so they can fix the feature, and then the QA engineer tests it again to see if everything has been fixed correctly.

After a series of retesting, a QA engineer needs to perform regression testing to make sure the bug fixes didn’t interfere with other functionality in the app. This doesn’t mean, however, that there’s a need to perform full regression testing of the whole app after each retest. A QA engineer can check only one part of an app (for example, the registration form) with the help of regression testing.


What do you actually pay for when you use the services of a professional quality assurance engineer? It’s not only testing but also creating documents such as a test plan, checklist, user cases, and user stories. This test documentation makes the whole development and testing process clearer.

QA engineers are also responsible for communicating with you as the client. They receive your requests for changes in the app and offer the best testing strategies for your application.

If you want your app to be reliable and stable, think about relying on the professional knowledge of quality assurance engineers. At Mobindustry, we provide high-quality QA services so you can be sure that your app will always be thoroughly tested by our professionals.

Rate the article!

🌕 Cool!
🌖 Good
🌗 So-so
🌘 Meh
🌑 …