# Test Strategy
Project: TODOMVC
Version: 1.0

|Version|Date|Author|Description of change|Approved by|
|---|---|---|---|---|
|1.0|25/07/2020|Quang Nguyen|Initiation ||

## 1. Introduction
### 1.1 Purpose
This document describes the scope, how to approach and methodologies used by deverlopment team to plan, organize the testing for the project TODOMVC. It does not describe implementation details of test cases or technical details of how the product features should work.
* Identify the functions that should be tested.
* List the recommended test requirements (high level).
* Recommend and describe the testing strategies to be employed.
* Identify Compatibility and Performance.
* List the deliverable elements of the test activities.

## 1. Scope and Overview
This section defines the scope of the testing. It identifies what items (files, etc.) and what areas of functionality (features) will be tested and what items and areas of functionality will not be tested.
### In-scope
* Ensure that TODO application is built in correct structure that is defined in requirement spectification
* Ensure that the main function of TODO application work corectly in cross devices / browser
* Ensure that performance of TODO application meets expectation that is defined by owner
* All test cases will be executed
* Critical bugs/issues are identified and fixed before release

### OUT-OF-SCOPE
* All that is not in the IN-SCOPE
* Security testing

## 2. Test Approach
To get a high quality product with the least effort. We should be careful in all steps in software development life cycle. Especially, Implementing process in deverlopment team (Dev and QC).
Whole team / QC should apply early testing technique _(static testing)_. Team should analyze carefully, make questions to clarify requirements before starting implementation. This step extreamly necessary. We can avoid futher mistake such as misunderstand, rework or fix side effect bugs.
Besides, QC and Dev must work closely to make sure that dev can aware the test cases that will be tested by QC after dev implements done. This step help dev chosing the best solution before coding.

graph LR
Start --> A[PO - Requirement specification]

--> B[Team - review and think solutions] --> F
A --> C[Team - analyze side effects or impact] --> F
A --> D[Team - Make question to clarify requirements] --> F[Dev team]

F --> G[QC write Test Case]
F --> H[Dev prepares to implement]
G--> L
H --> L[QC discuss to Dev about all cases]
L --> N[Devs implement and do sefttest]
N --> K[QC test and report bug]
K --> N
K --> Done

- Test Level
- Test Type
- Roles and responsibilities
- Environment requirements

### 2.1 Test Level
1. Unit Testing
2. Integration Testing
3. System Testing
4. User Acceptance Testing

### 2.2 Test Type
#### 2.2.1 Static Testing
This testing technique focus on reviewing requirement specification, analyze impact of changes or side effects.
Ask / make questions to clarify requirements early. Avoid misunderstand and rework after implementing.

|#|Description|
|---|---|
| Test Objective | Team will predict and prevent issue early, Deverlopment team can avoid rework or fix bug after impelemting|
|Technique| Whole team will analyze requirement specification carefully, analyze side effects and make the questions early before starting implementation |

#### 2.2.2 Functional Testing
This type of testing will focus on main functions of TODO app based on requirements. This test type verifies that the system works as required and validates that the correct functionality has been delivered.
|#|Description|
|---|---|
| Test Objective | Test the application with defined test cases to ensure that the main function works as expected |
|Technique| Design test cases to cover main functions of TODO app. Applying suitable technique of Black-box testing. It will cover the expected results occur when valid data is used. |

#### 2.2.3 Ad-hoc Testing
This type of test will focus on the behavior of the system. The tests carried out without planning, software and documentation.
|# |Description |
| --- | --- |
|Test Objective|Test the application without following any rules or test cases using the QC experience and common sense.|
|Technique|Tester uses his/her domain knowledge, experience with similar programs to perform the test. There is no test case.|
|Completion Criteria|The test will be done when needed for a specific purpose from Tester team|
|Special Considerations|During testing, any unexpected behavior in the system will be added to the bug report. If it is not in the scope of the user stories client will consider implementing/fixing it or not|

#### 2.2.4 Performance Testing
This type of test will focus on performance of TODO app when thousands of user uses this application in the same time.
|# |Description |
| --- | --- |
|Test Objective|Focus performance when loading app and response time|
|Technique|Using Performance Testing tool such as JMeter, K6|
|Completion Criteria|The speed loading is less than 3s. 10.000 uses can use in the same time without any timeout request|
|Special Considerations|During testing, any unexpected behaviour in the system will be added to the bug report.|

### 2.3 Roles and responsibilities
|Role|Responsibilities|
|---|----|
|Project Owner|Define requirement specification clearly before starting a new sprint|
|Programer|Implement features base on requirement specification|
|QC|Test new features or changes to ensure product quanlity |

### 2.4 Environment requirements
These applications, version and devices which are listed below are in this testing scope. The bugs are reported and fixed in these applications and devices. Other are seem known issue that may be fixed after considering.

|**Machine**||
| --- | --- |
|PC|Windows 10, 64 bits|
|Macbook| macOS 10.x|
|**Application**||
|Chrome| Latest version|
|Safari| Latest version|
|Firefox| Latest version|
|IE| version 10 or later|
|Microsoft Edge| Latest version |

## 3. Testing Tools
|# |Description |
| --- | --- |
|Requirement Specification| 1. Jira confluence at http://yourdomain.com/todo|
|Test Result management|Zephyr|
|Bug Tracking| Jira tool|
|Discussion|Hangouts, Email, Directly|

## 4. Testing acceptance criteria
- Testing plan is approved by Test Manager and Dev Manager: **100%**
- Main functions covered by TCs: **100%**
- All TCs executed: **100%**
- Blocker/Critical/High Issues: **0%**
- Main functions without test cases: **0%**

## 5. Approvals
Prepared by: Quang Nguyen - QC engineer
Approved by: ---------------
Date: /----/----/ 2020