Mobile App Testing Checklist: How to Test an App Before Launch in Nigeria

An app that works on the developer's phone in an air-conditioned office in Lekki is not the same as an app that works for a customer on a ₦60,000 Android phone with 300MB of data left, standing under a shed in Alaba market. Nigerian conditions are the test. Apps that skip real-device and real-network testing launch to one-star reviews about "not loading" and "money deducted but order not showing", and those reviews are hard to recover from.

This checklist is written for the business owner or product manager who commissioned the app, not only for the developer. It explains what each kind of test covers, who should do it, and how to run an acceptance test before you sign off. It pairs with Mobile App Requirements Checklist for Nigerian Businesses) and Mobile App Launch Checklist).

Who tests what: developer versus business

The developer is responsible for technical testing: unit and integration tests, device and OS coverage, performance, security and store compliance. The business is responsible for acceptance testing: confirming on real phones that the app does what the requirements document says, with real Nigerian payment methods, staff workflows and customers. Both are needed; neither replaces the other.

Put this split in the contract so testing is not assumed to be somebody else's job. What Should Be Included in an App Development Contract?uses.

Testing phases and when they happen

Testing is not a single week before launch. It runs through the project in phases, and each phase catches different problems.

If a quote or timeline shows testing only as "one week of QA" at the end, ask how the other phases are covered.

The twelve-area mobile app testing checklist

1. Functional testing against requirements

• Every must-have feature in the requirements document has at least one test case.
• Each user role (customer, rider, staff, admin) can complete its main journeys end to end.
• Failure paths behave correctly: payment declined, item out of stock, slot taken, OTP expired.
• Forms validate inputs (phone numbers, amounts, dates) and show helpful errors.
• Edge cases: empty states, very long names, zero-value orders, duplicate submissions from double taps.
• Data created in the app appears correctly in the admin dashboard, and vice versa.

2. User interface and experience

• Layouts work on small screens (5-inch phones) and large screens without clipping.
• Text is readable; buttons are large enough to tap with a thumb.
• Loading states, empty states and error messages are clear and in plain English.
• Navigation is consistent; the back button behaves as Android users expect.
• Images are compressed and load progressively.

3. Device and OS coverage

• Tested on real low-end and mid-range Android devices common in Nigeria (entry-level Tecno, Infinix, itel and Samsung models), not only flagships.
• Tested on the oldest Android version the requirements promise to support.
• Tested on at least two iPhone generations, including an older model, if iOS is in scope.
• Tested with limited storage and low RAM: the app should not crash when the phone is full.
• Tested after the app has been installed, updated and reinstalled (data migration between versions).

4. Network conditions

• Works on 2G and 3G speeds, with acceptable loading and clear progress indicators.
• Handles network drops mid-action without losing data or double-charging.
• Switching between mobile data and Wi-Fi does not break sessions.
• Offline behaviour matches requirements: queued actions sync correctly when the connection returns.
• Retry logic does not create duplicate orders, bookings or payments.
• Time-outs are handled with a message, not a frozen screen.

5. Performance, battery and data usage

• Cold start time is acceptable on a low-end phone (measure it; agree a target such as under four seconds).
• Key screens load within the agreed target on 3G.
• Data usage per typical session is measured and reasonable; heavy images and background refresh are controlled.
• Battery drain is acceptable for apps that use location or run in the background (rider and tracking apps).
• App size at install is within the agreed limit.

6. Payments

• Card payment succeeds and fails correctly in the gateway's test mode, including 3D Secure prompts.
• Bank transfer to a virtual account is recognised and the order or booking updates automatically.
• USSD payment flow completes and confirms.
• Live-mode test with small real amounts by each method before launch; verify settlement in the gateway dashboard.
• Failed and abandoned payments leave the order in the correct state and do not lock the customer out.
• Duplicate payment protection: a double tap or retry does not charge twice.
• Receipts (in-app, email, SMS) show the correct amount, reference and business name.
• Refund or reversal flow works and reconciles.
• Amounts display with naira symbol and thousands separators; no rounding errors on totals and fees.

How to Add Payments to a Mobile App.

7. Notifications and messaging

• Push notifications arrive on Android and iOS, with the app open, in the background and closed.
• Tapping a notification opens the right screen.
• SMS OTP arrives within a reasonable time across major Nigerian networks; resend works; fallback works when SMS is delayed.
• Email confirmations render correctly and do not land in spam for common providers.
• WhatsApp notifications, if used, deliver with approved templates and correct variables.
• Users can control notification preferences; opting out is respected.

8. Security

• All traffic uses HTTPS; no sensitive data in logs, URLs or local storage in plain text.
• Authentication cannot be bypassed; sessions expire; logout works everywhere.
• Role-based access is enforced on the server, not only hidden in the interface (a customer cannot call admin functions).
• Payment keys and API secrets are not embedded in the app in a way that can be extracted.
• Input validation and rate limiting protect against abuse (OTP flooding, brute force).
• The developer has run a security review or penetration test against a recognised standard such as the OWASP Mobile Application Security guidance, and a report is available.

9. Data protection and privacy

• Privacy notice is accessible before sign-up and matches what the app actually collects.
• Consent is requested for location, contacts, camera and marketing, only when needed, with clear explanations.
• Personal data is encrypted at rest and in transit; sensitive data (health, financial, ID documents) has additional access controls.
• Account deletion removes or anonymises data as the notice promises.
• Data sent to third parties (analytics, payment, AI, messaging) is documented and limited.
• The business has reviewed its obligations under the Nigeria Data Protection Act 2023 with the NDPC's guidance or a qualified adviser; this checklist is not legal advice.

10. Localisation and Nigerian formats

• Nigerian phone number formats are accepted (with or without +234, leading zero).
• Naira amounts, dates and times display correctly and consistently.
• Addresses accept landmarks and areas, not only street numbers and postcodes.
• Nigerian states, cities and delivery zones are correct and complete in dropdowns.
• Any Pidgin or local-language content is reviewed by a native speaker.

11. Accessibility and usability basics

• Text scales with system font size without breaking layouts.
• Colour contrast is sufficient in sunlight; colour is not the only indicator of status.
• Screen reader labels exist for key controls (a low-cost improvement that widens the audience).
• A first-time user can complete the core journey without instruction; watch three people try it.
• Error messages tell the user what to do next.

12. Regression, admin and release readiness

• A regression test list exists and is run before every release.
• Admin dashboard workflows are tested by the staff who will use them, for a full simulated day.
• Reports and exports match the underlying data.
• Analytics and crash reporting are working and reporting real events.
• Version numbers, build settings and environment configuration (test versus live keys) are correct.
• Store listing screenshots and descriptions match the app that will ship.

What changes when you test for Nigerian users

Testing for Nigerian users means testing on entry-level Android phones, on 2G and 3G connections in real locations, with bank transfer and USSD payments as well as cards, with SMS OTP across all major networks, and with power interruptions and low battery in mind. Tests that pass only on a flagship phone on office Wi-Fi tell you very little about how the app will behave for customers.

Practical adjustments:

• Buy two cheap test phones. An entry-level Android with limited RAM and storage, and a mid-range model. Test everything on them.
• Test in real places. Take the app to a market, a bus, a mall basement, and the areas your customers live in. Network behaviour differs by location and by operator.
• Test each operator. OTP delivery, data speeds and USSD behaviour vary across MTN, Airtel, Glo and 9mobile. Use SIMs from at least two.
• Test during peak periods. Evening congestion, end-of-month salary week and festive traffic stress both networks and your backend.
• Test with real money. Small live payments by transfer, card and USSD, verified in the gateway dashboard, are the only way to be sure reconciliation works.
• Test staff workflows on their phones. Riders, teachers, nurses and agents use whatever phone they own; the staff app must work there.
• Test with a dying battery and interrupted power. Apps that hold unsaved state lose data when the phone dies at 3%.

How to write a test case a non-technical team can run

A test case is a short script anyone can follow. It needs an ID, a starting condition, numbered steps, the expected result and space for the actual result.

Example format:

• ID: PAY-03
• Title: Pay for an order by bank transfer on a mid-range Android phone over mobile data
• Precondition: Logged in as a customer; one item in cart; using a Tecno test phone on Airtel data
• Steps: 1. Tap Checkout. 2. Choose Bank Transfer. 3. Transfer the exact amount from a bank app to the account shown. 4. Return to the app and wait.
• Expected result: Within two minutes the order status changes to Paid, a receipt appears in-app and by SMS, and the order shows as Paid in the admin dashboard.
• Actual result: (tester fills in)
• Pass or fail: (tester fills in)

Write one or two test cases per must-have feature, a few for the failure paths (declined card, wrong transfer amount, OTP expired) and a few for each staff role. Twenty to forty test cases cover most SME apps. Run them on each test phone and record results in a shared spreadsheet; the developer works from the fails.

Example (hypothetical): acceptance testing a food delivery app in Lagos

Example (hypothetical): a Lagos restaurant group commissions a customer app and a rider app for delivery within Lekki, Victoria Island and Ikoyi. Before launch, the operations manager runs a two-day acceptance test.

Day one, in the office: 32 test cases across ordering, payments (card, transfer, USSD, pay on delivery), rider assignment, status updates, notifications and the admin dashboard. Results: 27 pass; five fail. The failures include a double order created by a double tap on the Pay button, a transfer that reflected in the gateway but not in the app for eleven minutes, and a rider app screen that overflowed on a small phone.

Day two, in the field: the manager orders from a car in traffic on the Lekki-Epe expressway, from a market stall on 2G, and from a home in Ikoyi during evening congestion. A rider runs deliveries on their own three-year-old phone. New findings: the rider app drains battery quickly with continuous GPS, the customer app shows a blank screen when data drops mid-checkout, and OTP by SMS on one operator takes over three minutes at peak time.

The developer fixes the double-tap, adds a webhook retry for transfer confirmation, reduces GPS polling frequency, adds an offline message with retry, and adds a "call me with the code" fallback for OTP. A retest passes. None of these issues would have been found on office Wi-Fi with a flagship phone, and every one of them would have produced a bad review in launch week.

Running a beta with real Nigerian users

A closed beta puts the app in the hands of 20 to 100 real users for two to six weeks before public launch. It is the last chance to catch confusion and payment edge cases at small scale. Use Apple's TestFlight for iOS and Google Play's internal or closed testing tracks for Android; both let you distribute builds without a public listing.

• Recruit beta users from your real customer base (loyal WhatsApp customers, staff families, a pilot branch), across phone types and locations.
• Give them three tasks to complete and a WhatsApp group or form for feedback.
• Turn on crash reporting and analytics so you see what they do, not only what they say.
• Run live payments with real small amounts and verify settlement.
• Watch support requests: what people ask is what the app fails to explain.
• Fix, release a new beta build, and confirm fixes with the same users.
• Record the beta findings; they become launch-week FAQs and support scripts.

Google Play has at times required new personal developer accounts to complete a closed test before production access; check the current policy and allow time for it. How to Publish an App on Google Play Store.

Mistakes that let bugs reach customers

• Testing only on the developer's phone. The single biggest cause of "app not working" reviews in Nigeria.
• Skipping live payment tests. Test mode proves the integration; only live small payments prove reconciliation and settlement.
• Signing off from a demo. A demo is a guided tour; acceptance testing is you driving, with test cases, on your phones.
• Not testing staff workflows. The customer app works, the admin does not, and operations collapse in week one.
• No regression list. Every release after launch breaks something that used to work.
• Ignoring OTP delivery. If OTP fails, nobody gets past the first screen; test it across operators and at peak times.
• Treating security testing as optional. A breach costs more than a penetration test, and the NDPA expects reasonable measures.

Conclusion

Testing is what turns a finished build into an app customers can rely on. Split responsibilities clearly, test in phases rather than in a rush at the end, use the twelve-area checklist to make sure nothing is assumed, and run acceptance tests on the phones and networks your customers actually use, with real Nigerian payments. A two-day field test and a small beta cost a fraction of a bad launch week, and they are the difference between an app that earns trust and one that earns one-star reviews.

If you are approaching launch and want an independent acceptance test plan, or a development partner that builds real-device, real-network and live-payment testing into every release, Linestech can help you test properly before your customers do it for you.

Frequently asked questions

How long should testing take before launch?

For a typical SME app, allow two to four weeks between the last feature being finished and store submission: one to two weeks of acceptance and real-world testing, then a beta of two to four weeks that can overlap with fixes. Complex apps with payments, real-time features or multiple roles need longer.

Can the business test the app without technical staff?

Yes. Acceptance testing is about following test cases on real phones and recording what happens. A non-technical manager can run it well with a written test list, two test phones and a spreadsheet. The developer handles technical testing and fixes.

Which phones should we test on?

The phones your customers and staff actually use. For most Nigerian consumer apps that means at least one entry-level Android and one mid-range Android from brands common in Nigeria, plus an older and a newer iPhone if iOS is in scope. Ask the developer what their device coverage includes and fill the gaps yourself.

How do we test payments safely?

Use the gateway's test mode for most testing, then make a small number of live payments with real small amounts by card, transfer and USSD before launch. Check each one in the gateway dashboard and in your admin. Refund the test payments afterwards to confirm the refund flow works.

What is regression testing and why does it matter after launch?

Regression testing re-runs a fixed list of core test cases before every new release to confirm that old features still work after new changes. Without it, an update that adds a feature can silently break payments or login. Keep the list short (the core journeys and payments) and run it every time.

What should the developer hand over from testing?

A test report showing test cases run and results, device and OS coverage, known issues with severity, the security review or penetration test report, and the regression list. Ask for these before final payment.

Sources and further reading

Figures, platform rules and regulations change. These are the primary references behind this article and the places to check before you act on it.

• Nigeria Data Protection Commission (NDPC)
• OWASP Top 10
• Google Play Console