Skip to main content

Cypress UI Automation - part 2

 

Accessibility Testing 

Accessibility Testing Jira Ticket




The above ticket covers the need for the product team to implement Accessibility on the product. It shows the WCAG 2 level (A, AA, AAA) and the government requirements of AA and Accessibility. I understood that the accessibility level on the e-commerce products needed to be in level with the government’s target of AA accessibility level. I was expected to check that our level of Accessibility was in line with the government’s target level of AA on E-commerce products.  As part of the Automation test Strategy document, testers were required to implement Accessibility testing on their product, and part of the instruction was to create a ticket for each requirement. On this ticket, I have added some details of the test approach. I wanted to learn more about the accessibility tools and test results so the approach here was to start with the WAVE and axe tools of the Developers tools on the chrome browsers. I then developed it further by creating automation code with the cypress migration project. The soft skills here is my willingness to learn, and eagerness to exploring new ideas.




Here, I have added details of how to execute the tests using the accessibility Tools.





The comments I have added on the ticket showcase how vital it is in software testing to communicate well with the team. It updates them on the progress of the tests and how they can carry out their tests should they need to. Here, I am showing appreciation for the rest of the team to make sure my job is fulfilled well. It also promotes teamwork, as I am communicating with the team effectively.

Accessibility Test Condition

We need to verify our website pages compile with the UK government’s AA accessibility level requirement. I used the wave and accessibility testing tools to conduct manual accessibility testing. The whole idea here was to learn about the errors, then I automated the test again using the cypress-axe tool (automation test tool). Each element on the website should comply with the Accessibility level of AA.

 

Conditions

Type of Error

WCAG 2 Level / User impact

Expected Results

1.    Form Labels must have the corresponding label

Error

AA

Pass

2.    Linked Images should have alternative text / Links must have discernible text

 

Error/Violations

A

Pass

3.    Form Labels /

Form elements must have labels

 

Error/Violations

AA

Pass

4.    Headings should not be empty

 

Error

AA

Pass

5.    The element must have sufficient colour contrast

Violations

AA

Pass

6.    Frames must have a title attribute

Violations

Serious

Pass

I executed further Test with cypress-axe automation tool (besides the manual Accessibility Tool) so that continuous test execution results can be presented to the stakeholders in the future.

Firstly, I installed cypress-axe with the following command as instructed by the website:

npm install --save @types/cypress-axe

Then I entered the following details in the support/index.js file

import 'cypress-axe';

Then I entered the following details in the plugins/index.js file, for making sure we collect failure test results in the command line:

 

 

module.exports = (onconfig=> {

  on('task', {

    log(message) {

      console.log(message)

      return null

    },

    table(message) {

      console.table(message)

      return null

    }

  })

}

 

 

Then I executed the test with the same command as I would execute any spec file:

npm run stg

The test is being executed against the stg(UAT) environment.


 








The above table shows the result of the table statement specified in the plugins/index.js file - details above. The above table will make the test result presentable to the stakeholders.





Test Results are as follows:

15 accessibility violations were detected

Test Name/ID

Impact on Users

Description

Expected Results

Actual Results

aria-allowed-role

minor

Ensures role attribute has an appropriate value for the element

Pass

Failed

colour-contrast

serious

'Ensures the contrast between foreground and background colours meets WCAG 2 AA contrast ratio thresholds

Pass

Failed

empty-heading

minor

Ensures headings have discernible text

Pass

Failed

frame-title

serious

'Ensures <iframe> and <frame> elements contain a non-empty title attribute

Pass

Failed

heading-order

moderate

Ensures the order of headings is semantically correct

Pass

Failed

label-title-only

serious

Ensures that every form element is not solely labelled using the title or aria-described by attributes

Pass

Failed

label

critical

Ensures every form element has a label

Pass

Failed

landmark-banner-is-top-level

moderate

Ensures the banner landmark is at the top level

Pass

Failed

landmark-no-duplicate-banner

moderate

Ensures the document has at most one banner landmark

Pass

Failed

landmark-one-main

moderate

Ensures the document has only one main landmark and each iframe in the page has at most one main landmark

Pass

Failed

landmark-unique

moderate

Landmarks must have a unique role or role/label/title (i.e. accessible name) combination

Pass

Failed

link-name

serious

Ensures links have discernible text

Pass

Failed

page-has-heading-one

moderate

Ensure that the page or at least one of its frames contains a level-one heading

Pass

Failed

region

moderate

Ensures all page content is contained by landmarks

Pass

Failed

tab index

serious

Ensures tab

index attribute values are not greater than 0

Pass

Failed

 

Causes of failure

According to the wave and axe accessibility test tools, the cause of failure was that the elements do not meet the WCAG 2 level of AA, failing.

Root Cause of Failures

Developers are not applying the Accessibility rule during development maybe because they do not know or need to learn about WCAG2 standards so they can apply their knowledge during development.

I also added these details to the README.md file so the team can regenerate the report in the future.




Defect Report for Accessibility






You can see on the defect/bug report, I have assigned it to the Lead Developer and tagged the relevant stakeholders.

I was planning for ways to generate the Accessibility Report for all the pages in the shop. I researched and came across an article for making sure the Accessibility test is applied to all the pages using the sitemap. To complete this I needed a sitemap.xml file containing details of all the pages of the website. I reported this the Lead Developer but in order to address the issue and needed to rest of the team to be aware of the request. I presented the work I did on Accessibility testing to the team and requested the sitemap.xml file. They were very pleased with my work so it did not take long before the sitemap.xml file was generated as requested.


View part 3 here.


Thank you for visiting my website.











 



Comments

Popular posts from this blog

Working with Dropdownbox elements in Selenium WebDriver

How to select element from a Dropbox We are going to use Selenium webDriver and chrome driver to test this. In addition, this test was created on Mac.  I assume you have installed and setup java in your system path.  Also, install Eclipse for jee. 1. First let's take a look at a quick test case: Test case: TC_1. Register on http://automationpractice.com/index.php TC_1.1: Launch hope page -http://automationpractice.com/index.php TC_1.2 : Click on link ‘Sign in’ TC_1.3 : Under “Create Account” subheading, enter Email address in ‘Email address’ textfield TC_1.4 : Click on ‘Create an account’ button. —————————————————————————————— Test data: Email address: gorgeous12@hotmail.com http://automationpractice.com/index.php ---------------------------------------------------------------- Expected : http://automationpractice.com/index.php?controller=my-account ———————————------------ 2. Next, create a maven project in Eclipse 3....

Cypress UI Automation - part 1

Java to Cypress-JavaScript Automation Migration Introduction: Across Cancer Research UK engineering department, we currently use a Java automation framework for our User interface and API testing. The framework has evolved in the last 3 to 4 years and currently, we have 19 products/project, (running approximately 1350 test scenarios) using the framework to run the respective sanity/regression packs. The project/products extend across different technology stacks such as Drupal, Symphony, React JS, .Net, OBI and Siebel CRM.   The Quality Assurance (QA) test team are currently under the process to be transformed into a fully-fledged Quality Assurance function.   As part of this transformation, we would like to have a comprehensive, automated test suite that can be maintained by developers and testers. Furthermore, our front-end web development is moving into JavaScript, now is the right time to migrate our automation framework also from java into JavaScript. The introduction ...

Performance Testing

  Performance Testing As part of the Quality Assurance Test Approach, each tester has to implement performance testing within its product team. In this section of the project, I will be using Apache JMeter as the testing tool for the test approach. Apache JMeter is an open-source performance testing tool for load, stress and many more testing. Screenshot from: https://www.youtube.com/watch?v=817zU_bXh9Y&list=PLUDwpEzHYYLs33uFHeIJo-6eU92IoiMZ7 JMeter works by creating a request to a target server(website), the server then responds, saves responses, collects, calculate statistics, return results to request and then generate reports.