■ Manual Android App Testing

Complete Interview Preparation Notes

For Beginners • No Tool Experience Required

Freshers & Junior QA Testers

8+ 50+ Real-World ■ Pro Tips

Core Topics Interview Q&A Examples Included

Table of Contents
1 Core Concepts & Fundamentals Pg 2

2 Types of Testing Pg 3

3 Android-Specific Testing Pg 4

4 Bug Life Cycle & Reporting Pg 5

5 Test Case Writing Pg 6

6 Common Interview Questions & Answers Pg 7

7 Scenario-Based Questions Pg 9

8 ■ Pro Tips & Important Pointers Pg 10

 ■ 1. Core Concepts & Fundamentals

■ What is Software Testing?

Software testing is the process of evaluating and verifying that an app or software product does what it is
supposed to do. It helps find bugs before the user does.
• Ensures the app works as expected by the client/user
• Prevents defects from reaching production
• Improves quality, reliability, and user experience

■ TIP: Testing is NOT just finding bugs. It is also about building confidence in the product quality.

■ Verification vs Validation

Verification Validation

Are we building the product RIGHT? Are we building the RIGHT product?

Reviews, inspections, walkthroughs Actual testing on the product

Done without running the app Done by running / using the app

Static testing Dynamic testing

■ SDLC vs STLC
SDLC (Software Development Life Cycle): The complete process of planning, creating, testing, and delivering
software. Phases: Requirement → Design → Development → Testing → Deployment → Maintenance.
STLC (Software Testing Life Cycle): The specific testing phases within SDLC.

STLC Phase What Happens

1. Requirement Analysis Understand what needs to be tested

2. Test Planning Decide scope, resources, timeline, tools

3. Test Case Design Write test cases and test data

4. Environment Setup Prepare devices/emulators

5. Test Execution Run test cases, log defects

6. Test Closure Report summary, lessons learned

■ INTERVIEW FOCUS: SDLC vs STLC difference is a very common interview question. Remember: SDLC is the full
development process; STLC is the testing part within it.
 ■ 2. Types of Testing

■ Testing Levels

Level Who Does It What is Tested

Unit Testing Developers Individual functions/components

Integration Testing Dev/QA Communication between modules

System Testing QA Team Complete application end-to-end

UAT (User Acceptance) Client/End Users Does it meet business needs?

■ Functional vs Non-Functional Testing

Functional Non-Functional

Tests WHAT the app does Tests HOW WELL the app does it

Login, payment, search Speed, load, security, usability

Based on requirements Based on performance criteria

Examples: Smoke, Regression, Examples: Performance, Security,

Sanity, Integration Compatibility, Usability

■ Essential Testing Types — Definitions

■ Smoke Testing Quick check to verify basic functions work after a new build. 'Is the app even
launchable?'

■ Sanity Testing Narrow, focused testing after a bug fix to confirm the fix works without full
regression.

■ Regression Testing Re-testing existing features to ensure new changes haven't broken anything.

■ Exploratory Testing Simultaneous learning, test design, and execution. Tester freely explores the app.

■ Retesting Testing a specific bug that was fixed to confirm it is now resolved.

■ Usability Testing Testing how easy and user-friendly the app is for real users.

■ Compatibility Testing Testing the app on different Android versions, screen sizes, and devices.

■ Negative Testing Testing with invalid inputs to ensure the app handles errors gracefully.

■ End-to-End Testing Testing the complete user flow from start to finish (e.g., Register → Login → Buy →
Logout).

■ INTERVIEW FOCUS: Smoke vs Sanity vs Regression — These three are asked in EVERY interview. Remember:
Smoke=new build check, Sanity=after fix check, Regression=full re-check.
 ■ 3. Android-Specific Testing

■ Installation & Uninstallation Testing

• Install app fresh from Play Store or APK file
• Install on different Android versions (e.g., Android 9, 10, 11, 12, 13, 14)
• Upgrade install (install new version over old without uninstalling)
• Verify all app data is removed after uninstallation
• Reinstall after uninstall — check if onboarding appears again

■ TIP: Always test install on low-storage device scenarios — app should show proper error, not crash.

■ Interruption Testing
Test how the app behaves when it is interrupted mid-use:
• Receive an incoming phone call during app use
• Receive an SMS or push notification
• Plug/unplug charger while app is running
• Screen lock / unlock
• Switch to another app and return (background/foreground)
• Battery low notification popup
• Turn Wi-Fi ON/OFF while using app

■ STAND OUT TIP: Interruption testing is unique to mobile and impresses interviewers. Most beginners forget it!

■ Network Testing
• Test on Wi-Fi connection
• Test on mobile data (4G/5G)
• Switch from Wi-Fi to mobile data mid-session
• Test with slow/weak network (switch to 2G mode in developer options)
• Test with NO network (Airplane mode)
• App should show proper error messages — not crash or freeze

■■ IMPORTANT: Always check: Does the app show a proper 'No Internet' message? Does it auto-recover when
network returns?

■ Android-Specific Areas to Test

Back Button Does pressing back navigate correctly or exit accidentally?

Home Button App goes to background? Data preserved?

Recent Apps App visible in recent apps list? Restores correctly?

Screen Rotation Portrait ↔ Landscape — does UI adjust? Data lost?

Font Size Change System font large/small — does UI break?

Dark Mode Does app support dark mode properly?

Permissions Camera, location, storage — grant/deny each and test behavior

Push Notifications Received? Tapping opens correct screen?

Deep Links URL/link opens the correct page inside app

Battery Saver Mode App behavior changes? Restrictions apply?

■ INTERVIEW FOCUS: Permission testing is very important on Android. Test Grant/Deny for each permission and
verify app handles denial gracefully.
 ■ 4. Bug Life Cycle & Reporting

■ Bug Life Cycle (Defect Life Cycle)

The stages a bug goes through from discovery to closure:

Status Who Changes It What It Means

New / Open Tester Bug just raised, not yet reviewed

Assigned Lead/Manager Assigned to a developer to fix

In Progress Developer Developer is working on the fix

Fixed Developer Developer claims the bug is fixed

Retest Tester Tester verifies the fix

Closed Tester Fix confirmed — bug is closed

Reopen Tester Fix didn't work — bug raised again

Rejected Developer Not a bug (working as designed)

Deferred Manager Bug real but fix postponed to later release

Duplicate Lead/Tester Same bug already reported before

Won't Fix Manager Known issue but won't be fixed (low priority)

■ Bug Severity vs Priority

Severity Priority

Impact on functionality Urgency of fix

Defined by: Tester Defined by: Project Manager / Business

S1: Critical (app crash) P1: Fix immediately

S2: Major (feature broken) P2: Fix in current release

S3: Minor (partial issue) P3: Fix in next release

S4: Low (cosmetic issue) P4: Fix if time permits

■■ IMPORTANT: High Severity + Low Priority Example: App logo is broken on the splash screen — serious visually
(S2) but not urgent for business (P3).

■■ IMPORTANT: Low Severity + High Priority Example: CEO's name is spelled wrong on the home screen — minor
bug (S4) but fix ASAP (P1).

■ INTERVIEW FOCUS: Severity vs Priority distinction is a TOP interview question. Always give the examples above!

■ How to Write a Good Bug Report

Field Description

Bug ID Unique identifier (auto-generated in tools like Jira)

Title / Summary One-line clear description: e.g., 'App crashes on login with empty password'
Description Detailed explanation of the issue

Steps to Reproduce Numbered steps to recreate the bug

Expected Result What SHOULD happen

Actual Result What ACTUALLY happened

Severity Critical / Major / Minor / Low

Priority P1 / P2 / P3 / P4

Environment Device model, Android version, App version

Attachments Screenshots, screen recordings, logs

Reporter Tester who found the bug

Status New / Open / Assigned etc.

 ■ 5. Test Case Writing

■ Test Case Components

Field Description

Test Case ID Unique ID, e.g., TC_LOGIN_001

Test Case Title Short description of what is being tested

Pre-conditions What must be true before the test runs

Test Steps Step-by-step actions to perform

Test Data Input values to use

Expected Result What the app should do

Actual Result What the app actually did (filled during execution)

Status Pass / Fail / Blocked / Not Executed

Priority High / Medium / Low

■ Sample Test Case — Login Screen

Field Value

Test Case ID TC_LOGIN_001

Title Verify successful login with valid credentials

Pre-conditions App is installed. User account exists. Device has internet.

Step 1 Open the app

Step 2 Enter valid email: test@[Link]

Step 3 Enter valid password: Test@123

Step 4 Tap the Login button

Expected Result User is logged in and lands on Home screen

Actual Result (To be filled during execution)

Status Pass / Fail

■ Test Design Techniques

Equivalence Partitioning (EP): Divide inputs into valid/invalid groups. Test one value from each group.
Example — Age field (valid: 18-60): Test 30 (valid), 10 (invalid), 70 (invalid)
Boundary Value Analysis (BVA): Test at the boundaries of valid/invalid ranges.
Example — Password (6-12 chars): Test 5, 6, 7, 11, 12, 13 characters
Decision Table: Test combinations of conditions and their outcomes.
State Transition: Test how the app moves between different states.

■ TIP: EP and BVA are the most asked test design techniques. Always explain with a real example!
 ■ 6. Common Interview Questions & Answers

Q: What is manual testing?

A: Manual testing is the process of testing a software application by hand, without using automation tools. A
tester executes test cases step-by-step as a real user would, observing the behavior and reporting defects.

Q: What is the difference between a Test Plan and a Test Case?

A: A Test Plan is a document that describes the overall testing strategy, scope, schedule, and resources. A Test
Case is a specific set of steps and conditions to verify a particular functionality. Test Plan = 'What and how we
will test'; Test Case = 'Exact steps to test one thing'.

Q: What is a Test Scenario?

A: A test scenario is a high-level description of WHAT to test. Example: 'Test the login functionality.' A test case
breaks it down into exact steps. One test scenario can have multiple test cases.

Q: What is the difference between Retesting and Regression Testing?

A: Retesting: Testing the SPECIFIC bug that was fixed to confirm it is resolved. Regression Testing: Testing the
ENTIRE application after a change to ensure nothing else broke. Retesting is targeted; Regression is broad.

Q: What is Exploratory Testing?

A: Exploratory testing is unscripted testing where the tester freely explores the app without predefined test
cases. The tester simultaneously learns the application, designs tests, and executes them. It's great for finding
unexpected bugs.

Q: What information should a good bug report contain?

A: A good bug report should have: Bug ID, Title, Steps to Reproduce, Expected Result, Actual Result, Severity,
Priority, Environment (device, OS, app version), and Screenshots/attachments.

Q: What is the difference between Smoke Testing and Sanity Testing?

A: Smoke Testing is a broad, shallow test done after a new build to check if basic features work. Sanity Testing
is a narrow, deep test done after a bug fix to check if the specific fix works correctly.

Q: What is Alpha and Beta Testing?

A: Alpha Testing is done by the internal QA team before releasing to users. Beta Testing is done by a limited
group of real users in a real environment before the final public release.

Q: Explain the Bug Life Cycle.

A: New → Assigned → In Progress → Fixed → Retest → Closed (or Reopened if fix fails). Special statuses
include: Rejected (not a bug), Deferred (fix later), Duplicate (already reported), Won't Fix (acknowledged but not
fixed).

Q: What is Usability Testing?

 A: Usability testing checks how user-friendly and intuitive the application is. It focuses on the user experience —
can real users easily accomplish their goals without confusion or errors?

Q: What would you test for a mobile app login screen?

A: Positive cases (valid credentials), Negative cases (wrong password, empty fields, invalid email format), UI
checks (alignment, font, button states), Password masking, 'Forgot Password' link works, 'Remember Me'
functionality, Session expiry, Multiple failed login attempts lockout, Keyboard type (email keyboard for email
field), Back button behavior.

Q: What is Compatibility Testing in Android?

A: Testing the app on different Android OS versions (e.g., Android 9-14), different device brands (Samsung,
OnePlus, Xiaomi), different screen sizes (phone, tablet), and different screen resolutions to ensure consistent
behavior.
 ■ 7. Scenario-Based Questions

These are practical questions asked to test your real-world thinking:

Scenario: You find a critical bug just 1 hour before release. What do you do?

How to Answer:
1. Document the bug immediately with full details and severity.
2. Inform your lead/manager and development team right away.
3. Do NOT stay silent — communication is key.
4. Let the stakeholders decide: delay release, release with known issue, or hotfix.
5. Your role is to report; the decision is the manager's.

Scenario: How would you test a new Android e-commerce app from scratch?

How to Answer:
Cover these areas:
1. Installation & launch
2. Registration & Login (positive + negative)
3. Product search, filter, sorting
4. Add to cart, remove from cart
5. Checkout & payment flow
6. Order confirmation & email/notification
7. Profile management
8. Network interruption during payment
9. Orientation change mid-checkout
10. Compatibility on multiple Android versions

Scenario: A bug you reported is marked 'Rejected' by the developer. What do you do?

How to Answer:
1. Review the bug — maybe it IS working as designed.
2. Reproduce the bug again and record a video if possible.
3. Discuss politely with the developer, sharing your evidence.
4. Check the requirement document — is it mentioned?
5. If disagreement continues, escalate to the test lead or PM.
6. Document everything for reference.

Scenario: How would you test a payment screen?

How to Answer:
1. Valid card details → payment success
2. Expired card, wrong CVV, insufficient balance
3. Network drop during payment
4. App goes to background during payment
5. Double-tap the Pay button (prevent duplicate charges)
6. Screen rotation during payment
7. Payment confirmation notification received
8. Transaction shows in history
9. Refund/cancellation flow
 ■ 8. Pro Tips & Important Pointers

■ Top 10 Interview Tips

Know your basics cold

01 SDLC, STLC, Bug Life Cycle, Severity vs Priority — these come up in every interview. Practice them until
they feel automatic.

Give real-world examples

02 Don't just define terms. Say 'For example, if the Login button doesn't respond, that's a Critical (S1) bug.'
Examples make you memorable.

Prepare scenario answers

03 Interviewers LOVE to ask 'What would you test in...' questions. Practice answering for: Login, Registration,
Payment, Search, Settings.

Admit what you don't know

04 Never bluff. Say 'I haven't used that tool yet, but I am a quick learner and willing to learn.' Honesty +
eagerness beats lying.

Show testing mindset

05 Testers think about WHAT CAN GO WRONG. In the interview, show that you naturally think about edge
cases and failure scenarios.

Understand mobile specifics

06 Mention interruption testing, permission handling, orientation testing — these show you understand mobile
testing, not just generic web testing.

Know bug report format

07 Be ready to write or describe a bug report on the spot. Practice writing clear, professional bug reports.

Learn the vocabulary

08 Use terms correctly: 'I would log a defect' not 'I would tell someone.' 'I would create a test case' not 'I would
write steps.' Professional language matters.

Ask smart questions

09 Ask the interviewer: 'What devices do you test on?', 'What test management tool does the team use?',
'What is the release cycle?' — shows genuine interest.

Stay calm on tough questions

10 If a question is tough, think aloud: 'That's a great question. Let me think about it...' Interviewers appreciate
structured thinking over silence or panic.

■ Quick Revision Checklist — Before the Interview

■ Can I define: Manual Testing, SDLC, STLC, Bug Life Cycle?

■ Can I explain: Smoke vs Sanity vs Regression Testing?

■ Can I explain: Severity vs Priority with examples?

■ Can I write a complete test case for a Login screen?

■ Can I describe all fields in a good bug report?

■ Can I list Android-specific test areas (interruption, permissions, orientation)?

■ Can I answer: 'How would you test a payment screen?' with 8+ points?

■ Can I explain Equivalence Partitioning and BVA with examples?

■ Do I know the difference between Functional and Non-Functional testing?

■ Am I ready to answer: 'Tell me about yourself' with a QA-focused answer?

■ Android Manual Testing Interview Notes Good Luck with your Interview! ■