How to Write Test Cases for Keyboard Navigation (With Examples)

How to Write Test Cases for Keyboard Navigation (With Examples) is a critical skill for QA engineers, especially in today's web and mobile applications where accessibility and user experience are para

How to Write Test Cases for Keyboard Navigation (With Examples)

How to Write Test Cases for Keyboard Navigation (With Examples) is a critical skill for QA engineers, especially in today's web and mobile applications where accessibility and user experience are paramount. Keyboard navigation is essential for users who cannot or prefer not to use a mouse, and ensuring that your application is fully navigable via the keyboard is a must. This guide will walk you through the process of writing high-signal test cases for keyboard navigation, covering everything from test case anatomy to real-world examples and edge cases.

Understanding Test Case Anatomy

Before diving into the specifics of writing test cases for keyboard navigation, it's essential to understand the basic structure of a test case. A well-structured test case typically includes the following components:

Test Case ID

• Purpose: A unique identifier for the test case.
• Example: TC001

Test Case Title

• Purpose: A brief, descriptive title that summarizes the test case.
• Example: Verify Tab Order in Login Form

Preconditions

• Purpose: Steps or conditions that must be met before the test case can be executed.
• Example: User is on the login page.

Test Steps

• Purpose: Detailed, step-by-step instructions to execute the test case.
• Example:

1. Click on the login page.
2. Press the Tab key to navigate to the username field.
3. Press the Tab key again to navigate to the password field.
4. Press the Tab key again to navigate to the login button.

Expected Result

• Purpose: The expected outcome of the test case.
• Example: The focus should move sequentially from the username field to the password field, and finally to the login button.

Actual Result

• Purpose: The actual outcome of the test case, recorded during execution.
• Example: The focus moves as expected.

Status

• Purpose: The current status of the test case (e.g., Pass, Fail, In Progress).
• Example: Pass

Positive Test Cases for Keyboard Navigation

Positive test cases are designed to verify that the application behaves as expected under normal conditions. Here are some examples of positive test cases for keyboard navigation:

Verify Tab Order in Login Form

• Test Case ID: TC001
• Preconditions: User is on the login page.
• Test Steps:

1. Click on the login page.
2. Press the Tab key to navigate to the username field.
3. Press the Tab key again to navigate to the password field.
4. Press the Tab key again to navigate to the login button.

• Expected Result: The focus should move sequentially from the username field to the password field, and finally to the login button.

Verify Navigation in Dropdown Menu

• Test Case ID: TC002
• Preconditions: User is on the homepage with a dropdown menu.
• Test Steps:

1. Click on the homepage.
2. Press the Tab key to navigate to the dropdown menu.
3. Press the Enter key to open the dropdown.
4. Use the Arrow keys to navigate through the dropdown items.
5. Press the Enter key to select an item.

• Expected Result: The dropdown menu should open, and the user should be able to navigate through the items and select one using the keyboard.

Verify Focus on Modal Dialog

• Test Case ID: TC003
• Preconditions: User is on a page that triggers a modal dialog.
• Test Steps:

1. Click on the button to open the modal dialog.
2. Press the Tab key to navigate through the elements in the modal.

• Expected Result: The focus should be trapped within the modal dialog, and the user should be able to navigate through all elements using the Tab key.

Negative Test Cases for Keyboard Navigation

Negative test cases are designed to verify that the application behaves correctly under abnormal or unexpected conditions. Here are some examples of negative test cases for keyboard navigation:

Verify Focus Trapping in Modal Dialog

• Test Case ID: TC004
• Preconditions: User is on a page that triggers a modal dialog.
• Test Steps:

1. Click on the button to open the modal dialog.
2. Press the Tab key to navigate through the elements in the modal.
3. Press the Shift + Tab key to navigate backward.
4. Press the Esc key to close the modal.

• Expected Result: The focus should not leave the modal dialog while it is open, and pressing the Esc key should close the modal and return focus to the element that triggered it.

Verify Focus Loss on Page Reload

• Test Case ID: TC005
• Preconditions: User is on a page with a form.
• Test Steps:

1. Click on the form.
2. Press the Tab key to navigate to a specific input field.
3. Refresh the page.

• Expected Result: After the page reloads, the focus should return to the first focusable element on the page.

Verify Focus on Disabled Elements

• Test Case ID: TC006
• Preconditions: User is on a page with disabled form elements.
• Test Steps:

1. Click on the form.
2. Press the Tab key to navigate through the form elements.

• Expected Result: The focus should skip over disabled elements and move to the next focusable element.

Edge and Boundary Test Cases for Keyboard Navigation

Edge and boundary test cases are designed to verify that the application behaves correctly under extreme conditions. These test cases often uncover issues that are not apparent during normal usage. Here are some examples of edge and boundary test cases for keyboard navigation:

Verify Focus on Large Forms

• Test Case ID: TC007
• Preconditions: User is on a page with a large form containing over 20 input fields.
• Test Steps:

1. Click on the form.
2. Press the Tab key to navigate through all input fields.

• Expected Result: The focus should move sequentially through all input fields without skipping any.

Verify Focus on Nested Elements

• Test Case ID: TC008
• Preconditions: User is on a page with nested focusable elements (e.g., a button inside a div).
• Test Steps:

1. Click on the page.
2. Press the Tab key to navigate to the nested button.

• Expected Result: The focus should move to the nested button, and the user should be able to interact with it.

Verify Focus on Dynamic Content

• Test Case ID: TC009
• Preconditions: User is on a page that dynamically loads new content.
• Test Steps:

1. Click on the page.
2. Trigger the dynamic content load.
3. Press the Tab key to navigate to the newly loaded content.

• Expected Result: The focus should move to the newly loaded content, and the user should be able to interact with it.

Test Matrix for Keyboard Navigation

To ensure comprehensive coverage, it's useful to organize your test cases into a test matrix. This matrix can help you track the status of each test case and identify any gaps in your testing. Here is a sample test matrix for keyboard navigation:

Data Setup for Keyboard Navigation Testing

Data setup is crucial for ensuring that your test cases are executed under the right conditions. Here are some considerations for setting up data for keyboard navigation testing:

Test Environments

• Local Development Environment: Set up a local development environment to test the application's keyboard navigation features.
• Staging Environment: Use a staging environment that closely mimics the production environment to test keyboard navigation in a more realistic setting.

Test Data

• Sample User Data: Create sample user data for testing login forms and other user-specific features.
• Dynamic Content: Set up test data that triggers dynamic content loading to test focus behavior.

Browser and Device Configurations

• Multiple Browsers: Test keyboard navigation in different browsers (e.g., Chrome, Firefox, Safari) to ensure cross-browser compatibility.
• Multiple Devices: Test keyboard navigation on different devices (e.g., desktop, laptop, tablet) to ensure cross-device compatibility.

Prioritization and Traceability of Test Cases

Prioritizing and tracing your test cases is essential for effective testing. Here are some strategies for prioritizing and tracing test cases for keyboard navigation:

Prioritization

• High-Priority Test Cases: Focus on test cases that cover critical features and user flows, such as login forms and navigation menus.
• Medium-Priority Test Cases: Test cases that cover less critical but still important features, such as modal dialogs and dynamic content.
• Low-Priority Test Cases: Test cases that cover edge and boundary conditions, which are important for comprehensive testing but may not be as critical.

Traceability

• Traceability Matrix: Create a traceability matrix to map test cases to specific requirements and user stories.
• Issue Tracking: Use a bug tracking tool (e.g., Jira, Bugzilla) to track the status of test cases and any issues discovered during testing.

Manual and Automated Approaches to Keyboard Navigation Testing

Both manual and automated testing have their place in ensuring the quality of keyboard navigation. Here are some considerations for each approach:

Manual Testing

• Advantages:
• Flexibility: Manual testing allows testers to explore different scenarios and edge cases.
• Human Insight: Testers can use their intuition to identify issues that automated tests might miss.
• Disadvantages:
• Time-Consuming: Manual testing can be time-consuming, especially for large applications.
• Inconsistent: Results can vary between different testers and test runs.

Automated Testing

• Advantages:
• Efficiency: Automated tests can be executed quickly and repeatedly.
• Consistency: Automated tests provide consistent results across multiple test runs.
• Disadvantages:
• Initial Setup: Setting up automated tests can be time-consuming and requires technical expertise.
• Maintenance: Automated tests need to be maintained and updated as the application changes.

Tools for Automated Testing

• Selenium: A popular tool for automating web applications. It supports multiple programming languages and can be used to simulate keyboard navigation.
• Cypress: A modern end-to-end testing framework that provides a powerful API for writing automated tests.
• Playwright: A Node.js library for automating web browsers. It supports Chromium, Firefox, and WebKit and can be used to simulate keyboard navigation.

Example: Automating Keyboard Navigation with Selenium

Here is an example of how to automate keyboard navigation using Selenium in Python:

from selenium import webdriver
from selenium.webdriver.common.keys import Keys

# Initialize the WebDriver
driver = webdriver.Chrome()

# Navigate to the login page
driver.get("https://example.com/login")

# Locate the username and password fields
username_field = driver.find_element_by_name("username")
password_field = driver.find_element_by_name("password")
login_button = driver.find_element_by_id("login-button")

# Simulate tab navigation
username_field.send_keys(Keys.TAB)
password_field.send_keys(Keys.TAB)
login_button.send_keys(Keys.TAB)

# Verify the focus is on the login button
assert login_button == driver.switch_to.active_element

# Close the browser
driver.quit()

Real-World Examples of Edge Cases in Keyboard Navigation

Real-world applications often encounter edge cases that are not apparent during initial testing. Here are some examples of edge cases that can arise in production environments:

Focus Loss on Dynamic Elements

• Scenario: A user navigates through a form using the Tab key, and a dynamic element (e.g., a tooltip) appears, causing the focus to jump to an unexpected element.
• Solution: Ensure that dynamic elements are properly managed and do not disrupt the focus order.

Inconsistent Focus Behavior on Different Browsers

• Scenario: A user reports that the focus behaves differently on different browsers, causing confusion and frustration.
• Solution: Test the application on multiple browsers and ensure consistent focus behavior across all supported browsers.

Focus Trapping in Complex Modal Dialogs

• Scenario: A user encounters a modal dialog with multiple nested elements, and the focus gets trapped in an unexpected way.
• Solution: Use ARIA roles and attributes to ensure that the focus is properly managed within complex modal dialogs.

Checklist for Keyboard Navigation Testing

To ensure that you cover all aspects of keyboard navigation testing, use this checklist:

• Test Tab Order: Verify that the tab order is logical and consistent.
• Test Focus Trapping: Ensure that focus is trapped within modal dialogs and other confined areas.
• Test Focus Loss: Verify that the focus does not get lost during page reloads or dynamic content loading.
• Test Disabled Elements: Ensure that disabled elements are skipped during tab navigation.
• Test Nested Elements: Verify that the focus can navigate to nested elements.
• Test Dynamic Content: Ensure that the focus can move to dynamically loaded content.
• Test Multiple Browsers and Devices: Test the application on different browsers and devices to ensure cross-compatibility.
• Test Edge and Boundary Conditions: Identify and test edge and boundary conditions to uncover hidden issues.

Combining Designed Test Cases with Autonomous Exploration

While designed test cases are essential for ensuring that specific requirements are met, they may not cover all possible scenarios and edge cases. Autonomous exploration tools like SUSA can help fill these gaps by exploring the application in a more comprehensive and dynamic way.

How SUSA Can Help

SUSA is an autonomous QA platform that can explore your application and identify issues related to keyboard navigation. By uploading an APK or pointing it at a web URL, SUSA can:

• Explore the App: Tap, scroll, type, handle dialogs, and complete real flows.
• User Personas: Test with a range of user personas (curious, impatient, novice, adversarial, elderly, accessibility, power user, security tester, and others).
• Identify Issues: Find crashes, ANRs, dead buttons, accessibility (WCAG) violations, security issues, and UX friction.
• Track Flows: Track critical flows (login, signup, checkout) with PASS/FAIL verdicts.
• Generate Scripts: Auto-generate regression scripts from what it discovered (Appium for Android, Playwright for Web).
• Cross-Session Learning: Remember explored screens and dead ends, making each run smarter.

Example: Using SUSA for Keyboard Navigation Testing

Here is an example of how to use SUSA for keyboard navigation testing:

1. Install SUSA:

   pip install susatest-agent

1. Run SUSA :

   susatest-agent test https://example.com

1. Review Results :

• SUSA will explore the application, identifying issues related to keyboard navigation.
• It will generate a report with detailed findings, including crashes, ANRs, and accessibility violations.
• It will also auto-generate regression scripts for Appium and Playwright, which can be used for future testing.

Conclusion and Takeaways

Writing high-signal test cases for keyboard navigation is crucial for ensuring that your application is accessible and user-friendly. By following the guidelines and examples provided in this guide, you can create comprehensive test cases that cover a wide range of scenarios, from positive and negative cases to edge and boundary conditions.

Key Takeaways

• Test Case Anatomy: Understand the structure of a test case, including ID, title, preconditions, steps, expected results, actual results, and status.
• Positive, Negative, and Edge Cases: Write test cases that cover normal, abnormal, and extreme conditions.
• Test Matrix: Organize your test cases into a matrix to track their status and identify gaps.
• Data Setup: Set up test environments, data, and configurations to ensure accurate testing.
• Prioritization and Traceability: Prioritize test cases and create a traceability matrix to map them to requirements.
• Manual and Automated Testing: Use both manual and automated approaches to ensure comprehensive coverage.
• Real-World Examples: Be aware of edge cases that can arise in production environments.
• Autonomous Exploration: Use tools like SUSA to explore your application and identify issues that might be missed in designed test cases.

By combining designed test cases with autonomous exploration, you can ensure that your application is fully navigable via the keyboard, providing a better user experience for all users.