MindMap Gallery GPS Test Plan

GPS Test Plan

This is a mind map about GPS Test Plan.

Edited at 2021-01-11 08:34:05

Study Smarter

GPS Test Plan

Study Smarter

Recommended to you
Outline

GPS Test Plan

Control Procedures

Reviews

The project team will perform reviews for each Iteration. (Test Case Review and Final Test Summary Review). A meeting notice, with related documents, will be emailed to each participant

Bug Review meetings

The project team will perform reviews for each Iteration. (Test Case Review and Final Test Summary Review). A meeting notice, with related documents, will be emailed to each participant

Change Request

Once testing begins, changes to the GPS system are discouraged. If functional changes are required, these proposed changes will be discussed with the managers The managers will determine the impact of the change and if/when it should be implemented. The additional/modified fucnitonality should be documented as the Change Request document

Defect Reporting

When defects are found, the testers will complete a defect report on the JIRA defect tracking system. JIRA is accessible by testers, developers & all members of the project team. When a defect has been fixed or more information is needed, the developer will change the status of the defect to indicate the current state. Once a defect is fixed by developers the testers would re-test close the defect report if it passes. Below diagram explains the defect lifecycleD- Developers, T-Testers, PM- Project Managers

Test Schedule (Dates only for representation)

Iteration 1

09/01/2015

20/03/2015

Dhiren Shah

Robinson Batchu

Iteration 2

Iteration 3

Please refer to the below link for the latest project plan implementation schedule

Introduction

Test Plan Objectives

Define the activities required to prepare for and conduct smoke, functional, system, interface and webservices testing.

Communicate to all responsible parties about the System Test strategy

Define deliverables and responsible parties

Communicate to all responsible parties the various Dependencies and Risks

Scope

In Scope

The overall purpose of testing is to ensure the new web based system, GPS meets all of its technical, functional and business requirements. The purpose of this document is to describe the overall testplan and strategy for testing GPS. The approach described in this document provides the framework for all testing related to this application. Individual test cases will be written for each iteration based on the use cases provide by Virtusa (vendor) team. The test plan document will also be updated as required for each release if there are any improvements/ modifications along with the change request document

Out Of Scope

Load Testing

Automation Testing

Environment Requirements

Web Server

AEWEBSVCDEV4

Installation of the application

Net – 4.5IIS – 7.5OS – Win2008R2

Intel(R) Xenon, 4 GB RAM, 30 GB HDD

App Server

AEWEBAPPIDDEV

Managing application data

Net – 4.5IIS – 7.5OS – Win2008R2

Intel(R) Xenon, 4 GB RAM, 30 GB HDD

DB Server

DEVSQLCL2A\DEVINST2A

Database server to support the Content Management Tool

OS - Win2008R2MS SQL Server 2008 R2

Intel(R) Xenon, 4 GB RAM, 30 GB HDD

QA Requirements

UT1 for GPS and Other systems (PPL, Jaguar, MediaPulse and others)DB – ut1 for GPS and Other systems (PPL, Jaguar, MediaPulse and others)

Test Strategy

Entry Criteria

 Code changes made to the test site will go through a change control process

 All business requirements are documented and approved by the business users

 All design specifications like BRD, Use Cases, Wireframes have been reviewed and approved

 Unit testing has been completed by the development team

 All hardware needed for the test environment is available

 The application delivered to the test environment is of reliable quality

 Initial smoke test of the delivered functionality is approved by the testing team

 Code changes made to the test site will go through a change control process

Exit Criteria

 All test scenarios and test cases have been completed successfully

 All issues prioritized and priority 1 issues resolved

 All outstanding defects are documented in a test summary with a priority and severity status

 Go/No-go meeting is held to determine acceptability of product

Test Execution

Smoke Testing

The released code is working properly and ensures the system is basically operational.The QA environment is properly configured

Functional Testing

Functional testing focuses on the functional requirements of the software and is performed to confirm that the application operates accurately according to the documented specifications and requirements, and to ensure that interfaces to external systems are properly working

Interface Testing

This testing follows a transaction through all of the product processes that interact with it and tests the product in its entirety. Interface testing shall be performed to ensure that the product actually works in the way a typical user would interact with it. This involves the webservices testing

System Testing

Testing the fully integrated applications including external peripherals in order to check how components interact with one another and with the system as a whole. This is also called End to End testing. Verify thorough testing of every input in the application to check for desired outputs. Testing of the user's experience with the application

Cross Browser Testing

Please find below the scope of browser testingTarget Design Resolution is 1280x800 and it should work with any screen resolution

Iteration 1

• IE 9 and IE10• Safari 5.1.7 and Latest Version of Safari• Chrome 37 and Latest Version of Chrome• Mozilla 30 and Latest Version of Mozilla

Latest Version of Chrome

Iteration 2

Latest Version of Chrome

• IE 9 and IE10• Safari 5.1.7 and Latest Version of Safari• Chrome 37 and Latest Version of Chrome• Mozilla 30 and Latest Version of Mozilla

Iteration 3

• IE 9 and IE10• Latest Version of Safari• Latest Version of Chrome• Latest Version of Mozilla

• IE 9 and IE10• Safari 5.1.7 and Latest Version of Safari• Chrome 37 and Latest Version of Chrome• Mozilla 30 and Latest Version of Mozilla

Regression Testing

Regression testing shall be performed at the end of Iteration 3 to verify that previously tested features and functions do not have any new defects introduced, while correcting other problems or adding and modifying other features

User acceptance testing

User acceptance testing activities will be performed by the business users. The purpose of this testing will be to ensure the application meets the users’ expectations. This also includes focuses on usability and will include; appearance, consistency of controls, consistency of field naming, accuracy of drop down field information lists, spelling of all field name/data values, accuracy of default field values, tab sequence, and error/help messages

Test Organization

Test Types

Smoke Testing

UI and Functional Testing (UI and Database testing)

Interface Testing (Web Services Testing)

System Testing

User Acceptance Testing

Constraints

Frequent change in the requirements

Unavailability of Test Data

Unavailability of Test Environment

Test Case Development

Test Case ID

Module

Test Name

Test Data

Action

Expected Result

Test Result

Comments

Use Case

Requirement Tracebility Matrix

Tools

Subtopic 1

SQL Server 2008

Defect management

JIRA

Test Management

Excel (Test Summary Report)

Overall interface systems with GPS

Jaguar

PPL

Ceiton

Rights mart

WebStor

Word Press

International channel partner

International sales site

Media pulse

Platform

Image View

Netstorage

Functions To Be Tested

Iteration 1

Deals

Deal Offer

Programming

Tiered Pricing

Orders

Iteration 2

Fulfillment

PPL-GPS Integration

Deals Offer – Mobile View

Media Pulse-GPS Integration

Images Media

WIP

NWCO-GPS Integration

Short Form Deals

PPL-GPS Integration

RDM-GPS Integration

Jaguar-GPS Integration

Iteration 3

Production

Referential Data Mgmt

Reports

Global Search Updates

UCA Requirements