BoC - Test Plan 1.2

8/3/2019 BoC - Test Plan 1.2

http://slidepdf.com/reader/full/boc-test-plan-12 1/24

Oxagile © 2010 www.oxagile.com

BOOK OF COOLSprints testing

Test PlanVersion 1.2

8/3/2019 BoC - Test Plan 1.2


Test Plan, Version 1.4

Oxagile © 2010 Page 2 of 24

REVISIONS HISTORY

Version Date Author Comments

1.0 June 7, .2011 Roman Romanchuk Test Plan Draft

1.2 June 7, .2011 Roman Romanchuk Test Scope updated

GLOSSARY

Acronyms Description

Test case Named list of steps and condition for application evaluation

Passed Test case Condition under which a tester determines if a requirement upon an

application is satisfied

Failed Test case Means that Test Case was executed and condition which is

determined in the Test Case is satisfied

Issue Mantis issue

BoC Book of Cool

8/3/2019 BoC - Test Plan 1.2




TABLE OF CONTENTS

1 INTRODUCTION.................................................................................................................................... 5

1.1 PURPOSE OF THE DOCUMENT ...................................................................................................................... 5

1.2 RELATED DOCUMENTATION.......................................................................................................................... 5

2 ENVIRONMENT AND RESOURCES.................................................................................................... 7

2.1 SOFTWARE......................................................................................................................................................... 7

2.2 QA TEAM ............................................................................................................................................................. 7

2.3 TOOLS ................................................................................................................................................................. 7

2.4 PLATFORMS....................................................................................................................................................... 8

3 ACCEPTANCE CRITERIA .................................................................................................................... 9

4 TESTING SCOPE ................................................................................................................................ 10

4.1 SPRINT 1 ........................................................................................................................................................... 10 4.1.1 FEATURES TO BE TESTED ......................................................... .............................................................. ... 10

4.1.2 FEATURES NOT TO BE TESTED ......................................................... ....................................................... 11

5 TESTING DOCUMENTATION ............................................................................................................ 12

5.1 SPRINT TESTING SCOPE BASED ON FEATURES LIST ........................................................................... 12

5.1.1 FEATUES TESTING STATUSES ........................................................... ....................................................... 12

5.2 TEST CASES..................................................................................................................................................... 12

5.2.1 TEST CASES STATUSES ............................................................. .............................................................. ... 12

5.3 MANTIS ISSUE CREATION WORKFLOW .................................................................................................... 13 5.3.1 DEFINING BUG (MANTIS ISSUE) SEVERITY ........................................................... ................................. 13

5.4 TEST RESULT REPORTS ............................................................................................................................... 14

5.4.1 DAILY TETING PROGRESS REPORT ............................................................ ............................................ 14

5.4.2 SPRINT TEST RESUTLS REPORT ....................................................... ....................................................... 14

5.4.3 RELEASE ACCEPTANCETEST RESUTLS REPORT ......................................................... ...................... 14

6 TESTING METHODOLOGY AND ACTIVITIES.................................................................................. 15

6.1 FUNCTIONAL TEST ......................................................................................................................................... 15

6.2 GUI TEST ........................................................................................................................................................... 15

6.3 REGRESSION TEST ........................................................................................................................................ 15

6.4 SECURITY TEST .............................................................................................................................................. 16

6.5 RELEASE ACCEPTANCE TEST .................................................................................................................... 17

6.6 TESTS NOT PERFORMED FOR INITIAL TESTING RELEASE .................................................................. 17

6.6.1 PERFORMANCE TESTS ............................................................... .............................................................. ... 17

6.6.2 USABILITY TESTS............................................................... ................................................................. ........... 18

6.6.3 AUTOMATED TEST............................................................. ................................................................. ........... 18

8/3/2019 BoC - Test Plan 1.2




7 TESTING SCHEDULE ......................................................................................................................... 19

7.1 SPRINT TESTING TIME LINE SCHEMA........................................................................................................ 20

8 RISKS................................................................................................................................................... 22

9 APPENDIX ........................................................................................................................................... 23

9.1 TEST CASES SAMPLE.................................................................................................................................... 23

9.2 FEATURES LIST WITH TESTING COVERAGE SAMPLE ........................................................................... 23

9.3 TEST REPORTS SAMPLES ............................................................................................................................ 24

9.3.1 DAILY TESTING PROGRESS REPORT SAMPLE............................................................... ...................... 24

9.3.2 SPRINT TEST RESUTLS REPORT (TBD, WILL BE UPDATED WHEN ACTUAL SPRINT TEST

RESULTS REPORT IS CREATED BY QA) .......................................................... ....................................................... 24

8/3/2019 BoC - Test Plan 1.2




1 INTRODUCTION

1.1 PURPOSE OF THE DOCUMENT

The purpose of the test plan is to provide appropriate testing approach for Book of Cool Project, including

processes, methodologies and strategies. The document is intended to describe required testing activities; general

scope of the project requirements intended for testing during each sprint as well as explicitly state; the acceptancecriteria, which will determine clear measurements of success of the project.

The following areas are covered by current plan:

Testing resources and environment;

Acceptance Criteria for Book of Cool Project

Testing scope;

Testing documentation;

Testing activities;

Testing schedule.

This document is intended to be read by the customer and KITD project team, including managers and quality

assurance specialists. The content of this document is expected to be reviewed and explicitly approved by the

customer or his representatives.

1.2 RELATED DOCUMENTATION

The latest version of specification will be taken from DropBox account. To access BoC documentation, contact Jeff

Macomber [[email protected]] or Robert Obidinski [[email protected]]

Mantis ticket should always reference the latest mockups. If there is a discrepancy in functionality that is not noted

in the ticket, QA should review and discuss it with the Developer or Oxagile PM.

BoC project uses agile methodology: All 5 sprints have planning phase (2 weeks before the sprint starts). During

sprint planning phase Jeff and Robert organize knowledge sharing meetings to provide updated/detailed

documentation and scope of work. QA writes test cases accordingly.

The following documentation will be used during all testing sprints:

Design Specification (BOOK OF COOL INTERACTIVE DEMO 3.0.pdf) Technical Specification (BOC Technical Spec v2.pdf; Additional Technical Specs folder)

Description and comments to Mantis ticket

8/3/2019 BoC - Test Plan 1.2




8/3/2019 BoC - Test Plan 1.2




2 ENVIRONMENT AND RESOURCES

2.1 SOFTWARE

Server and Software PlatformPHP 5 +MySQL 4 +

KickApps Platform 5.0

Browser Support

Should be compatible with modern, standards compliant browsers, including:

IE 8, 9Firefox, Safari, Chrome (latest versions)

Advertising PlatformDoubleClick

Video PlayerKickApps Video Player will be used

KickApps Content Delivery System will be used

CMS RolesEach role within the CMS will be controlled through theKickApps system.Each user within the site can be assigned to multiple roles.In addition to being assigned to a specific role, users(particularly content editors and contributors) can berestricted to a specific section or category of the site.

Social SharingDrop in of basic javascript share utility with prebuilt sharefunctionality

Users are only allowed to share public content

2.2 QA TEAM

Initial testing phase requires at least 2 QA specialists: QA Lead, Senior QA

Role Person Responsibilities

QA Lead Roman Romanchuk Testing processes set up: QA Team coordination,

requirements and testing documentation evaluation, bugs

reporting, testing reports generation, communication with

PM, DEV, customers.

Senior QA Irina Shaban Perform test preparation and test execution activities for

the project. Report bugs and problems found.

2.3 TOOLS

Description Tool Link

Bug tracking system Mantis http://projectbugs.kickdeveloper.com/

http://projectbugs.kickdeveloper.com/

http://projectbugs.kickdeveloper.com/

8/3/2019 BoC - Test Plan 1.2




Testing Docs Repository Dropbox Dropbox, folder path: ‘BookOfCoolDocs\QA\

Requirements Repository Dropbox Dropbox, folder path: ‘BookOfCoolDocs\

2.4 PLATFORMS

URL Description

Development

CMS http://boc.kickdeveloper.com/

http://boc.kickdeveloper.com/



8/3/2019 BoC - Test Plan 1.2




3 ACCEPTANCE CRITERIA

The application will be accepted for final release after Testing phase when it meets predefined acceptance criteria.

General Acceptance Criteria:

All Features approved as the scope of each testing sprint (see Testing Scope for list of features) should

be fully tested; Admin area, User area UI and functionality is implemented according to requirements, specified in Related

Documentation section

User area UI and functionality is tested on all web browsers included into the scope (see Browser

Support)

Video Player is working without errors;

Features from Testing Scope should work without errors. Proper check list of the features intended for

each testing sprint should be created before the sprint starts.

As the result of acceptance testing the application should have no open Bugs with Major or Critical

severity;

Application should have all issues assigned. It is acceptable to have Deferred issues, or issues with

Medium or Minor severity, which would be agreed by PMs on Oxagile and KITD side to be fixed in future

phases or never;













8/3/2019 BoC - Test Plan 1.2




4 TESTING SCOPE

3-d parties services are out of scope. Only integration testing with following 3-d party services will be

performed:

JanRain Engage – used for login and registration using third party sites

Kickapps – used for media, comments

E-commerce site – performs users’ purchases checkout

4.1 SPRINT 1

Sprint 1 covers following features list:

Milestone Tasks

Dev

Complete

QA

Complete QA Priority

Sprint1 27-Jun 11-Jul

Joomla Setup out of scope

Kickapps backend setup out of scopeAdmin Design out of scope

Activity Engine out of scope

Scoring/Ranking Engine out of scope

Messaging Engine out of scope

Queue Engine out of scope

Registration/Login 1

Header/Footer - Active Navigation 10

ME - Inbox 3

ME - Settings 4

ME - Edit Profile 5

Admin Login 6

Admin Header/Footer - Active Nav 7

Admin Category Management 9

Admin Global Settings 8

Future Section 2

4.1.1 FEATURES TO BE TESTED

Registration pages: Join, JOIN –

EMAIL CONFIRMATION, JOIN –

AFTER EMAIL CONFIRMATION

Login pages: HOME - NOT LOGGED-IN, HOME - LOGGED-IN, LOGIN – login details, LOGIN - forgot password

ME – Inbox sections: My feed, My messages, My ranking, Friends, Activity on me.

ME – Settings sections: Account, Connections, Notifications, Privacy, Volume 2 Pre-order

ME - Edit Profile

Future Section pages: Space travel, Points, Maps, Volume two, BOC academy, BookofCool store

Header/Footer - Active Navigation

Admin Login

8/3/2019 BoC - Test Plan 1.2




Admin Header/Footer - Active Nav

Admin Category Management

Admin Global Settings

4.1.2 FEATURES NOT TO BE TESTED

Services functional testing is out of scope. Only integration testing with following services will be performed.

Activity Engine

Scoring/Ranking Engine

Messaging Engine

Queue Engine

Joomla and backend setup is out of functional/configuration testing scope:

Joomla Setup

Kickapps backend setup

Since admin design task refers to design requirements clarification done by Jeff, it‟s out of QA scope.

8/3/2019 BoC - Test Plan 1.2




5 TESTING DOCUMENTATION

The documentation produced by QA team aims to optimize QA team work assuming that multiple cycles of testing

of same features may be needed; simplify QA and Development team cooperation as well as provide

understandable and structured reports of testing results for the management team.

The following documentation will be created.

5.1 SPRINT TESTING SCOPE BASED ON FEATURES LIST

Testing scope coverage is based on features/sub features list. QA lead creates features/sub figures list and KITD

PM approves it before each sprint starts.

Format of test cases you could see at Features list with testing coverage sample section of this Test Plan.

5.1.1 FEATUES TESTING STATUSES

The following testing statuses for features are available:

Passed – test cases for the feature have status Passed or Deferred only;

Failed – at least one Test case for the feature has status Failed and there are no test cases with status

Blocked.

Blocked – at least one Test case for the feature has status Blocked.

5.2 TEST CASES

Test Cases will be created for each feature required for the sprint testing delivery. These Test cases will be used

for functional and regression testing.The following rules must be true when working with test cases:

Test cases should be written by QA team before upcoming sprint (during sprint planning phase);

Test cases should be reviewed by QA lead and approved by KITD PM before QA team could use them;

Test cases should be kept at Dropbox repository at actual version according to the latest requirement

changes.

Format of test cases you could see at Test Cases Sample section of this Test Plan.

5.2.1 TEST CASES STATUSES

The following statuses for test cases are available:

Passed – test cases passed without any errors or bugs;

Failed – test cases failed. QA should ensure if same or similar bug exists at Mantis. If no – new bug

should be created and assigned to the Oxagile PM;

Blocked – test cases couldn‟t be tested in case of some internal/external fault;

Deferred – test cases shouldn‟t be checked in this test iteration.

8/3/2019 BoC - Test Plan 1.2




5.3 MANTIS ISSUES (BUGS) WORKFLOW

All issues found, reopened, etc. should be logged by QA via Mantis. Mantis will serve as the main tasks pool (all

Project tasks will be stored under it) and bug tracking system for the QA team (all bug processing should be done

via Issues in the Mantis).

QA team should create new Mantis issue when a bug is found. Issue should be assigned to corresponding

developer in Mantis (status Assigned-Open). The issue description should contain structured Issue description,steps for reproduce, actual results and expected results, attached screenshots

QA team should work (check and verify) issues that have status Resolved-Fixed and re-assigned to QA.

The up-to-date requirements source is Mantis issue. When verifying Resolved-Fixed issues, QA should check all

comments in Mantis and update test cases accordingly.

QA team should close issues with status Resolved-Fixed only when it is completely fixed (done) and no similar

problems occur. Issue should be set to status Closed-Fixed.

QA team should re-open issue with if bug still exists, similar problem still occurs , QA doesn‟t agree that bug was

fixed correctly, etc. Issue status should be set Resolved-Reopened and assigned to the appropriate developer.

Appropriate reason for reopen should be specified.

If Mantis issue is not reproducible developer should set status Resolved-Unable to reproduce and re-assign to

QA. If Mantis issue is a duplicate, developer should set status Resolved-Duplicate. If Mantis issue is not an

issue/bug developer should set status Resolved-Won’t fix, add corresponding comment and re-assign issue to

QA. If developer wants to defer issue/bug fixing, status Resolved-Suspended should be set. If issue can‟t be fixed

(is a feature), developer should set status Resolved-Not fixable and re-assign issue to QA.

If QA agrees with developer, issue status is set to Closed, resolution becomes the same.

If a feature/bug verifying is blocked by another bug or feature implementation, than these features/bugs should be

linked using Mantis „Relationships‟ section

5.3.1 DEFINING BUG (MANTIS ISSUE) SEVERITY

The following severity statuses (currently available in Mantis) should be used to determine the severity of bug

(Mantis issue) and the sequence of bug fixing:

Block - Used for fatal errors that mean that testing cannot continue without fix, and/or the business isunable to use the application or IT is unable to operate the service. Must be fixed ASAP.

Crash - Used when there is a problem that means that testing can continue on the scenario using difficult

workarounds, and/or significantly impacts the business' ability to use the application or it's ability to

operate the service. Must be fixed before go-live.

Major - Used when there is a problem that means that testing can continue with relatively straightforward

workarounds, and/or has a minor impact on the business‟ ability to use the application or it's ability to

operate the service. Business and IT jointly determine if must be fixed before go-live.

8/3/2019 BoC - Test Plan 1.2




Minor - Used to highlight minor defects that do not impact the businesses ability to use the application or

it's ability to operate the service, (e.g., UI, cosmetic).

Bugs with severity Block/Crash can be fixed during sprint implementation phase (PM defines list of such issues).

Bugs with lower severity can be fixed at the end of sprint, during code stabilization phase.

5.4 TEST RESULT REPORTS

The reports on the test results should be regularly provided by QA Lead to management team. There are 3 main

test reports described below.

5.4.1 DAILY TETING PROGRESS REPORT

Daily testing progress reports are sent on daily basis at the end of the day. This applies for the 1-st Sprint only.

For the 2nd

-5th

sprints daily reports are sent 2 times per week. In case of any urgent/blocking issues reports are

send at the end of the day (on daily basis).Daily report template you could see at Daily testing progress report sample section of this Test Plan.

5.4.2 SPRINT TEST RESUTLS REPORT

Sprint test results reports are sent by email after sprint acceptance testing is performed. Acceptance testing is

performed at the end of each sprint (1 week before QA Complete Date), for details see Testing schedule section.

Sprint test results report template you could see at Sprint test results report section of this Test Plan.

5.4.3 RELEASE ACCEPTANCETEST RESUTLS REPORT

Release acceptance test results report is sent by email after final application acceptance testing is performed.

Release acceptance testing is planned during sprint 5, for details see Testing schedule section.

Release acceptance test report is similar to sprint test results report, except:

Release acceptance test report covers all sprints features testing

Release acceptance test report has final conclusion about application quality and decision whether

application can go live.

8/3/2019 BoC - Test Plan 1.2




6 TESTING METHODOLOGY AND ACTIVITIES

All testing activities should use test cases and as a result of testing QA team should create test cases results

report and set of closed/reopened/created Mantis issues.

6.1 FUNCTIONAL TEST

Functional tests should be used to check the functionality completed by development team basing on the set of

Tasks/Issues with status Resolved available in Mantis. Functional tests aim to check development tasks and bug

fixing issues completed by development team.

During functional testing QA team should create/update test cases according to Requirements changes/updates

and Mantis issues comments.

The result of Functional test – is a number of closed/reopened/created Mantis issues and executed test cases with

corresponding statuses.

Functional tests have higher priority than Regression tests.

During functional testing QA team could propose some improvements or tuning of the application. They should be

delivered to QA lead and PM and then put in Mantis to be considered for current or further sprints/phases.

6.2 GUI TEST

This test verifies that the application‟s UI corresponds to customer‟s expectations. UI test will be performed in the

set of browsers listed under Resources and Environment. Software. GUI test will be performed according to UIs

described in Art folder with path: „Dropbox\BookOfCoolDocs\Art\ ‟

6.3 REGRESSION TEST

This test ensures that the main functional ity didn‟t get broken after other issues were fixed. Regression tests

should check not only specific issue that developer reported as Fixed but also cover immediate area of

functionality that may be impacted by this fix.

Regression test should be performed according to set of test cases chosen by QA lead.

As the result of Regression test - QA team should set corresponding statuses for regression test cases list and

create tickets for found issues.

Regression test should be performed when full scope of specific feature(s) can be tested.

6.4 NON FUNTCIONAL TEST

6.4.1 SEO

All links should use SEO friendly structure – in this case that just means no references to index.php outside of ajax

calls

6.4.2 PERFORMANCE

All pages must have response time of the first byte less than 2 seconds

There should be no significant delay (less than 5 seconds) in form submit (e.g. join, login/logout) and content

submit, in the case of large files such as video and photo there should a “working” animation that is shown to the

user.

8/3/2019 BoC - Test Plan 1.2




6.5 SECURITY TEST

Security tests determine how secure the new system is. This test verifies that access to confidential data is

protected from unauthorized usage. Security test should ensure that no harm for user/application data could be

done.

The following security breach areas should be covered by security testing: URL injection, direct links check, XSS

User Roles and authorization access:

User Roles – admin – access to full site including complete admin

User Roles – boc staff – access to full public site, access to partial admin (media, recommendations, and

moderation only)

User role – regular user – no access to admin, logged in can access ME

User role – guest (not logged in) – no access to admin, no access to “ME” (should just send them to login), can

not perform actions such as commenting, rating, join academy, join research team, recommend item, upload

media

CMS Roles DetailBook of CoolBOC Site Technical Specifications V1.1Administrator RoleThis is a root level role within the system that can controlanything and everything in the CMS. A role best suited fora technical person within the BOC.BOC Staff RoleEmployees of BOC or designated content contributors

should have this role. Users within this role may also berestricted to certain content areas of the site.Users in the staff role should only be able to add and editarticles, not CMS content blocks such as the footer orother blocks.BOC Master RoleEmployees of BOC or designated content contributors willdesignate certain users as Masters. These users areconsidered to be experts in one or more disciplines, andcreate and star in content that is both educational andinformative.Individual Members can purchase content packages orindividual content items from a Master.

BOC Individual Member RoleThis is a site member who has created an account.Members in the BOC Individual Member Role can edit theirown record and personal information, upload video andimage content, follow other members, send and receivemessages to other members, rate content, comment oncontent and purchase content packages.Anonymous Visitor RoleThis role represents any visitor to the site who is not alogged in user. Any content assigned to this role will alsobe visible to search engines.Anonymous visitors may browse some content, but arenot allowed to rank content, send messages, add

8/3/2019 BoC - Test Plan 1.2




comments or upload new content.

Member statusesVarious membership statuses exist and will be utilized todrive internal promotions and advertisements. Themembership statuses follow below.1. Non Member2. Member who has not purchased any products from BOC3. Member who has bought a Full Master Pass but not a

physical copy of BOC.4. Member who has bought a physical copy but not a fullmaster pass.5. Member who has bought both a Full master Pass and aphysical copy.

CMS Content Editing

Individual Members and Masters can upload, edit or deletetheir own video and image content. They can alsocomment, tag, flag, share and rate other members‟ content or profiles.Administrators and Staff Members can manage contentcategories, moderate content and comments, manage

promotional items, manage slideshow content, and sendmessages to other users.No approval workflow is required for posting content,comments, or editing categorization on the site.Approval workflow is required for user-submitted futureitems (trips, gear, films) to be included in the future coolthings area. BOC Staff must approve user-submitted itemsand categorize appropriately.

6.6 RELEASE ACCEPTANCE TEST

Release acceptance testing is always performed prior to delivery to ensure the whole application is workingwithout issues.

Release acceptance testing requires full code freeze and no development updates to be due. During Release

acceptance testing QA team should run all existing test cases (created before) to ensure that application is ready.

If any application features are not covered by Test Cases – they should be tested too, basing on Specification/UI

requirements.

As result of Release acceptance testing - QA team should create Release acceptance testing results check list.

According to it QA lead and PM decide about final quality of the application.

6.7 TESTS NOT PERFORMED FOR INITIAL TESTING RELEASE

6.7.1 PERFORMANCE TESTS

This test verifies that application‟s response times meets user‟s expectations and does not exceed specified

performance criteria.

Load tests

In case application should be used by great amount of users QA team should ensure that user has no

performance problem like page response, page loading time, video response, video loading time etc.

Volume tests

8/3/2019 BoC - Test Plan 1.2




This test verifies that the application still behaves in accordance with performance requirements having the

requested maximum quantity of data in key tables.

Stress tests

This test verifies that the application satisfies performance requirements under maximum load during a short

period of time.

6.7.2 USABILITY TESTS

Test for 'user-friendliness'. Usability of application will be checked and possible recommendation may be

proposed. The question of usability is subjective and will depend on the targeted end-user or customer.

6.7.3 AUTOMATED TEST

In case of great amount of similar project it would be useful to implement it in later phases for better and faster

application testing of identical functionalities delivered from project to project.

8/3/2019 BoC - Test Plan 1.2




7 TESTING SCHEDULE

This chapter describes project schedule, according to which all development and testing activities will be

performed. Project is divided into following 5 sprints:

Milestone Tasks Dev Complete QA Complete

Ramp-upIntial meetings with internal Dev,

Design, QA resources 1-Jun

With review of mockups, documents,

etc

Sprint1 27-Jun 11-Jul

Joomla Setup

Kickapps backend setup

Admin Design

Activity Engine

Scoring/Ranking Engine

Messaging Engine

Queue Engine

Registration/Login

Header/Footer - Active Navigation

ME - Inbox

ME - Settings

ME - Edit Profile

Admin Login

Admin Header/Footer - Active Nav

Admin Category Management

Admin Global Settings

Future Section

Sprint2 25-Jul 8-Aug

Upload/Embed Page

ME - My Stuff

ME - Queue

Video Play Page

Image Play Page

Admin User Management

Admin Media Management

Recommendation Section

Admin Recommendations

Admin User Management

Sprint3 22-Aug 5-Sep

Explore

People

Admin Moderation

8/3/2019 BoC - Test Plan 1.2




Admin Slide Player

Slide Player Frontend

Sprint4 19-Sep 3-Oct

Style Ecommerce

Get Masterpasses functionality

Following

Homepage modules

Right rail modules outstanding (top 5

discipline, etc)

Search Engine

Search Page

Sprint5 10-Oct 17-Oct

Analytics implementation

Advertising implementationClean-up any remaining opens from

QA

Address client feedback from

previous phases

Go Live 18-Oct

7.1 SPRINT TESTING TIME LINE SCHEMA

Each sprint has following testing and development time line schema:

Development timeline

Testing activity

Requirements

clarification

Code Stabilization,

Bug Fixing

Sprint

Start

Code Freeze

Test Planning

(1-1.5 weeks)

Active Testing

(1-1.5 weeks) Acceptance

Testing

(1 week)

Sprint

Finish

Active

Development

8/3/2019 BoC - Test Plan 1.2




Timeline:

Test Planning phase = 1-1.5 weeks

Active testing phase = 1-1.5 weeks

Acceptance phase = 1 week

Release phase = during 5-th sprint

The following activities should be done during the Initial testing Phase:

o Sprint test planning – QA team familiarizes with project requirements and writes test cases,

updates test plan with features list and testing scope for upcoming sprint etc.

o Documentation review/testing – QA team should review specifications, requirements and other related

docs available on the project.

o Updating test plan – QA team should update test plan, section Testing Scope and upload it at Dropbox

path: „Dropbox\BookOfCoolDocs\QA\Test Planing\ ‟.

o Test cases creation – QA team should create test cases according to Testing Scope, project

requirements and upload it at Dropbox path: „Dropbox\BookOfCoolDocs\QA\Test Planing\ ‟.

Active testing – stabilization of application is in progress. QA team passes/updates test cases and

submits/verifies bugs (Mantis issues).

o Test cases updating – QA team should update test cases according to changes in documentation /

implementation. Notification to DEV and QA should be sent by KITD PM about all documentation

changes during active testing phase.

o Functional testing – QA team should verify Mantis issues that have „Resolved‟ status.

o GUI testing – QA team should perform GUI testing,

o Security testing – QA team should perform Security tests.

o Test Cases Execution – QA team should pass test cases, update test cases status and upload test cases

at Dropbox path: „Dropbox\BookOfCoolDocs\QA\Test Results\ ‟.

o Test Reports preparation: Test Team should generate regular e-mail reports showing if the testing is

started successfully or not and current sprint test results. All reports should be sent via email to the

predefined recipient list.

Acceptance testing – current sprint functionality has code freeze (no active development is on),

functionality is being prepared for internal delivery. QA team performs sprint acceptance testing.

o Acceptance tests – QA team should perform sprint acceptance testing.

o Sprint test results report - QA team should pass all test cases covering sprint testing scope, generate test

results report and upload it at Dropbox path: „Dropbox\BookOfCoolDocs\QA\Test Results\ ‟.

Release phase (during sprint 5) – application code freeze (no active development is on).

Application is being prepared for delivery. QA team performs release acceptance testing activities.

o Acceptance tests – QA team should perform release acceptance testing.

o Final Test Results Report - QA team should pass all test cases, covering all release scope, generate final

test results report and upload it at Dropbox path: „Dropbox\BookOfCoolDocs\QA\Test Results\ ‟.

o Integration tests – QA team should perform integration tests to check that different modules of application

work smoothly together.

8/3/2019 BoC - Test Plan 1.2




8 RISKS

RISK TABLE

Impact Likelihood Mitigation

Final requirements are not ready

for some features in upcoming

sprint

High Re-plan testing schedule for corresponding features; postpone test case creation and

testing for features with not complete/final requirements or write draft test cases with

comment to update them.

Changes in requirements High QA\DEVS should be notified about all requirement changes, especially during active sprint

development\testing phase. By default the latest requirements are stored in Dropbox.

Update test cases to new requirements as soon as possible.

There is no test environment

prepared for the project in time.

Environment is down

High Make sure the test environment is defined and dedicated for this project prior to the start of

the project test activities.

No code updates should be published during the testing cycle.

Testing cycle can be postponed till the environment is up and running again.

3-d party services (e.g. ranking

engine, video player) are not

integrated and available for End

to End testing

Medium Inform PM about 3-d party services unavailability.

Postpone testing of related features till 3-d party services will be integrated and available for

testing.

Emulate 3-d party services; where possible perform preliminary 3-d party services testing.

Project sign-off deadline is

October 18, 2011. Lack of QA

recourses.

Low Attempt to find external or internal QA resources to accomplish testing in time. Arrange

soonest knowledge transfer and new resource involvement to the project.

If no other resources are available from other projects – then testing priorities and coverage

should be discussed.

8/3/2019 BoC - Test Plan 1.2




9 APPENDIX

9.1 TEST CASES SAMPLE

BoC: User Area: Test casesTC ID SPEC ID SUMMARY STEPS EXPECTED RESULTS STATUS COMMENT/ISSUE ID

1. Registration/Login

1.1 Not run

1.2 Not run

9.2 FEATURES LIST WITH TESTING COVERAGE SAMPLE

Milestone Tasks Responsible

QA

Priority

Spec.

Ready

Spec. QA

Review

Test Cases

Writing

Testing

Status

Ramp-up

Intial meetings

with internal Dev,

Design, QA

resources

With review of

mockups,

documents, etc

Sprint1

Joomla Setup ox

out of

scope

N/A N/A N/A

Kickapps backend

setup kitd

out of

scope

N/A N/A N/A

Admin Design kitd

out of

scope

N/A N/A N/A

Activity Engine kitd out of scope

N/A N/A N/A

Scoring/Ranking

Engine kitd

out of

scope

N/A N/A N/A

Messaging Engine kitd

out of

scope

N/A N/A N/A

Queue Engine kitd

out of

scope

N/A N/A N/A

Registration/Login ox 1In progress Done Done Not run

Header/Footer -

Active Navigation ox 10

In progress Not started Not started Not run

8/3/2019 BoC - Test Plan 1.2



ME - Inbox ox 3In progress In progress In progress Not run

ME - Settings ox 4In progress Not started Not started Not run

ME - Edit Profile ox 5In progress In progress In progress Not run

Admin Login ox 6In progress Not started Not started Not run

Admin

Header/Footer -Active Nav ox 7


Admin Category

Management ox 9


Admin Global

Settings ox 8


Future Section ox 2In progress Done Done Not run

9.3 TEST REPORTS SAMPLES

9.3.1 DAILY TESTING PROGRESS REPORT SAMPLE

Daily testing reports should be sent by email to all stakeholders (Robert O´Bidinski, Jeff Macomber,

Alexander Makarov, and Muzaffer Habib) with following sections (that can be optional):

Summary – brief description of daily testing activities

Testing progress and results – testing activities detailed description, including: statistics

on test cases creating/updating/execution; test cases execution results, submitted bugs by

priorities; analyzed requirements etc.

Issues, blockers, questions – list of issues blocking application testing; list of questions

related to requirements, test ENV etc.

Test Plans – further testing plans and estimations

9.3.2 SPRINT TEST RESUTLS REPORT (TBD, WILL BE UPDATED WHEN ACTUALSPRINT TEST RESULTS REPORT IS CREATED BY QA)

Date post:	07-Apr-2018
Category:	Documents
Upload:	raman-ramanchuk
View:	217 times
Download:	0 times

BoC - Test Plan 1.2

Documents