El Cinco Trouble Ticket System
Test Plan
Authored By:
Kevin Harper
Ian Jenson
Kevin Kreutz
Mark Romero
John Sanders
Table of Contents
Test Plan Identifier - ELC01.1. 2
References. 2
Introduction. 2
Test Items. 2
Software Risk. 2
Issues Features to be Tested. 2
Features not to be Tested. 3
Approach. 3
Testing Levels. 3
Unit Testing. 3
System/Integration Testing. 3
Browser Compatibility Testing. 3
Acceptance Testing. 3
Test Tools. 3
Item Pass/Fail Criteria. 3
Suspension Criteria and Resumption Requirements. 4
Suspension. 4
Resumption. 4
Test Deliverables. 4
Remaining Test Tasks. 4
Environmental Needs. 4
Staffing and Training Needs. 4
Responsibilities. 5
Schedule. 5
Planning Risks and Contingencies. 5
Approvals. 5
Test Plan Identifier - ELC01.1
References
This document will reference the Software Requirements Specification Document. All references are explicitly cross-referenced for the reader’s ease of use.
Introduction
This is the Master Test Plan for the El Cinco trouble ticket system project. The primary focus of this plan is to ensure that the trouble ticket system is reliable, efficient and easy to use.
The project will have three levels of testing, Unit, System/Integration and Acceptance. The details for each level are addressed in the approach section and will be further defined in the level specific plans.
The estimated time line for this project is two (2) months, as such, any delays in the development process or in the installation could have significant effects on the test plan.
Test Items
The trouble ticket system will be tested throughout the development process to be sure that the system conforms to the software requirements specification. Before delivery the external authentication integration and browser compatibility will be tested.
Software Risk
The external authentication integration is the only part of the system that is not within the control of the trouble ticket system. Any downtime of the system, or lack of cooperation from the department running the system could delay testing.
Issues Features to be Tested
The following is a list of the areas to be focused on during testing of the application.
- External authentication system integration
- Email piping
- Email notification
- Trouble ticket entry and edit screens
- File attachments to trouble tickets
- Canned responses to trouble tickets
- Ticket search
- Ticket filtering
- Knowledge base
- Browser compatibility
Features not to be Tested
Browser compatibility will not be tested for Internet Explorer versions earlier than 7.0.
Approach
Testing Levels
Testing will be done by the development team at different phases of the project outlined below.
Unit Testing
Unit testing will be done by the developer during the development of a particular unit. Unit testing will ensure that the unit performs the functionality described in the Software Requirement Specification, particularity the use cases. Unit testing should also correct any bugs in the unit before it is integrated into the rest of the system.
System/Integration Testing
System testing will be done by the development team to ensure that individual units integrate well together. System testing should be performed throughout the development process as more units are added to the system. Additionally, system testing should test the integration between units to ensure that the system as a whole meets the specifications laid out in the Software Requirement specification.
Browser Compatibility Testing
Browser compatibility testing will occur after the system integration is complete. Browser compatibility will check to make sure the system displays and functions correctly in Firefox 3.x, Internet Explorer 7.x, Internet Explorer 8.x, Safari, and Chrome. Firefox 3.x will be use as the design standard during browser compatibility testing.
Acceptance Testing
Acceptance testing will be performed by the project stakeholder and development team before the final product is delivered to ensure that it conforms to the Software Requirement Specification. Any defect identified will be corrected before delivery is made.
Test Tools
No test tools have been identified for this project.
Item Pass/Fail Criteria
A unit or system/integration test passes if there are no PHP, Javascript, MySQL, web server, or HTTP error message returned and the unit or system performs the functionality described in the Software Requirements Specification, otherwise the test fails.
A browser compatibility test passes if all elements on a page are within five (5) pixels of the location on the screen when viewed in Firefox. Additionally all actions should perform the action as defined in the Software Requirements Specification without returning any PHP, Javascript, MySQL, web server, or HTTP error messages. The test fails if it does not meet these two criteria.
Suspension Criteria and Resumption Requirements
Suspension
If a particular unit is causing fatal errors that prevent further testing that unit should be removed from the system. If the system cannot be run or tested without the unit, then testing should be suspended.
Resumption
Once the error in the unit has been corrected it should be integrated back into the system and system/integration testing should be performed.
Test Deliverables
The following documents shall be included:
Master Test Plan (This document)
Test Incident Report Logs
Test summary report
Remaining Test Tasks
- Prepare the hardware test environment
- Perform the test procedures
- Resolve test incident reports
- Repeat tasks (3) - (5) until all test procedures are successful
- Prepare the test summary report
Environmental Needs
The test environment shall consist of a replication of the production enviroment including a PHP, MySQL installation.
Staffing and Training Needs
There are no additional staffing and training needs required for testing because the development team will perform testing.
Responsibilities
The development team will be responsible for all testing, and shall bring up all testing concerns in team meeting or via email.
Schedule
Unit and System/integration testing shall take place during the development process. Final system/integration testing, browser compatibility and acceptance testing shall take place from 04/26/2010 through 05/02/2010.
Planning Risks and Contingencies
If the scope or personnel of the project dramatically changes during the development process, testing could be delayed while the development team is brought up to speed with the changes. No part of the testing plan should be bypassed.
Approvals
|
Kevin Harper - Developer / Tester |
|
|
Ian Jenson - Developer / Tester |
|
|
Dennis Kreutz - Developer / Tester |
|
|
Mark Romero - Developer / Tester |
|
|
John Sanders - Developer / Tester |
|
|
Kevin Harper - Stakeholder |