4.1 Mobile application testing

Mobile application testing is the planned process of checking that an app works correctly, safely and comfortably on the devices, networks and users it was built for. Mobile apps face conditions that desktop software rarely meets: small screens, many device models, interrupted connections, limited battery and memory, and users who are distracted or on the move. Example: a building contractor releases a site-reporting app that lets supervisors photograph progress and submit daily reports. If it is tested only on the developer's new phone and office Wi-Fi, it may crash on an older handset or lose reports on a weak signal at the site. Testing is done in layers, starting with the smallest pieces of code and ending with the whole app in the hands of real users.

4.1.1 Unit test

A unit test checks the smallest testable part of an app, such as a single function, method or class, in isolation from the rest of the system. It is written and run by the developer, usually while the code is being written, so that faults are found when they are cheapest to fix. Example: a SACCO app contains a function that calculates loan interest. A unit test feeds the function known values and compares the result with the answer worked out by hand.

Formula: interest = principal × rate × time
Substitution: interest = 100,000 × 0.12 × 1
Working: 100,000 × 0.12 = 12,000
Result: expected interest = Ksh 12,000

If the function returns any other value for these inputs, the test fails and the developer corrects the code before it is combined with other parts.

Key features of a good unit test:

• Isolation: The unit is tested alone. Anything it depends on, such as a database or a web service, is replaced by a stub or mock (a simple stand-in that returns fixed values), so a failure points to the unit itself.
• Repeatability: The test gives the same result every time it is run, whatever the time, device or network.
• Automation: Tests run automatically after every change, so a new fault is noticed within minutes.
• Speed: Unit tests run in fractions of a second, so developers can run hundreds of them often.
• Boundary and invalid inputs: Tests include zero, negative, very large and empty values as well as normal ones.
• Independence: One test does not rely on the result or leftover data of another.

Steps for writing a unit test:

1. Identify the unit. Choose one function or class with a clear purpose, for example the interest calculation.
2. Define expected behaviour. Write down, from the requirements, what the unit must return for given inputs.
3. Arrange the test data. Prepare inputs, and create stubs or mocks for any dependencies.
4. Act. Call the unit with the prepared inputs.
5. Assert. Compare the actual output with the expected output and mark the test as pass or fail.
6. Add boundary and error cases. Repeat with a principal of zero, a negative principal, a missing rate and a very large amount, and check that the unit rejects or handles each correctly.
7. Run and keep the tests. Run the tests after every code change so that they also serve as a safety net for future edits.

4.1.2 Integration test

An integration test checks that separately built modules work correctly when they are connected. Each module may pass its unit tests and still fail when it exchanges data with another, because of mismatched data formats, wrong assumptions about order of calls, or errors in how one module handles another's failure. Example: a hospital appointment app has a booking module, a patient database and an SMS reminder service. Integration testing confirms that when a patient books a slot, the record is saved in the database with the right date and the reminder service sends the message to the correct phone number.

Common integration approaches compare as follows:

What integration tests usually check:

• Module interfaces: Data passed between modules has the right type, format and units, for example dates sent as the receiving module expects.
• Database interaction: Records are created, read, updated and deleted correctly, and nothing is lost when two modules write at once.
• API calls: The app sends correct requests to back-end services and handles the responses, including error codes and empty replies.
• Third-party services: Links to payment gateways, SMS providers, maps and push notifications behave as documented.
• Error handling between modules: When one module fails or times out, the others show a clear message rather than crashing.
• Device services: The app works properly with the camera, GPS, storage and notifications provided by the phone.

4.1.3 Usability test

A usability test measures how easily, efficiently and satisfactorily real users can complete tasks with the app. Code can be technically correct and still be abandoned because menus are confusing, buttons are too small to tap or text is hard to read outdoors. Example: a school develops an app for parents to check fee balances and download report forms. Ten parents of different ages and phone experience are asked to find a balance and download a form while an observer notes where they hesitate or make mistakes.

Common usability measures:

• Task success rate: The percentage of users who complete a task correctly.
• Time on task: How long users take, compared with a target.
• Error rate: How many wrong taps, wrong entries or backtracking steps occur.
• Satisfaction: Users' own rating of the experience, collected by a short questionnaire or interview.
• Learnability: How quickly a new user becomes comfortable without help.

Formula: task success rate = (users who completed the task ÷ users who attempted it) × 100
Substitution: task success rate = (8 ÷ 10) × 100
Working: 0.8 × 100 = 80
Result: task success rate = 80%

If the target was 90%, the design of that task needs improvement.

Steps for running a usability test:

1. Set objectives. Decide what is being tested, for example "a parent can view a fee balance in under 30 seconds".
2. Select representative users. Choose people who match the real audience in age, experience and language, not only colleagues.
3. Write realistic tasks. Give scenarios such as "Find out how much fee is outstanding for your child", without telling users where to tap.
4. Observe the sessions. Watch quietly, note hesitations, wrong taps and comments, and record the session with permission.
5. Collect feedback. Ask users afterwards what they found confusing, slow or pleasant.
6. Analyse the results. Calculate the measures, group the problems and rank them by how many users were affected and how serious they were.
7. Improve and retest. Change the design, then test again with new users to confirm that the problems are solved.

Mobile-specific points to observe include touch target size, readability in bright sunlight, use with one hand, clear feedback after each tap, and sensible behaviour when the user rotates the screen or receives a call.

4.1.4 System testing

System testing evaluates the complete, fully integrated app against the specified requirements. The tester treats the app as a black box: they do not look at the code but use it as a user would and check that each requirement is met from start to finish. Example: a bank's mobile app is tested through a full journey of logging in, checking a balance, transferring money to another account, viewing the mini statement and logging out. The tester confirms that the amount deducted, the amount received and the entries on the statement all agree.

What system testing covers:

• End-to-end scenarios: Complete business flows are run from the first screen to the last, rather than single features.
• Functional requirements: Every requirement in the specification is mapped to at least one test case and marked as passed or failed.
• Regression testing: Earlier working features are retested after fixes to make sure nothing was broken.
• Interruption testing: The app is tested when a call, SMS, low-battery warning or loss of network arrives in the middle of a task, for example during a transfer.
• Installation, update and uninstall: The app installs cleanly, keeps user data after an update and removes itself properly.
• Data integrity and recovery: After a crash or restart, data is not lost or duplicated, and incomplete transactions are rolled back or completed correctly.
• Non-functional requirements: Security, performance and compatibility are also verified against requirements, in detail as described in the sections that follow.

Defects found are recorded with the steps to reproduce them, the expected and actual results and a severity rating, so that developers can fix them and testers can retest. The app is normally accepted for release only when all critical defects are closed.

4.1.5 Security test

A security test checks whether the app protects its users, their data and the back-end systems from misuse. Mobile apps are especially exposed because they live on devices that can be lost, stolen, rooted or infected, and they communicate over networks that may be untrusted. Example: a county government revenue app lets residents pay market fees and land rates. Security testing checks that a resident cannot see another person's payment record, that the payment details cannot be intercepted, and that a stolen phone does not give access to stored data. Kenya's Data Protection Act, 2019 places duties on organisations that handle personal data, so protecting such data is a legal as well as a professional concern.

Areas covered by a security test:

• Authentication: Login, password rules, PIN or biometric checks and lock-out after repeated wrong attempts are tested for weaknesses.
• Authorisation: A user can reach only the data and actions allowed for their role, for example an ordinary user cannot call an administrator function.
• Session management: Sessions expire after inactivity, and a logged-out session cannot be reused.
• Data in transit: Communication with servers uses encryption such as HTTPS, and the app rejects invalid certificates.
• Data at rest: Passwords, tokens and personal details are not stored in plain text in files, logs, caches or screenshots on the device.
• Input validation: Entered data is checked so that attacks such as SQL injection cannot reach the database.
• Permissions: The app requests only the device permissions it really needs, such as camera or location.
• Code protection: The app is checked for hard-coded keys, and for how easily it can be reverse engineered or tampered with.
• API security: Back-end services refuse unauthenticated or malformed requests.

Steps in a security test:

1. Identify assets and threats. List what must be protected, such as payment records and personal details, and who might attack them.
2. Review the design and code. Look for insecure storage, weak encryption and hard-coded secrets.
3. Scan for known weaknesses. Check the app and its server against recognised lists of mobile risks, such as the OWASP Mobile Top 10.
4. Perform manual attack tests. Try to bypass login, change request data, access other users' records and read stored files.
5. Record and rate findings. Describe each weakness, how it was exploited and how serious it is.
6. Fix and retest. Correct the faults and confirm that the same attack no longer works.

4.1.6 Performance test

A performance test measures how fast, responsive and stable the app is under expected and extreme conditions. Users quickly abandon apps that start slowly, freeze or drain the battery, and servers that fail under heavy demand can stop business altogether. Example: a hotel booking app works well with 20 users in the office, but during the December holiday season thousands of guests search rooms and pay at the same time. Performance testing simulates that demand beforehand to find out whether the app and its servers cope.

Main performance measures:

• Response time: The time between a user action and the app's reply.
• Launch time: How long the app takes to open and become usable.
• Throughput: The number of requests the system handles per unit time.
• Resource use: CPU, memory, battery and mobile data consumed by the app.
• Error rate under load: The share of requests that fail as demand increases.

Formula: throughput = number of requests ÷ time in seconds
Substitution: throughput = 12,000 ÷ 60
Working: 12,000 ÷ 60 = 200
Result: throughput = 200 requests per second

Types of performance test:

• Load test: Applies the expected number of users to confirm that targets for response time are met.
• Stress test: Pushes demand beyond the limit to find the breaking point and see how the system fails and recovers.
• Endurance (soak) test: Runs a steady load for many hours to reveal memory leaks and slow degradation.
• Spike test: Applies a sudden jump in users, such as a booking offer announced to many customers at once.
• Scalability test: Increases load step by step to see whether adding server capacity gives proportional improvement.

Mobile-specific checks include behaviour on slow or changing networks, battery drain during long use, performance on low-memory phones, and how quickly the app resumes after being in the background.

4.1.7 Compatibility test

A compatibility test checks that the app installs and works correctly across the range of devices, operating system versions, screen sizes and network conditions used by its audience. Unlike a desktop product, a mobile app meets hundreds of device models with different hardware, manufacturers' customisations and software versions. Example: a farm produce marketplace app is used by farmers on inexpensive Android phones with small screens and by buyers in town on newer handsets. Compatibility testing confirms that prices, photos and order buttons display and work properly on both, including over slow mobile data.

Dimensions of compatibility:

• Operating system versions: The app is run on the oldest version it claims to support, the newest releases and those in between, because features and permission rules change between versions.
• Device hardware: Processor speed, memory, storage, camera quality and sensors differ and can cause crashes or missing features.
• Screen size and resolution: Layouts, text and images must fit small, large and high-density screens, and in both portrait and landscape orientation.
• Network conditions: The app is tried on Wi-Fi, 4G, slow 2G or 3G connections and with the connection switching or lost.
• Backward and forward compatibility: New versions of the app must still read data created by older versions, and the app should behave well on operating systems released after it.
• Other software on the device: The app should coexist with other apps, keyboards, accessibility settings and security software without conflict.
• Language and regional settings: Date formats, currency such as Ksh, and languages such as English and Kiswahili display correctly.

Steps for planning compatibility testing:

1. Study the target users. Find out which phones and operating system versions the audience actually uses.
2. Build a device matrix. Choose a manageable set of devices that covers the main brands, versions, screen sizes and performance levels.
3. Prepare test cases. Select the key flows, such as install, login, ordering and payment, to be run on every device in the matrix.
4. Run tests on real devices and emulators. Real devices show true behaviour, while emulators allow quick checks of many configurations.
5. Record results by device. Note which combinations pass or fail and the exact symptom, such as a cut-off button or a crash on start.
6. Fix and retest. Correct the layout or code problems and repeat the tests on the affected devices before release.