This document is going to define types of testing that will be implemented for the project, the tools that will be used in the technical stack and any processes to ensure that the definition of done is being followed.
Unit testing is designed to ensure that coding units (classes/methods/functions and logic etc) are satisfying requirements and not producing any issues that could degrade the product.
Tool ⇒ Jest
Integration tests will ensure that the component under test is performing as expected as a whole.
Tool ⇒ Jest, SuperTest, Docker and Kubernetes
E2E tests are designed to consider the whole application, which consists of multiple components.
Tool ⇒ Cypress, Jest, Docker and Kubernetes
Layout Tests to compare snapshots between previous and current versions of the product. If something is not matching with the previous baseline layout then it will throw a failure.
Tool ⇒ Galen, Docker and Kubernetes
Exploratory testing will be manually done as part of sign-off and acceptance of an item of work, along with required regression tests to ensure application health. It will only cover new and current tickets/features.
Tool ⇒ Manual
When required, performance testing will ensure that the experience offered by the application while under load has not degraded as a result of changes.
Tool ⇒ Locust, Docker and Kubernetes
We might need to implement some UI Performance Tests for the product in the future. For now we can execute some manual tests with a plugin called Lighthouse, but there is nothing confirmed yet. This is going to be decided in the second semester and the ticket is in the backlog: JIRA-1334 UI Performance Tests [SPIKE]
Tool ⇒ Lighthouse
High: There is no workaround and user can’t complete AC basic function
Medium: There is a workaround, but it is not easy/simple to identity
Low: Cosmetic issue
Bugs have 2 end states:
Resolved is when you have reproduced the issue, identified the problem and have fixed it to all defined standards. As with any other type of ticket - any related Pull Requests will need to be deployed and tested to ensure that there is no regression. Once the issue resolution has been signed off then it can be set to resolved.
Accepted is when you have determined that an issue falls outside of the need of an immediate fix (determined by the Definition of Done) and the product owner also accepts this as an issue in production and also a risk that’s worth having for the time being.
Link to the Bug Template
Chrome - Latest version
Firefox - Latest Version
We will cover all of the supported browsers only for the E2E tests, and Snapshot Tests, for the Exploratory Tests we will only cover Chrome and Latest Version.