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.

Testing Types

Functional Tests

Unit Testing

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 Testing

Integration tests will ensure that the component under test is performing as expected as a whole.

Tool ⇒ Jest, SuperTest, Docker and Kubernetes

End to End Testing

E2E tests are designed to consider the whole application, which consists of multiple components.

Tool ⇒ Cypress, Jest, Docker and Kubernetes

Snapshot Testing

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

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

Non-Functional Tests

API Performance Testing

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

UI Performance Testing

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



Quality Engineers

Test Tools Documentation

Bug Resolution

Bugs Priority:

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.

Bug Template

Link to the Bug Template

Important Links

Supported Browsers

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.