test plan template - devcom.com file · Web viewtest plan template - devcom.com

Test Plan

PID: COMPANY Reporter: -

Project

Test Plan

REVISION HISTORY

Ver. Description of Change Author Date

Approved

Name Effective Date

1.0 Project

Related Artifacts

Ref. Name

Abbreviations and Acronyms

SM Scrum Master

PO Product Owner

BA Business Analyst

QA QA Engineer

OS Operating system

GUI Graphical User Interface

UI User Interface

Test Plan


Contents1. INTRODUCTION 3

1.1. OBJECTIVES 3

1.2. AUDIENCE 3

1.3. BENEFITS 3

2. SCOPE OF WORK 4

2.1. COMPONENTS AND FUNCTIONS TO BE TESTED 4

2.2. COMPONENTS AND FUNCTIONS NOT TO BE TESTED 4

3. QUALITY AND ACCEPTANCE CRITERIA 13

4. CRITICAL SUCCESS FACTORS 14

5. RESOURCES 14

5.1. KEY PROJECT RESOURCES 14

5.2. TEST TEAM 15

5.3. TEST ENVIRONMENT 17

5.4. TEST TOOLS 17

5.5. TEST SCHEDULE 17

5.6. RISKS 18

6. TEST DOCUMENTATION AND DELIVERABLES 19

7. TEST STRATEGY 19

7.1. ENTRY CRITERIA 20

7.2. TEST METHODS 20

7.3. TEST TYPES 20

7.4. TEST LEVELS 20

7.4.1. Smoke Test 20

7.4.2. Critical Path Test 20

7.4.3. Extended Test 20

7.5. BUG AND DOCUMENTATION TRACKING 21

IT Lab 2016 Page: 2/22

Test Plan


7.5.1. Bug Severity Definitions 21


Test Plan


1. IntroductionThis document describes the approach and methodologies used by the testing team to plan, organize and perform the testing applications of the Project.

PROJECT will allow different role of users to get operational online information about trainees of the IT practice lab, their admission to the protection project by calculating the mean rating of trainees and left feedback from each team members of the project, and the mentor from specific direction (the role of the project) and report on the progress of the trainee on the project.

Project description situated at the confluence – drafting by BA of project.

1.1. OBJECTIVESThe key objectives of the test plan are as follows:

• Determine the significance or critical nature of the application system to the business

• Determine the levels and approach to testing

• Determine the need for a systems integration test by identifying key system interfaces

• Identify product risks

1.2. AUDIENCEThis Test Plan is intended for the following audience:

• Product/Project management

• Development Team

• Test Team

1.3. BENEFITSThe Test Plan can provide the following benefits:

• Faster development of testing requirements by directly using key project deliverables

• Earlier identification of testing requirements

• Independence of testing from development tasks and resources

• Well-defined tests

• Progressive and additive test tasks


Test Plan


2. Scope of Work

3. Components and Functions to be TestedAccording to the development methodology the scope of functions that will be tested during release will be planned and accepted by Customer, Dev team and Testing team.

In the chosen scope will be included the following testing methods:

- acceptance testing

- functional testing

- GUI testing

- regression testing

- integration testing

4. Components and Functions Not to be TestedThe following testing methods won’t be performed:

- performance testing

- testing of the back-end

Table 1. Pages and components to be tested in the R12 release.

Components and functions to be tested# Application/ component name Function name Comment

E1 - Home page

1. US 1.2.718 - Main page

Trainee’s block

Project's block

Number of projects

Number of trainees

Courses block

Login button


Test Plan



Test Plan



Test Plan



Test Plan



Test Plan


Add trainee button

IT Lab 2016 Page: 10/22

Test Plan


IT Lab 2016 Page: 11/22

Test Plan


IT Lab 2016 Page: 12/22

Test Plan


IT Lab 2016 Page: 13/22

Test Plan


IT Lab 2016 Page: 14/22

Test Plan


5. Quality and Acceptance Criteria

The main objective is to ensure Customer satisfaction by delivering good quality work of all project team members within the scope of the Product. This should be reached through ensuring that:

● Project team members have suitable skills and present their competency well;

● Project team members follow the Customer’s policies, processes, standards and guidelines;

● Project team members report their activities as necessary.

Appropriate metrics for the process assessment should be calculated at the stage when the product is released for production and should satisfy the following:

● Percentage of declined bugs among total amount of all bugs should not exceed 15%;

● Percentage of verified bugs among the difference of total amount and amount of declined bugs should not be less than 85%;

● Percentage of fixed bugs among the difference of total amount and amount of declined bugs should not exceed 1%.

Note: these metrics are organizational standard that should be observed in any case. Although, they can be strengthened depending on any existing PO standards.

Development team works in collaboration with QA team, designers and product owners to ensure requirements meet business criteria. During testing phase of each iteration QA team write and executes test cases based on these requirements. Acceptance criteria can be defined as:

● The product should work according to the requirements and acceptance criteria provided by BA and PO, and QA team;

● All QA tasks (or tasks provided in QA) for writing and executing test cases are closed;

● Design and code review are done;

● The implementation of product was approved by PO;

IT Lab 2016 Page: 15/22

Test Plan


● Regression testing should pass with no Blocker and Critical bugs.

● The product should not have bugs with severity Blocker and Critical to be released for production.

Note: If the build does not meet the Acceptance Criteria, it, however, can be delivered to Production Project Manager or Product Owner approves that.

6. Critical Success Factors

● Meet schedule and complete development and testing of all functionality in term;

● Functional requirements do not have last minute changes;

Note: Build may have last minute changes if Product Owner approves that.

● Application shouldn’t have known bugs with severity Blocker, Critical and Major (under the agreement with customer) at the time of Final Release;

● There are no problems with environment, connection to environment (network issues);

● No delays from development in deliverables of builds for testing.

In addition to the overall critical success factors, the following critical success factors are specific to the Testing process:

● Testing must be fully integrated into the project processes according to Agile (Scrum) principles;

● Functional Testing must be objective and must be performed by an independent test team (other than the programmers responsible for the application software);

● The defect management process must be functional as soon as testing begins, and must ensure that only valid and non-duplicated defects are processed;

● Features should be categorized by their relative importance to the business for defect prioritization.

IT Lab 2016 Page: 16/22

Test Plan


7. Resources

8. Key Project Resources

# Project Role Name, e-mail

1 Product Owner

2 QA mentor

3 Scrum master

4 Business analyst

5 QA Engineer

6 QA Engineer

7 UI Designer

8 BE Developer

9 BE Developer

10 BE Developer

11 FE Developer

12 FE Developer

9. Test Team

# Project Role Name Location Responsibilities

1 QA Mentor Coordinating of work QA teamCreating sub-tasks for QAChecking QA work

2 QA Engineer Test plan creationTest progress/result reportingTest cases creationTesting executionQA control of acceptance criteriaExecution sub-tasksBug reportingBug verification

IT Lab 2016 Page: 17/22

Test Plan


3 QA Engineer Test plan creationTest progress/result reportingTest cases creationTesting executionQA control of acceptance criteriaExecution sub-tasksBug reportingBug verification

10. Test Environment

# Browser Hardware configuration Software configuration1 Google chrome

55.0.2883.87 m15.6 Intel(R) Core(TM) i3-4010U CPU@ 1.70GHz 4,00GB

Windows 10 x64

2 Firefox 50.1.0 15.6 Intel(R) Core(TM) i3-4010U CPU@ 1.70GHz 4,00GB

Windows 10 x64

3 IE 11 15.6 Intel(R) Core(TM) i3-4010U CPU@ 1.70GHz 4,00GB

Windows 10 x64

11. Test Tools

# Tool Comment1 Jira Bug tracking, tasks and sub-tasks system

Confuence Requirements and documentation management

2 MS Excel For Test Cases

3 MS Word For Test Plan and Test Progress/Result Report Documentation

Jink Screenshots creation

12. Test Schedule

# Activity Begin Date End Date Assignment Location Work content1 Test plan

creation16/09/2016 Update

according new

8h-16h (depending on the amount of information to be

IT Lab 2016 Page: 18/22

Test Plan


applications adding or changing in project processes.

updated)

2Test cases creation

At the beginning of development

No later than 1st build deploy

4h-10h (depending on US complexity)

3Build installation

Weekly, on Friday

No later than 13:00

Up to 1h (depending on dev team)

4 Smoke Test execution

According to QA schedule


1h-2h (for new build deployed)

5Critical path Test execution



4h-12h (depending on US complexity)

6Test results report

Started with testing

By the end of Sprint

2h-3h (depending on testing volume)

13. Risks

# Risk Probability Impact Mitigation plan

1 ResourcesSome team members could temporary drop out from work process due illness or personal reasons.

high medium We can perform work of temporary drop out team members by overtime work of operable team members.

IT Lab 2016 Page: 19/22

Test Plan


2 Departure of employeesSome team members could left the project during the release.

low high We can ask to help us team members from other projects.

3 DefectsBig amount of bugs can reduce the performance of project team. Developers will be spend a lot of time to fix these bugs instead to develop planned user stories.

medium high We should estimate user stories well and planning bug fixing process to prevent this situations.

14. Test Documentation and Deliverables

# Title Responsible person(s)

Frequency (delivery time) Method of delivery

1 Profile Test Plan

Once before the testing start and updates during testing

2 Profile Test Cases

Before the testing start and updates during testing

3 Bug reports Upon finding a bug

4 Test Result Reports

In the end of two-week sprints

15. Test StrategyThe PROJECT application will be tested using a “black box” approach, which is based on the requirements (acceptance criteria in confluence/jira and functional requirements without knowledge of the internal structure or program source code.

IT Lab 2016 Page: 20/22

Test Plan


Once the build is provided for testing – smoke test will be executed. If build passes the smoke test other tests can be performed.

For every user story a specific set of tests will be created and performed. Different testing types will be used in order to cover functionality from a certain user story. Regression testing will be performed as will be done the development of new functional area affecting to already tested objects.

16. Entry CriteriaThe Testing Team may suspend partial or full-testing activities on a given build if any of the following occurs:

• Version of web application/acceptance criteria is changing through the process of testing.

• There is a fault with a feature that prevents its testing.

• Web application does not contain the specified change.

• A severe problem has occurred that does not allow testing to continue.

• A new version of the software is available to test.

17. Test MethodsTesting is the process of attempting to find discrepancies between the program and its functional specification/ requirements. The goal is to make sure that all functions of the PROJECT work correctly.

Manual functional testing – is considered as the main method of the application testing.

18. Test Types- Feature acceptance testing – testing features as they are implemented- GUI testing – testing of graphical user interface- Compatibility testing – performing tests in various browsers- Integration testing – testing application functionality in normal conditions, i.e. core functionality- Regression testing – includes all listed above tests and fixed bugs validation before release

IT Lab 2016 Page: 21/22

Test Plan


19. Test Levels

20. Smoke TestSmoke Test is performed to quickly assess the readiness of the product for further more deep and thorough testing. It includes testing PROFILE major functions on the one most often used client configuration.

If Smoke Test failed, Testing Team sends notification and suspends testing until corrected version of the product is available.

21. Critical Path TestCritical Path Test will be performed after Smoke Test is passed. The goal of the Critical Path Test is to find bugs that could affect the major functionality of the application that is most important for the product users. Critical Path Test will be performed manually according to Test Cases.

22. Extended TestThe Extended Test’s goal to find bugs related to the non-typical but still possible and likely usage scenarios (e.g. entering the incorrect data into the fields, boundary testing and so on). Extended Test will be performed both according to test cases and using ad hoc testing scenarios.

● Detailed Test Results Report containing testing process description and results summary will be issued as it specified in section Test documentation and deliverables.

23. Bug and Documentation TrackingTools described in the section Test Tools will be used for bug reporting and documentation tracking. The bug metrics and statistics will be included in the test results reports.

24. Bug Severity DefinitionsBlocker - Application, component or module crash or are not accessible.

Critical – Data corruption/loss, a problem in major functionality, no workaround is known.

Major – A problem with workaround, secondary features do not work properly.

Minor – Cosmetic flaw.

Trivial - Request to improve the quality of applications.

IT Lab 2016 Page: 22/22

Documents

test plan template - devcom.com file · Web viewtest plan template - devcom.com