The Android App QA Process: From Build to Release Candidate

A QA process is the repeatable path a build travels between the moment it compiles and the moment it is declared fit to release. Teams without one rely on individual habits, which means quality changes depending on who is around that week. This guide lays out the stages most Android teams use, what happens in each, and the handoffs that keep the flow moving.

The stages

1. Build intake: the artifact arrives with its version code, change list, and known risks.
2. Smoke test: a short pass proving the build installs and the critical path works.
3. Functional testing: features verified against their test cases.
4. Regression testing: the fixed suite confirming nothing previously working broke.
5. Bug triage: findings classified, assigned, and retested after fixes.
6. Release candidate verification: the exact signed build gets a final pass.
7. Sign-off and rollout watch: the release is approved and monitored after launch.

What happens in each stage

1. 1

   Build intake

   Record the version code, which features changed, which areas those changes touch, and any known issues. This shapes the rest of the pass: risky areas get deeper coverage, stable areas get the regression suite.

1. 1

   Smoke test

   Install, launch, sign in, reach the main content, and complete the one or two flows the app exists for. A smoke failure sends the build straight back without burning testing time on a build that was not ready.

1. 1

   Functional testing

   Run the test cases for in-scope features, including error paths and edge states, on the devices in your matrix. Every case result is recorded as pass, fail, or blocked so coverage is measurable rather than assumed.

1. 1

   Regression testing

   Run the stable suite that covers core flows across the whole app. This is the stage that catches the change in a shared library breaking a screen nobody touched.

1. 1

   Bug triage

   Each new bug gets a severity, an owner, and a retest after the fix lands. Bugs without reproduction steps go back to the reporter before they consume developer time.

1. 1

   Release candidate verification

   Test the exact signed build that will be uploaded, including an upgrade install over the previous version. Anything found here blocks sign-off until fixed and retested.

Write bugs people can act on

After sign-off

The process does not end at approval. Release the build as a staged rollout and watch Android vitals for the crash and ANR behavior of the new version against the old. Agree in advance what triggers a halt: a spike in crashes on a specific device, or any critical flow failing in the wild.

Running these stages consistently is what separates teams who ship calmly from teams who ship in panic. Organizations that want the whole path handled for them often engage AppsTestLab for the full cycle, from build intake through regression and rollout monitoring, while keeping ownership of the release itself.

Frequently asked questions