Mobile Application Testing Services

Testing finds problems before users do. After this module you can rank an app's risks and set a clear finish line, so your testing effort goes where failure would hurt users most.

• Test levels: single parts, parts together, whole app, real users.
• Types: function, usability, speed, safety, access, compatibility.
• Testing shows bugs exist; it cannot show none exist.
• Focus on risk: money, privacy and sign-in first.
• Write one sentence naming the top three risks if the app fails, such as lost payments, locked accounts or wrong data, and spend about half your test time on those areas.
• Agree on 'done' before starting: for example, no open critical bugs, 95 percent of test cases passed, and every main flow checked on at least two devices.
• Install the app fresh on one device and note how long the first run takes.
• Write the three most important user goals before writing cases.

Activity. List ten risks for a sample app and rank them.

Standard to meet. Rank with reasons.

Common mistake. Testing everything equally.

Check yourself. What are your top three risks?

You test against what the app should do. You will turn an app's promises and screens into a map of user paths and a device table, giving every later test a purpose.

• Read the requirements or user stories.
• Draw the main user paths.
• List devices, screen sizes and system versions to cover.
• Note limits: network loss, low battery, interruptions.
• Draw a simple map of screens as boxes and arrows, then count the paths from opening the app to finishing the main task; most apps have fewer than ten main paths.
• Read the store description and any help page, then list five promises the app makes; each promise is a test you can write straight away.
• Keep a list of devices and system versions tested.
• Use a clean test account for each run.

Activity. Draw the paths and a device table.

Standard to meet. Complete the paths and justify the devices.

Common mistake. Testing without knowing the intended behaviour.

Check yourself. Where did you check the requirement?

A good case is clear, small and repeatable. You will write precise, repeatable test cases with exact expected results, letting anyone rerun your checks and get the same answer.

• Fields: id, goal, steps, data, expected result.
• Include normal, edge and wrong inputs.
• One idea per case.
• Link each case to a requirement.
• Write each test case with an ID, steps numbered 1 to 5, test data, and one exact expected result such as 'order confirmation shows total of 12.50 in your currency'.
• For every input field, test an empty value, the shortest allowed, the longest allowed, one over the limit, and a special character; that is five quick cases per field.
• Record the screen for every failure.
• Note whether the fault occurs offline, on Wi-Fi or on mobile data.

Activity. Write 30 test cases.

Standard to meet. Write cases that cover every path and at least 5 edge cases.

Common mistake. Cases that combine several ideas.

Check yourself. Is each case one idea?

Real devices show real faults. You will select a small, varied set of phones and tablets and test under interruptions, finding faults that a single new handset would hide.

• Use at least two device sizes and two system versions.
• Record pass, fail, blocked.
• Capture screenshots and screen recordings.
• Repeat a failure before reporting.
• Choose devices by sorting your users into groups: pick one older low-memory phone, one recent mid-range phone and one tablet, and include both major operating systems if the app supports both.
• On each device test with the screen turned sideways, with battery saver on, and after a phone call interrupts, because these three conditions expose faults that normal use hides.
• Mark cases that need to be repeated every release.
• Check the app in a different language if offered.

Activity. Run all cases and record results.

Standard to meet. Record all 30 results with evidence for fails.

Common mistake. Testing on one phone.

Check yourself. Which devices did you use?

A report must let a developer see the bug in one try. You will draft bug reports a developer can reproduce on the first try, which saves repair time and prevents arguments over what happened.

• Title with place and symptom.
• Steps to reproduce, expected, actual, device and version.
• Picture or recording; how often it happens.
• Severity (harm) and priority (urgency) are different.
• Write the title as a short sentence saying what happened and where, then list numbered steps, expected result, actual result, device, system version and app version.
• Attach a screenshot or short screen recording under 30 seconds, and note how often it happens, such as 3 out of 3 tries, so developers know whether to chase it.
• Test rotating the screen in the middle of a task.
• Test what happens when the phone is low on storage.

Activity. Write 10 bug reports.

Standard to meet. Write each report so that a peer can reproduce it.

Common mistake. Vague bug titles.

Check yourself. Can a peer reproduce your bug?

Non-functional faults hurt users too. You will measure launch time and check sign-out, password display and permission requests, so slow or unsafe behaviour is caught before release.

• Time start-up and key screens; compare with a target.
• Check basic safety: sign-out, data shown on screen, permissions asked.
• Access: text size, contrast, screen reader labels.
• Weak network and offline behaviour.
• Check speed by timing the launch from tap to first usable screen on a mid-range phone; under 3 seconds is a good target, and note anything over 5 seconds.
• For safety, test that logging out clears the screen, that passwords are hidden, and that the app asks permission only for what it needs, such as not asking for contacts in a calculator.
• Check the privacy text matches what the app really collects.
• Report one positive finding in each summary.

Activity. Run five non-functional checks.

Standard to meet. Give each check a target and a result.

Common mistake. Ignoring weak networks.

Check yourself. What did you test offline?

Not every bug matters equally. You will sort defects by severity and spot clusters, then use that evidence to say where extra testing or fixes are needed.

• Group bugs by area and cause.
• Rank by user harm and how many are affected.
• Find patterns: one cause may explain five bugs.
• Recommend release, delay or release with limits.
• Group bugs by severity: crash or data loss is critical, a main task blocked is high, a wrong label is low. Count how many sit in each group to guide the release decision.
• Look for clusters: if six of twenty bugs sit in the payment screen, recommend extra testing there rather than treating them as six unrelated issues.
• Keep bug titles under ten words.
• Agree severity levels with developers before testing.

Activity. Build a bug summary table and rank the top five.

Standard to meet. Rank using harm and reach.

Common mistake. Ranking by how annoying it feels.

Check yourself. What is your top bug by harm?

Close the loop. You will finish with a one-page results summary and a disciplined retest, so the team can make a confident release or hold decision.

• Send a one-page summary: what was tested, found, risk, advice.
• Retest fixes and a few related areas.
• Update the case list for next time.
• Plan 90 days.
• Write a one-page summary with tests run, passed, failed, bugs by severity and a clear recommendation: release, release with known issues, or hold.
• After the fix, retest the exact steps from the original report and also run three nearby cases, since a fix in one place can quietly break another.
• Update your case list with every new bug.
• Share a lessons list with the team.

Activity. Write the summary and retest report.

Standard to meet. Lead the summary with the recommendation.

Common mistake. Not retesting.

Check yourself. What did retest find?

The app crashes when rotating on one device.

Question: How do you report it?

Model answer: Give device, version, steps, expected, actual, frequency and a recording.

Two high bugs remain with launch tomorrow.

Question: What do you advise?

Model answer: Delay or release with the feature off, based on harm and numbers.

On the slide: L1 Basic · Basics of apps

Notes: Explain what a mobile app is and what a tester does. Notes: use three apps on your phone and write one thing each does well and one thing that could fail. Standard: a clear sentence for each.

On the slide: L2 Awareness · Awareness

Notes: Describe the main test types (function, usability, device, network) and what a bug report must contain. Notes: read two sample bug reports and rate them. Standard: your rating names what is missing.

On the slide: L3 Foundation · Foundation

Notes: Write test cases for one feature from a requirement, with steps, expected result and priority. Notes: start with a login or search feature in a sample app. Standard: ten test cases that someone else can run without asking you.

On the slide: L4 Practitioner · Practitioner

Notes: Run test cases on two devices, record results and write bug reports a developer can repeat. Notes: include screenshots and the exact steps. Standard: at least five reports, each repeated by a peer.

On the slide: L5 Specialist · Specialist

Notes: Plan, run and report a test cycle for one real or sample app, with at least 30 test cases and 10 well-written bug reports. Notes: include a device list, a test summary and a risk view. Standard: summary shows pass, fail and blocked counts and the three highest risks.

On the slide: L6 Advanced · Advanced

Notes: Lead a test team with a test plan, automation for repeated checks and a release recommendation. Notes: add a regression suite and a defect trend chart. Standard: the release note says what is tested, what is not and what is risky.

On the slide: L7 Super expert · Super expert

Notes: Set the test-plan and defect-report method for mobile apps and teach the testers who apply it. Notes: review defect trends by device and release each year.