Mandatory

• Connect Beru VPN - instruction
• Tortoise -  Download Version Control System (will be replaced with Github)
• Charles Proxy   Download

Helpful

• Clear Cache extension  Download
• Slack app
• Wrike - Project Management tool Learn the basics
• Wayback Machine - to compare previous display of pages and compare to the latest (after deployment)
• Screenshot app - i.e.  Screenpresso, Screentogif 

Repository - local setup

1. Create folders for repositories you will work on locally i.e. D:\Solutions\GoBasicV5
   NOTE It is important to create them in D drive
2. Download TortoiseHg
3. Download Charles Proxy
4. Install Clear Cache extension 
5. Login to Beru repositories (VPN disconnected)
6. Copy URL of the repo you need to clone to your local machine
7. Open Tortoise
8. Click File > Settings > TortoiseHG
9. Click Edit File button
10. In the file paste and fill credentials (twice, at the beginning and the end of the document):
    [ui]
    

     

    username =

    password =

    ignore = ~/.hgignore

    [insecurehosts]

    repos.beru.dk = 1

    [extensions]

    rebase =

    [auth]

    repos.beru.dk.prefix = repos.beru.dk

    repos.beru.dk.username =

    repos.beru.dk.password =

11. Click File > Clone Repository
    
    
    
    
12. Paste in copied URL
13. Select the destination folder
14. Click Clone
    
    
    
    
15. To pull incoming changes click the icon:
    
    
    
    
16. If you need the latest version of a specific branch, right click > Update
    
    
    

NOTE:

To make sure what repository you should work with, right click on the customer’s page, select View page source and find a path where the repository name is displayed:

Retesting - Flow

1. Connect to Beru VPN
2. Open Charles
3. Open two browser windows separately:
1. In one window open a client’s page
2. In another window open a client’s page but with {pagename}.dk/?debug=TRUE 
4. Check if the page is now displayed in Charles
5. To add the page for debugging right-click and ENABLE SSL Proxying
   
   
   
   
6. Refresh the page (if needed, clear cache again, and refresh the page) - proceed if the proper icon is displayed next to the page:
   
   
   
   
7. Find a proper CSS file that needs to be replaced for testing purpose, usually it is under Themes, in other cases developer will share the information about the path
   
   
   
   
8. Right-click the file and select Map local
9. Choose local path to the file with a fix on staging and map it 
10. Compare the page with a fix to production
11. Make sure that fix did not break other functionalities/UI

Monthly - flow

1. Turn on VPN 
2. Find Monthly deployment ticket in Wrike
3. There is a list of solutions that will be deployed - after a deploy developers mark solution in a checkbox
4. Find the domain URL 
5. Open it in a browser - the latest changes are first visible under admin: admin.{customersdomainurl}.dk
6. Use the Wayback Machine where possible to be able to compare the site before and after a release 
7. Run sanity check on web and mobile view - use Browserstack or if not possible test mobile view in a browser
8. Focus on: buttons, links, lists with a dropdown, sorting, pagination, margins, sliders, accordions, but not only, these are sensitive areas
9. If you find a regression - report immediately on Slack channel, and create a Subtask
10. If you find a bug that is not a regression, report it (????? to confirm if as a subitem too)

Web and mobile testing

Supported Browsers:

• Chrome
• Safari
• Edge
• FireFox

Mobile

Browserstack

1. Credentials in 1Password
2. To be able to test customers' pages:
   1. turn on Beru VPN locally
   2. turn on Local testing (Force Local needed in some cases) in Browserstack
      
      

Background

QualWeb is the tool used by Danish government for testing in the ministries - we also have to use it, but keep in mind that the results of these tests are often false-positive and more testing is needed.

• A + AA levels
• Errors only - NOT warnings

• 2.4.11 Focus Not Obscured (Minimum) (AA)
• 2.5.7 Dragging Movements (AA)
• 2.5.8 Target Size (Minimum) (AA)
• 3.2.6 Consistent Help (A)
• 3.3.7 Redundant Entry (A)
• 3.3.8 Accessible Authentication (Minimum) (AA)
• 2.4.12 Focus Not Obscured (Enhanced) (AAA)
• 2.4.13 Focus Appearance (AAA)
• 3.3.9 Accessible Authentication (Enhanced) (AAA)

• 4.1.1 Parsing (Obsolete and removed)

Tools

• Qual Web - testing on the external page
  
  Qual Web
• AXE - browser extension
  
  AXE
• Wave - browser extension
  
  Wave
• Contrast Checker - visit the tool page, can be used as a Bookmark too. The Contrast Checker Bookmarklet will display a miniature version of WebAIM's popular Contrast Checker in any web page. By using the eyedropper tool in the color picker tools, you can readily check the contrast of any page content by selecting the foreground and background colors.
  
  Contrast Checker
  Contrast Checker as a Boomark

Documentation

WCAG 2.1

WCAG 2.2 - 'Understanding' docs

Testing Flow

1. Verify that the issue found in QualWeb is actually an Error and not just a Warning.

2. Verify if it's not a false-positive:

a. Read the rules on https://www.w3.org/TR/WCAG21/

b. Test with AXE Chrome plugin

c. Test with WAVE Chrome plugin

d. Run manual testing 

e. Checking contrast with https://webaim.org/resources/contrastchecker/ 

3. If you can't find the error anywhere else than QualWeb, it's probably a false-positive. If in doubts, contact Ask or Beata

____________________________________________________________________________________________

Accessibility Testing Guidelines

Purpose:
Accessibility testing ensures that the application is usable by individuals with disabilities, including those using assistive technologies such as screen readers, magnifiers, or voice commands.

Key Accessibility Principles

1. Perceivable

   • Task: Ensure that all users can perceive the information presented.
   • How to Test:
     • Check if text alternatives (alt text) are available for images and non-text elements.
     • Verify if color contrast ratios between background and text meet accessibility standards.
   • Tools to Use:
     • WAVE (Web Accessibility Evaluation Tool): Highlights accessibility issues in real-time.
     • Contrast Checker: Test color contrast ratios.

2. Operable

   • Task: Ensure that all users can navigate the application, especially using a keyboard or assistive devices.
   • How to Test:
     • Navigate the entire application using only a keyboard (Tab, Enter, Spacebar).
     • Test the functionality of all interactive elements without using a mouse.
   • Tools to Use:
     • VoiceOver (macOS/iOS), NVDA (Windows): Test the app with a screen reader to ensure it's fully operable via keyboard.
       NOTE - NVDA can affect local Java files on Windows and using Charles Proxy might be immposible after these changes
     • Tab Key Navigation: Check whether users can navigate through all interactive elements using the Tab key.

3. Understandable

   • Task: Test whether users can understand and interact with the content effectively.
   • How to Test:
     • Ensure that instructions, labels, and forms are clear and descriptive.
     • Confirm that error messages are specific and help users correct their input.
   • Tools to Use:
     • Screen Reader Testing: Listen to how the app's content is read aloud and determine if it makes sense in audio-only mode.

4. Robust

   • Task: Ensure compatibility with a variety of assistive technologies and older browsers or systems.
   • How to Test:
     • Test the app on older browsers and mobile operating systems.
     • Validate that the app works well with various assistive technologies, like screen readers and voice controls.
   • Tools to Use:
     • Browser DevTools: Check for HTML validation errors.
     • Axe Accessibility Plugin: Automated tests to flag common issues.

Specific Accessibility Tests

1. Keyboard Navigation

   • Task: Check if the app is fully functional via keyboard-only input.
   • How to Test:
     • Use the Tab key to navigate and ensure focus states are visible.
     • Verify that dropdowns, modals, and interactive elements are keyboard accessible.
   • Tools to Use:
     • Keyboard Test (Manual): Perform common tasks using the keyboard only.

2. Screen Reader Compatibility

   • Task: Ensure the app works seamlessly with screen readers.
   • How to Test:
     • Use screen readers like NVDA (Windows), JAWS, or VoiceOver (macOS/iOS) to navigate and interact with the app.
     • Ensure that interactive elements, headings, and buttons have proper labels and are announced correctly.
   • Tools to Use:
     • NVDA/VoiceOver/JAWS: Test for appropriate text-to-speech output and ARIA (Accessible Rich Internet Applications) labels.

3. Color Contrast and Visual Design

   • Task: Ensure sufficient contrast between text and background for readability by users with visual impairments.
   • How to Test:
     • Use a contrast checker to verify that all text complies with the recommended contrast ratio of at least 4.5:1 for normal text.
   • Tools to Use:
     • Color Contrast Analyzer: Test the contrast of text and other elements.
     • Sim Daltonism (macOS): Simulate different types of color blindness to assess visual clarity.

4. ARIA Landmarks and Roles

   • Task: Ensure that ARIA (Accessible Rich Internet Applications) roles and landmarks are correctly used for assistive technologies.
   • How to Test:
     • Check for the correct use of ARIA attributes (e.g., aria-label, aria-hidden) in HTML elements.
   • Tools to Use:
     • WAVE Toolbar: Review ARIA usage and general accessibility attributes.

General Accessibility Testing Tools

• Axe Accessibility Plugin: Comprehensive tool for finding and fixing accessibility issues.
• NVDA/VoiceOver: Screen reader testing.
• WAVE: For evaluating accessibility directly in the browser.
• Google Lighthouse: Automated accessibility testing with scoring and reports.

General Testing Tips

• Document Every Issue: Record screenshots or videos for any UX/UI or accessibility issues you encounter, including steps to reproduce and device/browser configurations.
• Test Across Devices: Ensure thorough testing on multiple devices, operating systems, and browsers.
• Collaborate with Developers: Share feedback in a detailed and actionable format, prioritizing issues that severely impact usability and accessibility.

By following these guidelines, testers will ensure that the application is not only user-friendly but also accessible to everyone, meeting both UX/UI and accessibility standards.

This documentation is subject to updates based on evolving UX/UI trends and accessibility standards. Be sure to regularly check for new guidelines.

Bug ticket - to discuss

1. Topic
2. Description
3. STR - Steps To Reproduce
4. AC - Acceptance Criteria 
5. For QA: Attach screenshots, recordings and other data needed to investigate/ fix: environment, URL, device, OS, version, timestamp
6. For PM, PO, developers: Attach requirements, designs