Mobile-specific test cases in Testing Fundamentals - Framework Patterns

Framework Mode - Mobile-specific test cases

Folder Structure for Mobile Test Automation Project

mobile-test-framework/
├── appium/
│   ├── page_objects/
│   │   ├── LoginPage.js
│   │   ├── HomePage.js
│   │   └── SettingsPage.js
│   ├── tests/
│   │   ├── login.test.js
│   │   ├── navigation.test.js
│   │   └── gestures.test.js
│   ├── utils/
│   │   ├── gestures.js
│   │   ├── deviceHelpers.js
│   │   └── waitHelpers.js
│   ├── config/
│   │   ├── appium.config.js
│   │   ├── capabilities.js
│   │   └── env.js
│   └── reports/
│       └── test-report.html
├── docs/
│   └── mobile-testing-guidelines.md
└── README.md

Test Framework Layers for Mobile Testing

• Driver Layer: Manages connection to mobile devices or emulators using Appium or similar tools.
• Page Objects: Encapsulate mobile app screens and UI elements for easy interaction and maintenance.
• Test Cases: Scripts that use page objects to perform mobile-specific tests like gestures, orientation, and network changes.
• Utilities: Helper functions for gestures (swipe, tap), device state management (battery, network), and explicit waits.
• Configuration: Holds environment settings, device capabilities, app paths, and credentials for different test runs.
• Reporting: Generates readable test reports and integrates with CI/CD pipelines for automated feedback.

Configuration Patterns for Mobile Testing

• Environment Files: Separate config files for dev, staging, and production with app package names and server URLs.
• Device Capabilities: Define device name, platform version, automation engine (e.g., UiAutomator2, XCUITest) in capabilities.js.
• Credential Management: Use environment variables or encrypted files to store sensitive data like user logins.
• Dynamic Device Selection: Allow tests to run on different devices or emulators by passing parameters or using config flags.
• App Paths: Configure app installation paths or URLs for installing the app before tests.

Test Reporting and CI/CD Integration

• HTML Reports: Generate clear, easy-to-read reports showing passed, failed, and skipped tests with screenshots.
• Video Recording: Capture test runs on devices for debugging failures.
• CI/CD Integration: Connect with Jenkins, GitHub Actions, or GitLab to run tests on code commits or pull requests.
• Notifications: Send test results via email or messaging apps to keep the team informed.
• Log Collection: Collect device logs and Appium server logs for troubleshooting.

Best Practices for Mobile Test Framework Design

1. Use Page Object Model: Keep UI locators and actions separate from test logic for easier updates when app UI changes.
2. Handle Device Variations: Write tests that adapt to different screen sizes, OS versions, and device orientations.
3. Explicit Waits: Use waits for UI elements to appear or become interactable to avoid flaky tests.
4. Test Real User Scenarios: Include gestures, notifications, background/foreground app states, and network changes.
5. Keep Tests Independent: Each test should set up and clean up its own state to run reliably in any order.

Self-Check Question

Where in this folder structure would you add a new page object file for the "Profile" screen of the mobile app?

Key Result

Organize mobile tests with clear layers: driver, page objects, tests, utilities, config, and reporting for maintainability and reliability.

Practice

1. Which of the following is a key focus when writing mobile-specific test cases?

easy

A. Testing only desktop browser compatibility

B. Testing features unique to mobile devices like GPS and touch gestures

C. Ignoring screen size variations

D. Testing only backend APIs without UI

Solution

1. Step 1: Understand mobile-specific features

   Mobile devices have unique features like GPS, accelerometer, and touch gestures that desktop devices do not.

2. Step 2: Identify test case focus

   Mobile-specific test cases must focus on these unique features to find device-specific issues.

3. Final Answer:

   Testing features unique to mobile devices like GPS and touch gestures -> Option B

4. Quick Check:

   Mobile features = A [OK]

Hint: Focus on device features unique to mobile devices [OK]

Common Mistakes:

• Ignoring mobile-only features
• Testing only desktop scenarios
• Not considering touch interactions

2. Which syntax correctly describes a test step for checking screen orientation change in a mobile test case?

easy

A. Step 1: Open browser and check URL

B. Step 1: Click desktop menu and verify dropdown

C. Step 1: Rotate device to landscape mode and verify UI adjusts correctly

D. Step 1: Run backend API and check response code

Solution

1. Step 1: Identify relevant mobile action

   Rotating device orientation is a common mobile-specific action to test UI responsiveness.

2. Step 2: Match test step syntax

   Step 1: Rotate device to landscape mode and verify UI adjusts correctly clearly states rotating device and verifying UI adjustment, which fits mobile test case syntax.

3. Final Answer:

   Step 1: Rotate device to landscape mode and verify UI adjusts correctly -> Option C

4. Quick Check:

   Mobile orientation test = B [OK]

Hint: Look for steps mentioning device rotation or orientation [OK]

Common Mistakes:

• Confusing desktop actions with mobile
• Ignoring device rotation in test steps
• Using backend steps in UI test cases

3. Consider this test step in a mobile app test case:

Step 1: Enable airplane mode
Step 2: Open the app
Step 3: Verify the app shows 'No internet connection'

What is the expected result of Step 3?

medium

A. App shows 'No internet connection' message

B. App logs user out automatically

C. App loads data from server normally

D. App crashes due to no network

Solution

1. Step 1: Analyze network condition

   Airplane mode disables all network connections, so the app cannot reach the internet.

2. Step 2: Understand expected app behavior

   The app should detect no internet and show a friendly message, not crash or load data.

3. Final Answer:

   App shows 'No internet connection' message -> Option A

4. Quick Check:

   Airplane mode disables network = D [OK]

Hint: No network means app shows offline message, not crash [OK]

Common Mistakes:

• Assuming app crashes without network
• Expecting normal data load offline
• Confusing logout with network loss

4. A tester wrote this mobile test step:

Step 1: Switch device to dark mode
Step 2: Open app
Step 3: Verify app UI uses dark colors

But the test always fails. What is the most likely error?

medium

A. The device was not actually switched to dark mode before testing

B. The app does not support dark mode at all

C. The tester used wrong device model

D. The app crashed on launch

Solution

1. Step 1: Check test setup correctness

   If the device is not switched to dark mode, the app UI won't change, causing test failure.

2. Step 2: Consider app support

   While app support matters, the question says test always fails, so setup is more likely the cause.

3. Final Answer:

   The device was not actually switched to dark mode before testing -> Option A

4. Quick Check:

   Incorrect setup causes test failure = A [OK]

Hint: Verify device mode before testing UI changes [OK]

Common Mistakes:

• Skipping device mode setup
• Assuming app supports dark mode without checking
• Ignoring device compatibility

5. You need to write a mobile-specific test case to verify the app's behavior when the device battery is low (below 15%). Which of the following is the best test step?

hard

A. Step 1: Connect device to chargerStep 2: Open appStep 3: Verify app loads data quickly

B. Step 1: Open appStep 2: Check if app crashes on startup

C. Step 1: Switch device to airplane modeStep 2: Open appStep 3: Verify app shows offline message

D. Step 1: Set device battery level to 10%Step 2: Open appStep 3: Verify app shows low battery warning and reduces background activity

Solution

1. Step 1: Simulate low battery condition

   Setting battery level below 15% tests app behavior under low power.

2. Step 2: Verify app response

   The app should warn user and reduce background tasks to save battery.

3. Final Answer:

   Step 1: Set device battery level to 10%
   Step 2: Open app
   Step 3: Verify app shows low battery warning and reduces background activity -> Option D

4. Quick Check:

   Low battery test = C [OK]

Hint: Simulate battery level, check app warning and behavior [OK]

Common Mistakes:

• Testing unrelated conditions
• Ignoring battery level simulation
• Confusing network and battery tests