...
| View file | ||
|---|---|---|
|
Terms, Abbreviations and Definitions
Term | Description |
UI | User Interface |
UAT | User Acceptance Testing |
BUAT | Business User Acceptance Testing |
CI/CD | Continuous Integration/Continuous Delivery |
Objectives
The current document describes the testing methodologies and testing flow which will be applied during all stages of Design system implementation.
...
This document is the live one and should be adjusted promptly to conform to the current state of the application requirements.
Testing Scope
Features to be tested
Container
Grid
Section
Typography
Image
Icon
Heading Block
Link
Button
CTA Block
Accordion Item
Accordion List
Page Header
Text box
Navigation Link
Navigation
Logo
Basic Header (i.e. excl. Site Search)
Subtle Button variant
Footer
iFrame
Carousel
Product Header
Overview
Product Card
Product Lists
Picto Card
Picto List (aka Ingredients/Benefits section)
Image + Text
Article Header
Article Decoration (e.g. Pull Quotes, etc) (Image Carousel only in Figma)
Embedded Video
Page Card
Page List
Teaser
Sitemap
Product How To + Safety Block (How To block, reference below, seems a bit complicated for markets to use it)
Promo Strip
Testing types in scope
Code review - peer review and acceptance of developed code by the RB side
Unit testing (automated) - developers team responsibility with coverage of at least 80 %
UI compatibility and cross-browser testing in a manual way;
Smoke testing on a preview build of each new version that is deployed;
Accessibility testing (automated and manual)
Visual Regression testing in a semi-auto way[Probably will be changed]
Functional testing
Testing types out of scope
Performance testing
Loading testing of server-side is out of scope
Testing of content - The DA Team will copy and port content provided by the customer/brand team. So the correctness of the provided content is on the customer/brand team
Testing of the functionality of third parties, only the testing of integration is in our scope
Test Approach
Testing flow
All test activities will be divided into four phases:
...
*This flow will be implemented for every component
Analysis & Planning Phase
The purpose of this phase is to cover requirements provided by the customer with test documentation such as checklists, which will be used in the test phase and during the Stabilization testing phase.
...
Requirements clarification for and checklists creation;
Consideration of requirements testability and request for development support if needed;
Test documentation creation / change / support functional and non-functional checklist's
Test Phase
The purpose of this phase is to validate features against requirements using the test documentation created in the elaboration phase.
...
Unit testing (automated) - developers team responsibility;
UI compatibility and cross-browser testing in a manual way
Accessibility testing;
Bugs verification
Reporting
Test documentation support
Stabilization Phase
The purpose of the phase is to ensure that all set of components works together as expected according to requirements, any change doesn’t impact existing functionality. This phase includes regression testing and the final smoke testing (before delivering the application to the customer for acceptance).
It is supposed that regression mostly will be done with developed manual UI tests.
UAT + Go-live phase
Test activities will be done during the phase:
...
This sign-off should be tracked in JIRA in the specific story for each component.
Test Types and Levels
Unit testing
The tests will be developed by the DataArt dev team. These tests will be included in CI/CD pipeline and will be executed as a part of the build process. Failed unit tests will prevent the creation of build artifacts (application build).
...
Tools to be used:
Jest Testing Library
Cross-browser and compatibility testing
The purpose of the testing is to ensure that all components look in accordance with the approved design in all agreed browsers. Such as the application is to be developed in a mobile-first approach, it is highly important to verify the application on different mobile devices that are agreed with the customer.
...
Browser DevTools
Percy/Chromatic
*Tools must be approved
Accessibility testing
The purpose of the accessibility testing is to make sure that components conform to WCAG 2.0 standards. The accessibility testing is to be started in the design review step - all colors from the approved design will be checked on conformance with color contrast ratio by WCAG 2.0 standards. This testing type will be performed manually and using accessibility automation tools.
Tools to be used:
StoryBook
AxeCore
UI testing and Visual Regression testing
The purpose of UI testing is to check that created UI Library matches the design
Percy/Chromatic
Smoke testing
The goal of the smoke testing is to execute a limited suite of the checks which verify main functionalities and UI to make sure that a deployed build is not broken at all. This testing will be performed manually.
Functional testing
The purpose of functional testing is to make sure that all modules work correctly according to requirements. Functional testing will be performed manually.
...
Storybook development env
Reporting
This section enlists the reports to be created during the testing activities.
UI checklist
The report is provided by the test team for the sprint. UI checklist is expected to contain the following data:
...
The report is planned to be delivered as a document added to the Confluence. The recipients are the Customer’s side, PM, and management personnel.
Accessibility checklist
The report is provided by the test team for the sprint. The accessibility checklist is expected to contain the following data:
...
The report is planned to be delivered as a document added to the Confluence. The recipients are the Customer’s side, PM, and management personnel.
Visual Regression report
The report is provided by the test team for the sprint. It’s planned to include the following information in the report:
...
The report is planned to be created in the Visual regression tool.
Functionality checklist
The report is provided by the test team for the sprint. The functionality checklist is expected to contain the following data:
...
The report is planned to be delivered as a document added to the Confluence. The recipients are the Customer’s side, PM, and management personnel.
Issue and test documentation management
Issues management
It is planned to store and track all issues(Epics, Stories, Bugs, Tasks) in Jira.
...
Priority | Definition | Maximum Allowable |
Urgent | This is a failure that prevents either large or core areas of the Product from functioning. This defect needs to be fixed and deployed as soon as possible.
| 0 |
Highest | This is a failure that prevents either large or core areas of the Product from functioning. A workaround may exist as a short-term satisfactory solution. Some of these defects should be fixed before going live.
| 0 |
High | This is a serious failure that must be fixed before going live. High defects badly affect core areas, causing important or highly visible areas to fail. It is not normally possible to work around High defects. High defects should be fixed before going live. | 10% |
Medium | A failure that is causing an error in the application functionality. It is of lower impact or in a less visible area than a High failure. Medium defects normally have a workaround. They usually impact only a few test cases and will not stop QA testing, and staying on schedule | 10% |
Low | Defects have a low impact in less visible areas of the site, only affect the fringes of a business process, or only happen in unlikely circumstances. Low defects usually only affect a single test case and will not stop QA testing, and staying on schedule. | 10% |
Lowest | Defects have a low impact in less visible areas of the site, only affect the fringes of a business process, or only happen in unlikely circumstances. Low defects usually only affect a single test case and will not stop QA testing, and staying on schedule. | 10% |
Checklist management
For the checklist creating Confluence will be used.
Accessibility checkpoints management
The accessibility checklist will contain only checkpoints that have to be executed manually. These checks will be stored in Jira as Test case issue type and marked with the ‘Accessibility’ label
Suspension and Resumption Criteria
Testing of Test Items will be suspended if:
...
All duties of the DataArt team are done
Test Deliverables
The following test artifacts are planned to be created within the project:
...
Reports showing d differences or similarities between modules and their original design. The report should be automatically generated after every commit
Risks
№ | Description | Mitigation strategy | Impact | Probability |
1 | Requirements inconsistency | To gather requirements properly, update in constantly after each review, and use only reviewed requirements | High | Medium |
2 | Changing requirements | To create adaptive documentation to prevent time losing | High | Medium |
3 | Changing design | Low | Medium | |
4 | Non-working environment | High | Low |
Approvals
The following people are required to approve the Test Strategy:
...