Test Strategy

1. Document Revision History 

Date

Version No.

Author

Description

23.08.2022

1.1

 Viktoriia Malysh

Created the documentation

12.09.2022

1.2

 Viktoriia Malysh

Restructured the test strategy, added some styling

2. Approvals 

The Test Strategy is approved by the following stakeholders: 

Stakeholder

Full Name

Status

Date of Sign Off

Client Representative

 

 

 

Project Manager

 Ruslan Bokach

 

 

DEV Lead

 

 

 

FE Lead

 

 

 

3. Purpose

The purpose of the test strategy is to define the testing approach, the types of tests, test environments, tools to be used for testing, and the high-level details of how the test strategy will be aligned with other processes. The test strategy document is intended to be a living document and will be updated when we get more clarity on Requirements, Test environment and Build management approach, etc.

4. Project Overview

The main purpose of the  Bournemouth7s 2023 project is to create and style the site based on the requirements. The Bournemouth7s 2023 is the World’s Largest Sport & Music Festival and on the site, people can buy tickets for this festival. The client`s CRM (Easol Sandbox) is used for managing the site.

5. Tools for QA planning and testing purposes

Confluence will be used for storing all project-related information.

JIRA will be used as a bug tracking system, as well as for planning, tracking, and analyzing project activities and tasks.

Browserstack will be used for cross-browser/device testing.

6. Requirements references for Bournemouth7s 2023 project

Type

Link

Comment

Active Sprint

 https://cheitgroup.atlassian.net/jira/software/c/projects/EB7/boards/117?selectedIssue=EB7-15

 

Backlog

 https://cheitgroup.atlassian.net/jira/software/c/projects/EB7/boards/117/backlog?view=detail&issueLimit=100

 

Requirements

 Bournemouth7s – Project Passport

The site deployed to live before the site were done, because the timer was shown on the mane page (two days before users can start buying tickets to the festival). The development and testing workcontinued while the timer was shown on the main page

Design

 Desktop: https://app.zeplin.io/project/62fcefeaff6f5129542c6be1

 During the site crean and testing some pages were added ro the design.

7. Testing Types

The following testing types will be executed during the “Bournemouth7s 2023” project:

7.1. Functional testing

The functional testing will be executed to evaluate the compliance of a system or component or third party with specified functional requirements and corresponding predicted results. Functional testing is performed for each planned feature and is guided by approved client requirements.

7.2. Regression testing

The regression testing will be performed to ensure that any bugs have been fixed and that no other previously working functions have failed as a result of the reparations and that newly added features have not caused any problems to previous versions of the software.

7.3. Design (Responsive) testing

The design testing will be performed for all testing levels to assure that it meets the design-related specifications.

Responsive testing on mobile devices (tablets don`t need to be tested on this project) is focused on the business logic for the project in the scope of features.

Design testing will be based on the approved scope of the UI designs – https://app.zeplin.io/project/62fcefeaff6f5129542c6be1

(синяя звезда) Design testing will be NOT based on the pixel-to-pixel verification.

7.4. Cross-browser compatibility testing

The cross-browser compatibility testing will be performed (Chrome, Safari, Firefox) to check the ability of the solution to interact with the agreed list of browsers.

Cross-browser testing will be covered manually on Test Environment only on browsers defined for cross-browser testing.

8. Planned testing types on the test environments (browsers, devices)

Devices:

Windows

MacOS

iOS:

Google Chrome (latest)):

Monterey (Safari – latest):

  • iPhone 13 Pro Max

  • 1440 x 1028

  • 1920×1080

  • 2560 x 1080

  • 1028 x 768

  • 1440 x 1028

  • 1920×1080

  • 2560 x 1080

  • 1028 x 768

  • Phone 6

Android:

Firefox (latest):

  • Samsung Galaxy S22 Ultra

  • 1440 x 1028

  • 1920×1080

  • 2560 x 1080

  • 1028 x 768

  • Samsung Galaxy S8

9. Approach for Process Flow

9.1. Work with Tasks

  1. Tasks will be split into BE and FE.

  2. All Tasks that have the status “Ready for QA” should be assigned to QA.

  3. All found issues that relate to the Task should be linked to it.

9.2. Work with Bugs

Bug creation tips:

  • The bugs should be created according to the task titles – for example “Bugs – Homepage” (“Bugs – page name – block name”). If there is more than one bug that relies on one task ticket, the bugs are written in one ticket. If the QA Engineer found the new bugs after the written ticket were fixed, the QA Engineer needs to write the new bug ticket and assign it to the Developer.

  • In case the found bug is related to a certain task – it should be linked to the task.

  • In case QA found Blocker/Critical bug during the testing ticket which is not related to the task – it should be added to the Active sprint.

  • In case QA found a Major/Minor/Trivial bug during the testing ticket which is not related to the task – it should be reported as the separated bug ticket.

Bug verification tips:

  • In case the ticket is passed – QA should add a detailed comment with a screenshot (video if needed) and move it to the “Approved”/”Done” status.

  • In case the ticket is failed – QA should add a detailed comment with a screenshot (video if needed) and the ticket should have the “Reopened“ status.

Comments

Leave a Reply