Functional Test Plan

154a, Borschagivska str., Kiev, Ukraine ph: +38(044)501-55-48 contact@qa-

ABC

Functional Test Plan

Customer Developer Created by (Author) Preparation date Version Status

General information ABC

(QATestLab) 23. 07.2015 0.3 For confirmation

Revision History

Version

Description

Author

Date

0.1 Creating 0.2 Updating 0.3 Updating 0.4 Updating

15.07.2015 17.07.2015 21.07.2015 23.07.2015

Link

Related Documents Document name

FUNCTIONAL SPECIFICATIONS Version 1.0

Approved by

Author

Date

Copyright 2017 ?QATestLab. All Rights Reserved.

1

154a, Borschagivska str., Kiev, Ukraine ph: +38(044)501-55-48 contact@qa-

1. INTRODUCTION

Content

1.2 Purpose of the document

1.3 Objective

2. DESCRIPTION OF THE PROJECT

3. SCOPE OF WORK

3.1. The components and functions to be tested

3.2. The components and functions not to be tested

4. QUALITY CRITERIA

5. THE DECISIVE FACTORS OF THE PROJECT SUCCESS

6. LIMITATIONS, ASSUMPTIONS AND RISKS

6.1. The risks of the project

6.2. Plan to reduce the risks

6.3. Assumptions

7. RESOURCES

7.1. The team of external testing

7.2. Tools for testing

8. Deliverables

8.1. Testing Documentation and Reports

9. Responsibilities

9.1. Handling exceptional situations

10. STRATEGY OF TESTING

10.1. Testing phases

10.2. Acceptance criteria

10.3. Testing Methods

10.4. Test Types

10.4.1. Functional testing.

10.4.2. UI testing

10.4.3. Mobile testing

10.4.4 Regression testing

10.4.5. Smoke testing

Copyright 2017 ?QATestLab. All Rights Reserved.

3 3 3 3 3 3 4 4 4 4 5 5 6 6 6 6 6 6 7 8 8 8 8 9 9 9 9 9 9 9

2

154a, Borschagivska str., Kiev, Ukraine ph: +38(044)501-55-48 contact@qa-

10.4.patibility testing

9

10.5. Defect tracking and documentation

9

10.6. The life cycle of the bug

10

10.7. Criteria of the testing is complete

11

11. Acceptance Plan

11

11.1. Criteria for beginning of acceptance testing

11

11.2. The process of acceptance testing

11

11.3. Schedule of acceptance testing

11

11.4. Troubleshooting and corrective action

11

11.5. Risks of the acceptance testing

11

11.6. Product acceptance criteria

12

11.7. The matrix of product acceptance

13

1. Introduction

2. Purpose of the document

This document describes a test strategy for the project "ABC" and approaches, which the test team will use to verify the quality of the product prior to release. The document also lists the different resources that are needed for a successful testing of the project.

3. Objective

The purpose of the test strategy is to formalize the testing process, plans and approaches to testing, interfacing process with the development team and the project team to achieve the high quality of the software product. The strategy takes into account the specifics of the functionality of the project "ABC"

4. Description of the project

"ABC" project is developing by company _ on request of company _. External testing services are provided by QATestLab company.

"ABC" is the system ....

5. Scope of work

6. The components and functions to be tested

Components/Applications name

Functions

1 Back end

Back end: Log in

Link

FUNCTIONAL SPECIFICATIONS Version 1.0

Copyright 2017 ?QATestLab. All Rights Reserved.

3

154a, Borschagivska str., Kiev, Ukraine ph: +38(044)501-55-48 contact@qa-

2

The website including the web player

Forgot password Admin: Log in Forgot password Create User account List Editor account Log Out

(including the next versions)

7. The components and functions not to be tested

Components/Applications Functions name

1 Program code

2 The 3d party system

3

Web services without web interface

Comment Unit testing- testing the source code

Testing requests to the server directly, without web interface.

8. Quality criteria

The delivered product must work in accordance with the requirements and the functional specification listed in sections "Scope of Work "and "Related documents".

The delivered product must not contain any known defects with critical and high priority in the final version, and no more than 30 bugs in all other priorities.

9. The decisive factors of the project success

Compliance with schedule for developing and approving specifications for the development of parts of the product.

Compliance with the schedule and the completion of development and testing of all functionality in time.

The application should not include known defects with critical and high priority at the time of the final version.

Functional requirements are not changed at the last moment.

10. Limitations, assumptions and risks

The late submission of information, delays in document approval by the Customer. Changes in the requirements during product development. Ambiguous requirements can increase the risk of bugs appearance in the system. The narrow time frame increases the risk of bugs appearance at the time of the transfer system in

live. If the timing of development phase is not met, it will directly affect the timing of testing.

Copyright 2017 ?QATestLab. All Rights Reserved.

4

154a, Borschagivska str., Kiev, Ukraine ph: +38(044)501-55-48 contact@qa-

11. The risks of the project

Risk Id RI.1

RI.2 RI.3 RI.4 RI.5

RI.6 RI.7

Risk description

The late submission of information, delays in document approval by the Customer.

Incorrect or incomplete stated requirements.

Probability (Hi gh / Medium /Low)

Medium

Influence (High / Average / Low)

High

High

High

Changes in the requirements during development.

Problems with the delivery of the product into production because of the unavailability of servers.

High High

High Medium

Problems of integration with Medium

High

internal systems of the

Customer due to the absence

or unavailability of appropriate

interfaces and test

environment.

Errors in the 3d party providers of Low

High

the software.

The narrow time frames. If the

Medium

High

time frame of development phase

is not met, it will directly affect the

timing of testing.

Effects on Cost / Schedule / Quality Schedule

Cost, Schedule Cost, Schedule Schedule

Cost, Schedule, Quality

Cost, Schedule Cost, Schedule, Quality

12. Plan to reduce the risks

Risk Id Actions to reduce the risk

RI.1

Compliance with the rules of planning and organizing meetings.

Timely information about the unavailability of employees (including due to vacation,

illness, etc.).

The schedule of meetings and the provision of necessary information in advance.

RI.2

Splitting development into short iterations. Frequent demonstrations of new functionality.

RI.3

Fixing the basic list of requirements in the contract.

A dedicated Product Owner from the Customer.

Frequent demonstrations of new functionality.

RI.4

Getting further details on installing the product from the Customer's IT department as

soon as possible.

Copyright 2017 ?QATestLab. All Rights Reserved.

5

 ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download