Direct answer: "Tested" should mean every specified feature was verified against expected behavior and reasonable edge cases, coverage across the target devices and browsers, and a regression check confirming a new change did not break something that worked before. If a vendor cannot describe this beyond "we tested it," ask more specific questions before signing, not after delivery.
What a real QA process actually covers
Functional testing verifies each feature behaves as specified, including invalid input and edge cases, not just the intended happy path. Cross-device and cross-browser testing confirms the experience holds up on the platforms real users will actually use, not just the developer's own machine. Regression testing re-checks previously working functionality after each change, catching the specific failure mode where fixing one bug silently introduces another. None of this is exotic — it is standard practice that should be visible in the delivery process, not assumed to be happening invisibly.
Automated tests vs. manual testing
Automated tests for core business logic pay for themselves quickly on any project beyond a small, short-lived scope — they run on every change and catch regressions immediately, something manual testing alone cannot do consistently as a codebase grows. Manual testing stays necessary for UI/UX judgment and exploratory testing that automation cannot replace. A mature vendor uses both, and can describe roughly what is covered by each.
When load testing genuinely matters
Load testing checks how the application performs under real concurrent traffic — response times and error rates under load, not a single test session. It matters for apps expecting a traffic spike (a public launch, a sale event) or a large user base from day one. It is reasonably deferred for an early MVP with a small initial audience, provided the backend is not architecturally locked into a design that cannot later scale — see our scalable enterprise mobile app guide for that distinction.
Questions worth asking before signing
What percentage of the codebase has automated test coverage, what a pre-delivery QA checklist actually contains, which devices and browsers get tested, how regressions are caught on projects with ongoing development, and whether a past QA report or test summary can be shown as evidence. Specific, concrete answers here are a stronger signal than confident but vague reassurance.
Vendor QA vs. client UAT — different responsibilities
Building and executing the technical QA process is the vendor's responsibility as part of delivering working software, not a billable extra. User acceptance testing (UAT) — confirming the delivered software actually solves the real business problem — is the client's role, since only the client can judge that fit. Both need to happen before a project is genuinely "done."
For the broader vetting checklist this QA discussion is part of, see our guide to choosing a mobile app development company and our technical due diligence guide.
Frequently Asked Questions
At minimum: every feature in the specification has been manually or automatically verified to work as intended, edge cases and invalid input have been checked (not just the happy path), the app has been checked across the target devices/browsers it needs to support, and a prior fix has not silently broken something that worked before (regression testing). A vendor who cannot describe their process beyond "we tested it" has not actually described a process.
For anything beyond a very small or short-lived project, automated tests for core business logic are worth the upfront time — they catch regressions immediately and cheaply every time the code changes afterward, which manual testing alone cannot do reliably at scale. Manual testing remains necessary for UI/UX judgment calls and exploratory testing that automation cannot replace. A mature process uses both, weighted toward automation for logic that will be touched repeatedly.
Regression testing re-verifies that previously working features still work after a new change — without it, a fix for one bug can silently reintroduce or cause a different one elsewhere in the app. This matters most on projects with ongoing development, where the codebase keeps changing after initial launch; a vendor without a regression process is relying on manual memory to catch this, which does not scale past a small app.
Load testing verifies the application holds up under expected (and above-expected) concurrent traffic — response times, error rates, and database performance under real load rather than a single developer's test session. It genuinely matters for apps expecting a traffic spike (a launch, a sale event, a viral moment) or with a large expected user base from day one; it is often reasonably deferred for an early-stage MVP with a small initial user base.
Ask specifically: do you write automated tests, and for what percentage of the codebase; what does your pre-delivery QA checklist look like; which devices and browsers do you test against; how do you catch regressions on ongoing projects; and can you show a QA report or test summary from a past project (with client details redacted if needed). Vague answers to any of these are a real signal, not a formality to skip past.
The vendor owns building and executing the QA process as part of delivering working software — that is what "done" should include, not a separate paid add-on. The client's role is user acceptance testing (UAT): verifying the delivered software actually meets the real business need, which only the client can judge, alongside the vendor's technical QA that verifies the software works as specified.