1、 SOFTWARE TEST PLAN Content 1. INTRODUCTION . 1 2. SCOPE . 1 2.1 Features to be Tested. . 1 2.2 Features not to be Tested. . 1 3. QUALITY OBJECTIVES . 1 3.1 Primary Objectives . 1 3.2 Secondary Objectives . 2 4. TEST STRATEGY . 2 4.1 Testing Types . 2 4.2 Testing Tools . 3 4.3 Bug Severity and Prior
2、ity Definition . 3 4.3.1 Severity List . 3 4.3.2 Priority List . 4 4.4 Bug Triage . 4 5. ENTRY AND EXIT CRITERIA . 5 5.1 Entry Criteria . 5 5.2 Exit Criteria . 5 6. SUSPENSION CRITERIA AND RESUMPTION REQUIREMENTS . 5 6.1 Suspension Criteria . 5 6.2 Resumption Criteria . 6 7. SCHEDULE AND TEST DELIVE
3、RABLES . 6 8. TESTING ROLES . 6 8.1 Roles and Responsibility . 6 8.2 Explanation on QA Role in Test Process . 7 9. STAFFING AND TRAINING NEEDS . 8 10. RESOURCE AND ENVIRONMENT NEEDS . 9 11. RISKS AND CONTINGENCIES . 9 11.1 Risk Description . 9 11.2 Risk Management . 10 12. APPROVALS . 10 1 1. INTROD
4、UCTION Customer wants a perfect website, which passed the full cycle of manual testing. Given the specificity of the site it is very important to have the same quality and the site. The Test Plan has been created to facilitate communication within the team members. This document describe approaches
5、and methodologies that will apply to the unit, integration and system testing of the http:/www.EasyQA.com/, a website gathering answers that are asked by a reporter, or by the people in an audience. This plan includes the scopse, objectives, testing strategies, entry and exit criteria, suspension cr
6、iteria. This document has clearly identified the schedule and corresponding test deliverables, testing roles, stuff and training needs, the resource and environmental needs as well as the risks and contingencies. 2. SCOPE The document mainly targets the GUI testing and validating data in report outp
7、ut as per Requirements Specifications provided by Client. 2.1 Features to be Tested. GUI Search and Filters Logic Performance 2.2 Features not to be Tested. Not other than mentioned above in section 2.1 3. QUALITY OBJECTIVES 3.1 Primary Objectives A primary objective of testing is to: assure that th
8、e system meets the full requirements, including quality requirements (functional and non-functional requirements) and fit metrics for each quality requirement and satisfies the use case scenarios and maintain the quality of the product. At the end of the project development cycle, the user should fi
9、nd that the project has met or exceeded all of their expectations as detailed in the requirements. Any changes, additions, or deletions to the requirements document, Functional Specification, or Design Specification will be documented and tested at the highest level of quality allowed within the rem
10、aining time of the project and within the ability of the test team. 2 3.2 Secondary Objectives The secondary objectives of testing will be to: identify and expose all issues and associated risks, communicate all known issues to the project team, and ensure that all issues are addressed in an appropr
11、iate matter before release. As an objective, this requires careful and methodical testing of the application to first ensure all areas of the system are scrutinized and, consequently, all issues (bugs) found are dealt with appropriately. 4. TEST STRATEGY 4.1 Testing Types Black box testing: It is so
12、metimes called behavioral testing or partition testing. This kind of testing focuses on the functional requirements of the software. It enables one to derive sets of input conditions that that will fully exercise all functional requirements for a program. GUI Testing: GUI testing will includes testi
13、ng the UI part of report. It covers Users Report format, look and feel, error messages, spelling mistakes, GUI guideline violations. Integration Testing: Integration testing is systematic technique for constructing the program structure while conducting test to uncover errors associated with interac
14、ting. In Report, integration testing includes the Testing Report from respective location(s). Functional Testing: Functional testing is carried out in order to find out unexpected behavior. The characteristic of functional testing are to provide correctness, reliability, testability and accuracy of
15、the report output/data. System Testing: System testing of software is testing conducted on a complete, integrated system to evaluate the systems compliance with its specified requirements. Performance Testing: - Check the optimal time the page is loaded - Check the operation of the system 3 User acc
16、eptance testing: The purpose behind user acceptance testing is to conform that system is developed according to the specified user requirements and is ready for operational use. Acceptance testing is carried out at two levels - Alpha and Beta Testing. User acceptance testing (UAT) will be done at th
17、e client. Alpha testing: The alpha test is conducted at the developers site by client. 4.2 Testing Tools Process Tool Test case creation Microsoft Excel Test case tracking Microsoft Excel Test case execution Manual Test case management Microsoft Excel Defect management Microsoft Word Test reporting
18、PDF Check list creating Microsoft Excel Project structure Mind Map (.xmind) 4.3 Bug Severity and Priority Definition Bug Severity and Priority fields are both very important for categorizing bugs and prioritizing if and when the bugs will be fixed. The bug Severity and Priority levels will be define
19、d as outlined in the following tables below. Testing will assign a severity level to all bugs. The Test Lead will be responsible to see that a correct severity level is assigned to each bug. The QA Lead, Development Lead and Project Manager will participate in bug review meetings to assign the prior
20、ity of all currently active bugs. This meeting will be known as “Bug Triage Meetings”. The QA Lead is responsible for setting up these meetings on a routine basis to address the current set of new and existing but unresolved bugs. 4.3.1 Severity List The tester entering a bug into GForge is also res
21、ponsible for entering the bug Severity. 4 Severity ID Severity Severity Description 1 Critical The module/product crashes or the bug causes non- recoverable condition: system crashes, GP Faults, or database or file corruption, or potential data loss, program hangs requiring reboot are all examples o
22、f a Sev. 1 bug. 2 Major Major system component unusable due to failure or incorrect functionality. Sev. 2 bugs cause serious problems such as a lack of functionality, or insufficient or unclear error messages that can have a major impact to the user, prevents other areas of the app from being tested
23、, etc. Sev. 2 bugs can have a work around, but the work around is inconvenient or difficult. 3 Minor Incorrect functionality of component or process. There is a simple work around for the bug if it is Sev. 3. 4 Trivial Documentation errors or signed off severity 3 bugs. 4.3.2 Priority List Priority
24、Priority Level Priority Description 1 High This bug must be fixed immediately; the product cannot ship with this bug. 2 Medium These are important problems that should be fixed as soon as possible. It would be an embarrassment to the company if this bug shipped. 3 Low The problem should be fixed wit
25、hin the time available. If the bug does not delay shipping date, then fix it. 4.4 Bug Triage Bug Triages will be held throughout all phases of the development cycle. Bug triages will be the responsibility of the Test Lead. In the testing phase, triages will be held on a regular basis with the time f
26、rame being determined by the bug find rate and project schedules. Thus, it would be typical to hold few triages during the Planning phase, then maybe one triage per week during the Design phase, ramping up to twice per week during the latter stages of the Development phase. Then, the Stabilization p
27、hase should see a substantial reduction in the number 5 of new bugs found, thus a few triages per week would be the maximum (to deal with status on existing bugs). The QA Lead, Product Manager, and Development Lead should all be involved in these triage meetings. The QA Lead will provide required do
28、cumentation and reports on bugs for all attendees. The purpose of the triage is to determine the type of resolution for each bug and to prioritize and determine a schedule for all “To Be Fixed Bugs. Development will then assign the bugs to the appropriate person for fixing and report the resolution
29、of each bug back into the GForge bug tracker system. The QA Lead will be responsible for tracking and reporting on the status of all bug resolutions. 5. ENTRY AND EXIT CRITERIA 5.1 Entry Criteria All test hardware platforms must have been successfully installed, configured, and functioning properly.
30、 All the necessary documentation, design, and requirements information should be available that will allow testers to operate the system and judge the correct behavior. All the standard software tools including the testing tools must have been successfully installed and functioning properly. Proper
31、test data is available. The test environment such as, lab, hardware, software, and system administration support should be ready. QA resources have completely understood the requirements QA resources have sound knowledge of functionality Reviewed test scenarios, test cases and RTM 5.2 Exit Criteria
32、A certain level of requirements coverage has been achieved. No high priority or severe bugs are left outstanding. All high-risk areas have been fully tested, with only minor residual risks left outstanding. Cost when the budget has been spent. The schedule has been achieved. 6. SUSPENSION CRITERIA A
33、ND RESUMPTION REQUIREMENTS 6.1 Suspension Criteria The build contains many serious defects which seriously or limit testing progress. 6 Significant change in requirements suggested by client Software/Hardware problems Assigned resources are not available when needed by test team. 6.2 Resumption Crit
34、eria Resumption will only occur when the problem(s) that caused the caused the suspension have been resolved 7. SCHEDULE AND TEST DELIVERABLES Deliverable For Due Date Test Plan Project Manager; QA Director; Test Team 25/06/19 Traceability Matrix Project Manager; QA Director 20/08/19 Test Results Pr
35、oject Manager 20/11/19 Test Status report QA Manager, QA Director 20/01/20 Metrics All team members 20/03/20 8. TESTING ROLES 8.1 Roles and Responsibility Role Staff Member Responsibilities Project Manager Carl Nagle 1. Acts as a primary contact for development and QA team. 2. Responsible for Projec
36、t schedule and the overall success of the project. QA Lead Agile Sherpa 1. Participation in the project plan creation/update process. 2. Planning and organization of test process for the release. 3. Coordinate with QA analysts/engineers on any issues/problems encountered during testing. 4. Report pr
37、ogress on work assignments to the PM. 7 8.2 Explanation on QA Role in Test Process Understanding Requirements: - Requirement specifications will be sent by client. - Understanding of requirements will be done by QA Preparing Test Cases: - QA will be preparing test cases based on the exploratory test
38、ing. This will cover all scenarios for requirements. Preparing Test Matrix: - QA will be preparing test matrix which maps test cases to respective requirement. This will ensure the coverage for requirements. Reviewing test cases and matrix: - Peer review will be conducted for test cases and test mat
39、rix by QA Lead - Any comments or suggestions on test cases and test coverage will be provided by reviewer respective Author of Test Case and Test Matrix - Suggestions or improvements will be re-worked by author and will be send for approval - Re-worked improvements will be reviewed and approved by r
40、eviewer Creating Test Data: - Test data will be created by respective QA on clients developments/test site based on scenarios and Test cases. Executing Test Cases: QA Jacob Proffitt Andrew Hunter Kent Beck 1. Understand requirements 2. Writing and executing Test cases 3. Preparing RTM 4. Reviewing T
41、est cases, RTM 5. Defect reporting and tracking 6. Retesting and regression testing 8 - Test cases will be executed by respective QA on clients development/test site based on designed scenarios, test cases and Test data. - Test result (Actual Result, Pass/Fail) will updated in test case document Def
42、ect Logging and Reporting: - QA will be logging the defect/bugs in Word document, found during execution of test cases. After this, QA will inform respective developer about the defect/bugs. Retesting and Regression Testing: - Retesting for fixed bugs will be done by respective QA once it is resolve
43、d by respective developer and bug/defect status will be updated accordingly. In certain cases, regression testing will be done if required. Deployment/Delivery: - Once all bugs/defect reported after complete testing is fixed and no other bugs are found, report will be deployed to clients test site b
44、y PM. - Once round of testing will be done by QA on clients test site if required Report will be delivered along with sample output by email to respective lead and Report group. - QA will be submitting the filled hard copy of delivery slip to respective developer. - Once lead gets the hard copy of d
45、elivery slip filled by QA and developer, he will send the sreport delivery email to client. 9. STAFFING AND TRAINING NEEDS It is preferred that there will be at least one (1) full time tester assigned to the project for the system/integration and acceptance testing phases of the project. This will r
46、equire assignment of a person part time at the beginning of the project to participate in reviews etc. and approximately four months into the project they would be assigned full time. If a separate test person is not available the project manager/test manager will assume this role. In order to provi
47、de complete and proper testing the following areas need to be addressed in terms of training. A. The developers and tester(s) will need to be trained on the basic operations of the EDI interface. Prior to final acceptance of the project the operations staff will also require complete training on the
48、 EDI communications process. 9 B. The sales administration staff will require training on the new screens and reports. C. At least one developer and operations staff member needs to be trained on the installation and control of the PC based distributors EDI package. The distributors personnel will a
49、lso have to be trained on the PC based package and its operational characteristics. 10. RESOURCE AND ENVIRONMENT NEEDS Support level 1 (browsers): - Windows 8: Edge, Chrome (latest), Firefox (latest), Safari (latest) - Mac OS X: Chrome (latest), Firefox (latest), Safari (latest) - Linux Ubuntu: Chro
50、me (latest), Firefox (latest) Support level 1 (devices): - iPhone 5 / 6, iPad 3, Nokia Lumia 910, Google Nexus 7, LG G3. Support level 2: - xWindows 7: IE 9+, Chrome (latest), Firefox (latest), Safari (latest) - Windows XP: IE 8, Chrome (latest), Firefox (latest), Safari (latest) 11. RISKS AND CONTI
