How to Write Test Cases for Settings Page (With Examples)

How to Write Test Cases for Settings Page (With Examples)

How to Write Test Cases for Settings Page (With Examples)

A settings page is often the hub where users adjust preferences, manage accounts, toggle features, and control privacy. Because it touches almost every aspect of an application, defects here can erode trust, cause data loss, or block core workflows. Writing effective test cases for this page requires a systematic approach that captures positive verification, negative validation, edge‑condition probing, and traceability to requirements. This guide walks you through the anatomy of a solid test case, provides a concrete matrix of 20+ examples, shows how to prioritize and maintain traceability, and explains how autonomous exploration (e.g., with SUSA) complements manual design to achieve real coverage.

Understanding the Settings Page Test Scope

Before writing any test case, you need to decompose the settings page into its functional domains. Most settings pages share common categories, though the exact labels vary by product. Identifying these categories helps you ensure that no area is overlooked and gives you a natural way to group test cases.

Common UI Elements and Interaction Patterns

• Toggle switches for enabling/disabling features (e.g., notifications, dark mode).
• Input fields for text entry (e.g., display name, email, API key).
• Dropdowns or pickers for single‑selection choices (e.g., language, time zone, theme).
• Multi‑select lists for choosing several options (e.g., notification categories, allowed file types).
• Buttons that trigger actions (e.g., “Save”, “Reset to defaults”, “Delete account”).
• Links or navigation items that open sub‑screens (e.g., “Privacy”, “Security”, “About”).
• Informational banners or badges that show status (e.g., “2‑step verification enabled”, “Storage used: 3.2 GB”).

Each of these elements can be exercised with a set of generic test ideas: verify default state, verify state change persists after navigation, verify invalid input is rejected, verify required fields are enforced, and verify that the UI reflects the underlying model instantly.

Functional Areas to Cover

1. Account & Profile – username, email, password, profile picture, linked social accounts.
2. Preferences & Appearance – theme, language, font size, layout density, orientation lock.
3. Notifications – global toggle, per‑channel switches, sound/vibration, do‑not‑disturb schedule.
4. Privacy & Security – two‑factor auth, login sessions, data export/delete, app permissions, ad personalization.
5. Data & Storage – cache clearing, download location, sync frequency, backup/restore.
6. Advanced / Developer – API keys, webhook URLs, debug logging, feature flags, experimental options.
7. Legal & About – terms of service, license attributions, version number, support contact.

By mapping each of these areas to the UI elements listed above, you create a matrix that guides test case creation. For example, the “Account & Profile” area will involve text fields (username, email), a password field with strength meter, a file picker for avatar upload, and a button to save changes.

Anatomy of a Test Case

A well‑structured test case makes it easy to review, automate, and maintain. While templates vary, the following fields are essential for settings‑page testing.

Including postconditions is especially valuable for settings tests because many actions mutate persistent state; failing to reset can cause cascading false positives in later tests.

Positive Test Cases

Positive test cases verify that the settings page works as intended when users follow the happy path. Below is a table of 12 representative cases covering the most common functional areas. Feel free to extend or adapt them to your product’s specific UI.

These cases give you a solid baseline. Each one can be automated with UI‑driven tools (Appium for mobile, Playwright for web) or executed manually during exploratory sessions.

Negative Test Cases

Negative testing ensures the settings page gracefully handles invalid input, unexpected states, and misuse. The following table lists 12 negative scenarios, each with a clear expected failure mode.

Negative cases are crucial for uncovering validation gaps, race conditions, and UI stability issues that only manifest under stress or erroneous input.

Edge and Boundary Cases

Edge cases push the limits of data types, device capabilities, and system configurations. Boundary testing focuses on minimum/maximum values, empty states, and transitions around those limits. Below are six edge/boundary scenarios that often reveal defects missed by basic positive/negative tests.

These cases test the limits of UI scaling, input validation, time‑zone handling, and dynamic localization—areas where defects often escape notice until a real‑world user hits an extreme configuration.

Data Setup and Test Data Management

Reliable test execution depends on reproducible data. For settings‑page tests you often need to control the user’s account state, device configuration, and sometimes backend feature flags. Below are practical strategies for preparing and cleaning up test data.

Using Fixtures or Factory Objects

If your application exposes a test API or a local database you can manipulate, create a fixture that puts the account into a known state before each test. For example, a pseudo‑code snippet in JavaScript (using a hypothetical test harness) might look like:

// beforeEach hook
async function resetUserSettings() {
  await api.delete('/settings');          // wipe persisted settings
  await api.post('/settings/defaults');   // restore factory defaults
  await api.put('/user/profile', {
    displayName: 'TestUser',
    email: 'test@example.com',
    avatarUrl: null
  });
}

This ensures each test starts from a clean slate, eliminating cross‑test contamination.

Mocking External Services

Settings that trigger server calls (e.g., saving an API key, enabling cloud backup) should be mocked to avoid flakiness due to network latency or server downtime. Tools like MockServer, WireMock, or the built‑in networking stubs in Playwright allow you to intercept requests and return predefined responses.

// Playwright example: mock the API key endpoint
await page.route('https://api.example.com/v1/user/apikey', route => {
  route.fulfill({
    status: 200,
    contentType: 'application/json',
    body: JSON.stringify({ masked: '****abcd' })
  });
});

Handling Device‑Specific Resources

For tests that involve file uploads (avatars, custom sounds) or storage location changes, push the required files onto the device/emulator as part of the test setup. Using adb for Android:

# Push a 1.5 MB test avatar to /sdcard/Pictures/
adb push test_avatar.jpg /sdcard/Pictures/test_avatar.jpg
# Push a short audio clip for notification sound
adb push test_sound.ogg /sdcard/Notifications/test_sound.ogg

Then reference those absolute paths in your test steps. After the test, you can clean up with adb shell rm to keep the storage state consistent.

Versioning Test Data

Keep a version‑controlled directory (e.g., testdata/settings/) containing:

• CSV files for bulk user creation (username, email, preset settings).
• Binary assets (images, audio) used in upload tests.
• JSON payloads for API mock responses.

Tag each dataset with the corresponding test case IDs so that auditors can see exactly what data drove each verification.

Prioritization and Risk‑Based Testing

Not all settings carry equal risk. A mis‑configured dark‑mode toggle is annoying but rarely catastrophic; a flawed password‑change flow could lead to account takeover. Use a simple risk matrix to assign priority levels.

After scoring each test case, you can sort by priority and allocate automation effort accordingly. For example:

• P0 cases (e.g., password change, 2FA enabling, API key storage) should be automated first and run on every commit.
• P1 cases (theme persistence, language change, notification sound) merit automation but may be executed nightly.
• P2/P3 cases (edge‑case font sizes, emoji names) can be executed manually or as part of a weekly exploratory run.

Document the rationale for each priority in a spreadsheet or test‑management tool; this aids stakeholder communication and helps justify test‑suite size.

Traceability to Requirements

Traceability links each test case to a source artifact—user story, design spec, or regulatory requirement. This connection serves two purposes: it shows coverage and facilitates impact analysis when requirements change.

Creating a Traceability Matrix

A simple two‑column table works well:

If you use a tool like Jira with the Xray or Zephyr add‑ons, you can add a custom field “Test Case ID” to issues and then generate a traceability report directly.

Maintaining Traceability Over Time

When a user story is updated, locate all linked test cases and review them for relevance. If a requirement is removed, either retire the associated tests or mark them as “obsolete”. Conversely, when a new story is added, create test cases early—ideally during sprint planning—so that the test base grows in lockstep with the product.

Combining Manual Test Cases with Autonomous Exploration (SUSA)

Manual test cases give you intentional, requirement‑driven coverage. Autonomous exploration tools like SUSA add a complementary layer that discovers unexpected behavior, edge cases, and regressions that scripted tests might miss.

How SUSA Works in the Context of a Settings Page

1. Upload the APK or provide the web URL – SUSA starts with no prior knowledge of the app.
2. Persona‑driven navigation – It simulates multiple user profiles (curious, impatient, novice, accessibility‑aware, power user, adversarial, etc.). Each persona has distinct interaction patterns: a power user may rapidly toggle switches, an accessibility user may rely on screen‑reader navigation, and an adversarial user may attempt invalid inputs.
3. State‑aware exploration – SUSA remembers which screens it has visited, which actions led to crashes or ANRs, and which UI elements are dead ends. Over successive runs it builds a model of the app’s state graph and focuses on unexplored transitions.
4. Real‑flow validation – While exploring, SUSA attempts to complete common flows (login, signup, changing a setting) and marks them PASS/FAIL based on observable criteria (e.g., does a toggle persist after navigation?).
5. Regression script generation – After a run, SUSA can export the discovered sequences as Appium (Android) or Playwright (web) scripts, giving you a starting point for automated tests.

Practical Example: Using SUSA to Find a Hidden Settings Bug

Suppose your app has a “Developer Options” screen that is only revealed after tapping the build number seven times. A manual tester might forget to include this path in their test matrix. SUSA’s curious persona, which repeatedly taps visible elements, will eventually uncover the hidden toggle. During that exploration it may also try to enter an excessively long string into the newly exposed API‑key field, triggering a buffer‑overflow‑like crash that would be hard to anticipate manually.

To integrate SUSA findings into your test suite:

1. Run SUSA on a nightly basis against a staging build.
2. Export the generated Appium script for any flow that resulted in a FAIL.
3. Review the script; if the failure represents a legitimate bug, convert it into a proper test case with clear ID, preconditions, and expected result.
4. Add the test case to your regression suite and prioritize it based on the observed impact (e.g., crash → P0).

This approach ensures that your manual test cases remain the backbone of requirement validation while SUSA continuously expands coverage into the “unknown unknowns” space.

Automation Strategies

Turning the test cases from the tables above into automated scripts provides fast feedback and enables continuous integration. Below are concrete snippets for both mobile (Appium) and web (Playwright) contexts. Adjust selectors, URLs, and credentials to match your application.

Mobile Automation with Appium (Android)

// Example: SET-002 – Dark Mode persists after restart
@Test
public void testDarkModePersists() {
    // Precondition: user logged in, theme Light
    loginUser("test@example.com", "Password123");
    SettingsPage settings = new SettingsPage(driver);
    settings.openAppearance();

    // Step: enable Dark Mode
    settings.toggleDarkMode(true);
    settings.saveIfNeeded();

    // Step: restart app
    driver.resetApp(); // equivalent to close + launch
    // Re‑login if required by your app
    loginUser("test@example.com", "Password123");
    settings.openAppearance();

    // Verification
    assertTrue(settings.isDarkModeEnabled(), "Dark Mode should stay ON after restart");
    assertTrue(settings.isUiInDarkTheme(), "UI should reflect dark theme");
}

Key points:

• Use Page Object Model to encapsulate locators (By.id("toggle_dark_mode"), etc.).
• Call driver.resetApp() to simulate a full cold start; if your app maintains session via tokens, you may need to re‑login explicitly.
• Assertions should check both the UI toggle state and a visual cue (e.g., background color) to catch sync bugs.

Web Automation with Playwright (TypeScript)

// Example: SETN-001 – Display name cannot be blank
test('display name cannot be only spaces', async ({ page }) => {
  await login(page, 'test@example.com', 'Password123');
  await page.goto('/settings/profile');

  const nameInput = page.locator('input#displayName');
  await nameInput.fill('     '); // five spaces
  await page.locator('button#save').click();

  // Expect inline error message
  const error = page.locator('text=Name cannot be blank');
  await expect(error).toBeVisible();

  // Ensure the name field still contains the spaces (no change)
  await expect(nameInput).toHaveValue('     ');
});

Tips:

• Leverage Playwright’s auto‑waiting and built‑in locators for resilient selectors.
• Use test.use({ storageState: 'auth.json' }) to persist