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
Environment Requirements
1
Web Server
AEWEBSVCDEV4
Installation of the application
Net – 4.5IIS – 7.5OS – Win2008R2
Intel(R) Xenon, 4 GB RAM, 30 GB HDD
2
App Server
AEWEBAPPIDDEV
Managing application data
Net – 4.5IIS – 7.5OS – Win2008R2
Intel(R) Xenon, 4 GB RAM, 30 GB HDD
3
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
4
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)
UT1 for GPS and Other systems (PPL, Jaguar, MediaPulse and others)DB – ut1 for GPS and Other systems (PPL, Jaguar, MediaPulse and others)
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)
Wondershare EdrawMind
