Test Strategy

1. Document Revision History 

2. Approvals 

The Test Strategy is approved by the following stakeholders: 

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 MBCA project is to create and style the site based on the requirements.

Issue overview:

The Midsize Bank Coalition of America (MBCA) has a longstanding public-facing website https://midsizebanks.com/, but that website lacks a member-only portal. Thus, the 1500+ senior officers of MBCA’s 101 member banks lack a secure, confidential repository of confidential documents and videos that they can access on a self-service basis.  Instead, they send hundreds of emails each week to the MBCA’s Executive Director asking questions and requesting documents or links to video recordings of MBCA meetings – these questions and requests could be more efficiently handled on a largely self-service, member-only portal.

Scope of work:

Redesign of the previously developed by us member-only portal (Initial requirements). The main point of it is to make the design more dynamic and desired for partners (not members-only)- additional functionality, which should be developed on the portal - it’s the ability to register and post content for Partners + Consultant Law firms.
In the future - make additional traffic to sell advertisements on the portal.

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, and for planning, tracking, and analyzing project activities and tasks.

Google docs will be used for creating different supporting documentation (for ex. checklist).

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

6. Requirements references for MBCA

7. Test Environment

8. Testing Types

The following testing types will be executed during the MBCA project:

8.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.

8.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.

Regression testing is usually performed when all the components are tested based on created high-priority test cases; no critical and blocking bugs are open that were found during the component testing.

The regression testing is usually done after the code freeze and is always done before the deployment to production.

8.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 tablet and mobile devices is focused on business logic for the project in the scope of features.

Design testing will be based on the approved scope of the UI designs - <link to the design>

Design testing will NOT be based on the pixel-to-pixel verification, but generally look only (elements positions, colors).

Responsive testing on other intermediate resolution values is OOS.

8.4. Cross-browser compatibility testing

The cross-browser compatibility testing will be performed 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.

9. Planned testing types on the test environments (browsers, devices, email clients)

9.1. Browsers and Devices Scope

Browsers and Devices Scope

9.2. Email Clients

10. Approach for Process Flow

10.1 Work with Bugs

Bug creation tips:

• In case the found bug is related to a certain task - it should be linked to the task and Active sprint.

• 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 and added to the Active sprint.

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 “QA Approved” 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 “To Do“ status.

10.2 Regression testing procedure

Should be performed after each new functionality implementation and after related bug fixing

11. Checklists and Test Cases creation approach

The high-level checklists and test cases (if needed) for component testing will be created in the internal checklists for component and regression testing.