## Context **Update (2025-10-17):** After technical investigation, we've identified key limitations with the E2E approach that require adjusting our strategy: * **Flakiness concerns**: E2E tests with real data produce inconsistent results * **Test coupling**: Functional test failures can prevent accessibility checks from running * **Ownership changes**: Test ownership has transferred to stage groups ## Revised Approach: Feature Tests with Mocked Data We will use **feature tests** instead of E2E tests to ensure: * Consistent results through mocked data and controlled test environments * Isolated accessibility checks that run independently of functional assertions * Separate spec folder dedicated to accessibility-only checks ## Implementation Strategy ### Phase 1: Start with Golden Journeys * Focus on ~"golden journey" test cases as first iteration * Translate critical user journeys from E2E to feature test level * Define priority order for stages based on traffic data (**Create** and **Plan** first) ### Phase 2: PoC & Automation * Compare E2E vs feature specs for same user interactions * Explore Duo-assisted translation from E2E to feature tests * Minimum viable output: RSpec setup with interaction comments for engineers to complete ### Phase 3: Stage Group Collaboration * Create delegation epic similar to https://gitlab.com/groups/gitlab-org/-/epics/19643 * Engage stage groups to contribute to accessibility test coverage * Scale coverage across remaining stages based on defined priorities ## Original E2E Context (for reference) ~~If we were to use E2E tests, instead of feature tests, we could use already specified user journeys from theses test cases: https://gitlab.com/gitlab-org/gitlab/-/quality/test_cases~~ There's **742** test cases available. Previous considerations included: * Limiting to `gitlab/qa/qa/specs/features/browser_ui` subdirectory (CE: ~277 test cases in 180 files, EE: 217 test cases in 127 files) * Prioritizing **Create** and **Plan** subdirectories based on user traffic