Probably more than you did while building it, but nowhere near as much as a bank needs. The useful answer depends on what the app can damage when it gets things wrong.
If this is a small side project, you can absolutely pay someone twenty bucks to have a poke around it. They will open the app, click the obvious buttons, try a few journeys and tell you if anything visibly falls over. That is not useless. A fresh pair of eyes can spot embarrassing stuff you have become blind to. For a quick outside check, even a clear testing brief is better than hoping they guess what matters.
Just know what you bought. You bought somebody clicking about. You did not buy an assessment of whether the important risks have actually been covered.
If you are staring at a finished app and genuinely do not know where ‘enough testing’ sits, that is the sort of judgement call we can make for you: what matters, what does not, and where the effort is actually worth spending.
Testing and QA are not quite the same thing
On small projects people often use ‘testing’ and ‘QA’ to mean the same thing. That is fine until it starts hiding what you are actually buying.
Testing is the hands-on bit: trying the software, looking for failures and gathering evidence about how it behaves. QA is the wider job of making quality less accidental. That can include challenging risky requirements, making the product easier to test, keeping environments and data usable, reviewing how defects are handled and learning from production failures.
You do not need a grand QA department for your first app. You do need to understand that one cheap test pass is only one slice of the problem. Somebody can click every obvious button and still never ask whether your payment design, permissions or recovery process are fundamentally unsafe.
Two small apps, two very different testing jobs
Example A: a free local club events app. No payments and no sensitive records; users can report a mistake and you can correct it quickly. First check sign-up, event creation, cancellation, permissions, mobile layout and an inaccessible venue or broken link. Ask two people who did not build it to try common tasks on different devices. Keep a brief list of anything that failed and retest the fixes. A short, inexpensive outside check may be proportionate.
Example B: a small appointment app taking deposits. Now a mistake can take money, expose bookings or leave customers without appointments. Test successful and failed payment, duplicate clicks, timeouts, retries, cancellations, refunds, booking clashes, customer data access and whether confirmation messages match the actual transaction. Check what happens when the payment service is unavailable. Use realistic test accounts and record the results. Independent professional testing becomes much easier to justify.
The difference is not the number of screens. It is the consequence of being wrong. For either app, write down the three failures you most need to avoid, the evidence you already have, who will do each remaining check and what would make you postpone launch. That gives you a test scope you can defend without inventing a heavyweight process.
Start with what would hurt
Do not begin by counting screens or writing 400 test cases because somebody on the internet said that looked professional. Ask what happens when the app is wrong.
- Can it charge somebody twice?
- Can it lose work or customer data?
- Can one user see another user’s information?
- Can a failed integration leave an order, booking or payment in limbo?
- Can a user get trapped somewhere with no obvious way out?
If the worst outcome is a wonky icon, keep the response proportionate. If the worst outcome is money disappearing or customer data wandering into the wrong account, the bar goes up rather quickly.
Then test the journeys that matter. Sign-up, login, payment, saving, editing, cancelling, deleting, recovery, integrations and anything irreversible. Try failure as well as success. Turn the connection off. Refresh at an awkward moment. Let a session expire. Enter rubbish. Do the thing twice. Users are wonderfully inventive once software leaves your laptop.
If you want us to look at what you have built and tell you where we would spend the testing effort first, get onto us. We can review the product, the risks and what you have already done, then give you a practical testing plan rather than a ceremonial spreadsheet.