BLOG / QA

What A Proper QA Pass Catches That Unit Tests Miss.

Real Devices, Slow Networks And Odd User Paths. Where Most Launch-Day Bugs Actually Come From.

Uzair, SQA Engineer1 min read

Unit tests prove that each piece of code does what its developer intended. They cannot prove that the product works for a person on a cheap phone, on a train, who taps the back button at the worst possible moment. That is what a QA pass is for.

Real devices

Simulators do not run out of memory, overheat or have a notch in the wrong place. We test every release on a small set of real phones, including at least one older, slower model.

Bad networks

We throttle the connection, drop it mid-request and switch between Wi-Fi and mobile data. Loading states, retries and offline messages only get tested when the network misbehaves on purpose.

  • Slow 3G and offline on every key screen
  • Requests interrupted halfway through
  • App sent to the background during a payment or upload

Odd user paths

Real users double-tap submit buttons, paste emoji into phone fields and come back to a form three days later. Exploratory testing follows those paths deliberately, because nobody writes unit tests for them.

Most launch-day bugs are not in the code anyone was worried about. They are in the paths nobody thought a user would take.
Uzair, SQA Engineer
  • QA
  • Testing
  • Release

Share this article

Written by

Uzair

SQA Engineer, Dev N Scale

Uzair leads quality assurance on our builds, from test plans in week one to the final pass before release.