Test Plan Template:
A simple Test Plan template appears, as shown below:
Company Name.
- <Project Name>.
----------------------------------------------------------------------------------------------------------
Index:
------------
1.) Introduction about Project....................................Page Number.
1.1) Description of this document:.........................Page Number.
1.2) Related Documents.........................................Page Number.
2) .......... and so on...
--------------------------------------------------------------------------------------------------------------------------------
1) INTRODUCTION:
A brief Introduction about the project.
1.1) Description of this document:
This document is a test plan for the <Project Name> platform, produced by Quality Assurance. It describes the testing strategy and approach to testing. QA will use this document to validate the quality of this product. It also contains requirements of various resources required for the successful completion of the <Project Name> and associated products.
The focus of testing the <Project Name> is to support those new features that will allow easier deployment and maintenance of solutions built upon the -<Project Name> - and -<Its associated applications name>. This release of the -<Project Name> will also include legacy bug fixing, and redesigning or including missing functionality from previous release.
1.2) Related Document(s) :
● 1. Requirement and Design doc.
● 2. ------
● 3. Business Specifications Requirement doc.
● 4. ------
--------------------------------------------------------------------------------------
Software Testing and QA Engineer:
● Identify Test Data.
● Execute Test scenarios.
● Raise Software Error Reports.
● Administer Error Measurement System.
● Liaising with technical staff to ensure availability of all testing facilities.
● Collate and distribute all testing documentation, and collect completed test documentation.
● Report on testing progress to the Testing Team Lead and other designated project personnel (s).
Testing Support Team / Developers / Project Managers / Team Leads:
● Take part in daily Error Reviews.
● Co-ordinate/provide support for system test.
● Resolve errors.
● Re-release product after amendments.
● Support Systems Testers.
● Regularly review Testing progress and provide feedback on shared docs.
● Raise and manage issues/risks relating to project or outside Test Teams control.
● Review & sign off Test approach, plans and schedule.
● All the modules in <Project Name>
● Search Forms
● Buttons/Tabs
● Accessibility
● Availability
● Compatibility
● Functional
● Performance
● Reliability
● Scalability
● Usability
● List of Features not to be tested.
The objective of this <Project Name> Test Plan is to define the procedures and logistics necessary to test the functionality of <Project Name> and applications associated with the <Project Name>.
The following objectives were incorporated into the test plan:
● Provide a formal testing process
● Test each Tier of requirement.
● Document the results of each test.
● Collect issues from the tests.
● Provide verifiable documentation that the concept, as developed, is functional.
● To test the functionality of <Project Name> and intended working of the same.
The testing will require participation of most of the personnel assigned to the project in order to operate and oversee the <Project Name>. To assist in coordination and documentation.
A dedicated testing team will be needed that will have no other duties during the testing period. This test team will oversee the testing. Optimally, the test team will consist of one team of at least four testers.
This team will consist of —
1.) Name 1.
2.)
3.)
4.)
Recruitment Required:
The <Project Name> Test Phase will require the following resources:
● <Project Name> Test environment.
● Proactive chat system.
● More than one land line phone number for SMS and Call tracking
● Tools for Load and stress testing [Tool yet to be decided].. OR Load Runner.
● Basic training on Tools used.
8.) Classification of Bugs:
● Blocker: This bug prevents developers from testing or developing the software.
● Critical: The software crashes, hangs, or causes you to lose data.
● Major: A major feature is broken.
● Normal: It's a bug that should be fixed.
● Minor: Minor loss of function, and there's an easy work around.
● Trivial: A cosmetic problem, such as a misspelled word or misaligned text.
● Enhancement: Request for new feature or enhancement.
9.) Bugs Priority List:
Priority
|
Priority Level
|
Priority Description
|
5
|
Must fix
|
Must be fixed immediately;
the product cannot ship with
This bug.
|
4
|
Should fix
|
Should be fixed as soon as
possible or else it will ruin the
Company’s reputation.
|
3
|
Fix
|
Fix it when it does not delay
The shipping date.
|
2
|
Low Priority
|
Fix it after all other higher levels are done.
|
1
|
Trivial
|
Fix it to make the product
Perfect.
|
● During tests, errors will be recorded as they are detected on Error Report forms.
● Errors should be strictly turned around by Bugs Fixing Team and reported back to QA.
Identify what software is to be tested and what the critical areas are, such as:
A. Delivery of a third party product.B. Ability to use and understand product/package/tool, etc.D. Extremely complex functions.E. Modifications to components with a past history of failure.F. Poorly documented modules or change requests.
There are some inherent software risks such as complexity; these need to be identified. They include :
A. Safety
B. Multiple interfaces
C. Impacts on Client
D. Flash player dependencies.
B. Multiple interfaces
C. Impacts on Client
D. Flash player dependencies.
Training on the application/system.
Training for any test tools to be used/ required.
APPROACH:
It is hoped that there will be at least one full time independent test team for system/Load testing. However, with the time line constraint established to one month; most testing will be done by the test team with the development team’s participation.
UNIT Testing:
Will be done by the developer and will be approved by the development team leader.
ACCEPTANCE Testing:
UAT shall be performed by the actual end users with the assistance of the project manager. Applicaions will enter into Acceptance test after all critical and major defects have been corrected. An application may have one or more major defect as long as it does not impede testing or performance of the application. Prior to final completion of acceptance testing, all open critical and major defects MUST be corrected and verified by the Customer test representative.
To generate a final test report and wait for sign-off. The bugs should be reported as clear and complete as possible. The informal feedback of these tests should be collected, evaluated and could lead to feature requests.
Required
|
Name
|
Sign off and Date
|
Yes
| ||
Yes
| ||
Yes
| ||
Yes
| ||
Yes
| ||
Yes
| ||
Yes
| ||
Yes
| ||
Yes
|
No comments:
Post a Comment
I would like to thank you for your comments..! Please keep commenting. To get posts and updates via mail, I would suggest you to subscribe the Blog. Thanks Again..!