Test Plan Template(Name of the Product)

Prepared by: (Names of Group Members)

(Date)

TABLE OF CONTENTS1.0 Introduction2.0 Objectives and Tasks2.1 Objectives2.2 Tasks3.0 Scope4.0 Testing Strategy4.1 Alpha Testing (Unit Testing)4.2 System And Integration Testing4.3 Performance And Stress Testing4.4 User Acceptance Testing4.5 Automated Regression Testing4.6 Beta Testing4.7Compatibility Testing5.0 Hardware Requirements6.0 Environment Requirements6.1 Main Frame6.2 Workstation7.0 Test Schedule8.0 Control Procedures9.0 Features To Be Tested10.0 Features Not To Be Tested11.0 Resources/Roles & Responsibilities12.0 Schedules13.0 Significantly Impacted Departments (Sids)14.0 Dependencies15.0 Risks/Assumptions16.0 Tools17.0 Approvals

1.0 INTRODUCTIONA brief summary of the product being tested. Outline all the functions at a high level.

2.0 OBJECTIVES AND TASKS2.1 Objectives of Test PlanDescribe the objectives supported by the Master Test Plan, eg., defining tasks andresponsibilities, vehicle for communication, document to be used as a service levelagreement, etc.

2.2 Tasks of Test PlanList all tasks identified by this Test Plan, i.e., testing, post-testing, problem reporting, etc.We assume each implemented functional req. as a test scenario and for every test scenario, we prepare a set of test cases.Below is the sample requirements traceabilitytable for task mapping (#BR > #FR > #TS > #TA)

(Add your project functionalities in this table and prepare test scenarios)

Sr.No.

#Business Requirements

(BR)

#Functional Requirements

(FR)

#Test Scenarios (TS)

#Testing Approaches /Strategies

(TA)01 Reduce Call Center

and other support system costs per incident

Forums or content co-creation(e.g. wikis)

Forum Board(Create Post/Edit Post/Display Post/Rank Post/Delete Post) 1.Functional Testing

(Standard Testing)2.Non-Functional Testing

02 Increase customer loyalty and engagement

Gamification&Leaderboard Creation

Leaderboard(Rank Customer/Discount Offerings)

3.0 SCOPEGeneralThis section describes what is being tested, such as all the functions of a specific product, its existing interfaces, integration of all functions. List here how you will accomplish the items that you have listed in the "Scope" section. For example, if you have mentioned that you will be testing the existing interfaces, what would be the procedures you would follow to notify the key people to represent their respective areas, as well as allotting time in their schedule for assisting you in accomplishing your activity?

4.0 TESTING STRATEGYDescribe the overall approach to testing. For each major group of features or featurecombinations, specify the approach which will ensure that these feature groups areadequately tested. Specify the major activities, techniques, and tools which are used to test the designated groups of features.The approach should be described in sufficient detail to permit identification of the major testing tasks and estimation of the time required to do each one.

Refer and choose test strategies for Web-based Applications from following table

Refer and choose test strategies for Desktop/Standalone Applications from following table

1. Functional testing (Generally required for all products. The purpose of functional testing is to reveal defects related to the product’s/component’s functionality and conformance to documented functional requirement specifications.)

2. Unit testing - usually accomplished by developers; 3. Structural testing4. Exploratory testing (Always write down what you do and what happens when you

run exploratory tests.)5. Component/Sub-component testing 6. Walkthroughs, inspections, desk-checking7. Verification (e.g., reviews, examinations, walkthroughs, desk-checking, or

inspection of interim work products such as requirements, design, specifications, documentation, prototypes, code; early detection of errors are highly cost effective.)

8. Developmental integration testing 9. Developmental system testing 10. User acceptance testing (Generally required for all products. The purpose of

acceptance testing is convincing the user that the product fulfills expected user needs.)

11.Performance/load/stress testing

12.Security/access testing 13.Usability testing14.Operational procedure documentation verification15.Regression testing (Reliability)16.Alpha & Beta Testing17. Smoke Test - …establish that the system is stable and all major functionality is

present and works under ‘normal’conditions18.Pilot testing19. Recovery testing - …can involve the manual functions of an application, loss of

input capability, loss of communicationlines, hardware or operating system failure, loss of database integrity, operator error, or application system failure.

20.Operations testing / Usability Testing (Ease of Operations)21. Compliance testing - …verifies that the application was developed in accordance

with information technology standards,procedures, and guidelines.22. Manual-Support Testing - Systems commence when transactions originate and

conclude with the use of the results ofprocessing. The manual part of the system requires the same attention to testing as does the automated segment.

23.Intersystem [interface] Testing24. Parallel Testing (e.g., matching test results between current live system and new

system.)25. Compliance Testing (Authorization) - Testing should verify that the authorization

rules have been properly implemented and evaluate compliance with them. Test conditions should include unauthorized transactions or processes to ensure that they arerejected, as well as ensuring authorized transactions are accepted.

And preparea test strategy table as below (which will includeshortlisted testing approaches, you may add your own testing approaches as per your project need)

Approach Type of Testing

Manual Testing Automated Testing on

DeviceTools/APIs/LibrariesUsing

DeviceUsing

Emulator

Standard Testing

(Functional Testing)

Unit Testing No Yes No 1. Junit(unit testing framework)

2. Selenium WebDriver/IDE(web application automation testing framework)

3. Jmeter(performance/load testing)

4. Appium(mobile app automation framework)

5. Responsive Design Mode(responsive web design

Integration Testing No Yes No

System Testing Yes No YesRegression

Testing Yes No Yes

Acceptance Testing Yes No No

Special Type of Testing to

Address Specific

Challenge

Compatibility Testing Yes No Yes

GUI Testing Yes No No

emulator)6. IronWASP7. HP LoadRunner

And many more….

Client-specificTesting

Performance Testing

- - -Security Testing

--

Describe every testing strategy and prepare tables for it.

4.1 Unit TestingDefinition:Specify the minimum degree of comprehensiveness desired. Identify the techniqueswhich will be used to judge the comprehensiveness of the testing effort (for example,determining which statements have been executed at least once). Specify any additional completion criteria (for example, error frequency). The techniques to be used to trace requirements should be specified.Participants:List the names of individuals/departments who would be responsible for Unit Testing.Methodology:Describe how unit testing will be conducted. Who will write the test scripts for the unit testing, what would be the sequence of events of Unit Testing and how will the testing activity take place?

MODULE/FUNCTIONALITY NAME:UNIT/CLASS:

CREATED BY:

DATE OF CREATION:

DATE OF REVIEW:

TEST CASE

ID

TEST UNIT/CLASS

TEST CASE

PRE-CONDITION

TEST STEPS

TEST DATA

EXPECTED RESULT

POST CONDITION

ACTUAL RESULT

STATUS(PASS/FAIL)

4.2 System and Integration TestingDefinition:List what is your understanding of System and Integration Testing for your project.Participants:Who will be conducting System and Integration Testing on your project? List theindividuals that will be responsible for this activity.Methodology:Describe how System & Integration testing will be conducted. Who will write the test scripts for the unit testing, what would be sequence of events of System & Integration testing, and how will the testing activity take place?

PROJECT NAME:

MODULE/FUNCTIONALITY:

CREATED BY:

DATE OF CREATION:

DATE OF REVIEW:

TEST CASE

ID

TEST SCENARIO

TEST CASE

PRE-CONDITION

TEST STEPS

TEST DATA

EXPECTED RESULT

POST CONDITION

ACTUAL RESULT

STATUS(PASS/FAIL)

4.3 Performance and Stress Testing

Definition:List what is your understanding of Stress Testing for your project.Participants:Who will be conducting Stress Testing on your project? List the individuals that will be responsible for this activity.Methodology:Describe how Performance & Stress testing will be conducted. Who will write the test scripts for the testing, what would be sequence of events of Performance & Stress Testing, and how will the testing activity take place?

PROJECT NAME:

MODULE/FUNCTIONALITY:

CREATED BY:

DATE OF CREATION:

DATE OF REVIEW:

Web Page ID # Samples Average Min Max Std. Dev. Throughput SENT

KB/secRECVD KB/sec Avg. Bytes

4.4 User Acceptance TestingDefinition:

The purpose of acceptance test is to confirm that the system is ready for operational use. During acceptance test, end-users (customers) of the system compare the system to its initial requirements.Participants:Who will be responsible for User Acceptance Testing? List the individuals' names and responsibility.Methodology:Describe how the User Acceptance testing will be conducted. Who will write the testscripts for the testing, what would be sequence of events of User Acceptance Testing, and how will the testing activity take place?

PROJECT NAME:

MODULE/FUNCTIONALITY:

CREATED BY:

DATE OF CREATION:

DATE OF REVIEW:

ID Test Description Step # Test Steps Exp. Results #Business Req. Covered

#Functional Req. Covered

4.5 Automated Regression TestingDefinition:Regression testing is the selective retesting of a system or component to verify that

modifications have not caused unintended effects and that the system or component stillworks as specified in the requirements.Participants:Methodology:

Prepare table as per your need.

4.6 Beta TestingParticipants:Methodology:A beta test is the second phase of software testing in which a sampling of the intended audience tries the product out.

Prepare table as per your need.

4.7 Compatibility Testing:Definition: Compatibility Testing is a type of Software testing to check whether your software is capable of running on different hardware, operating systems, applications , network environments or Mobile devicesParticipants: ….

Methodology: ….

ID

Hardware Specification

(Processor/Clock Speed/RAM)

Operating System Telecom Network Browsing Application Interactive Testing

(PASS/FAIL) Comments

5.0 HARDWARE REQUIREMENTSComputers

Modems

6.0 ENVIRONMENT REQUIREMENTS6.1 Main FrameSpecify both the necessary and desired properties of the test environment. Thespecification should contain the physical characteristics of the facilities, including thehardware, the communications and system software, the mode of usage (for example,stand-alone), and any other software or supplies needed to support the test. Also specify the level of security which must be provided for the test facility, system software, and proprietary components such as software, data, and hardware. Identify special test tools needed. Identify any other testing needs (for example, publications or office space). Identify the source of all needs which are not currentlyavailable to your group.

5.2 Workstation

7.0 TEST SCHEDULEInclude test milestones identified in the Software Project Schedule as well as all itemtransmittal events. Define any additional test milestones needed. Estimate the time required to do each testing task. Specify the schedule for each testing task and test milestone. For each testing resource (that is, facilities, tools, and staff), specify its periods of use.

Task Name Start Date

Finish Date

Effort Estimation

Comments

Test Planning Review Requirements documents 2 d Create initial test estimates 1 dStaff and train new test resourcesFirst deploy to QA test environmentFunctional testing – Iteration 1Iteration 2 deploy to QA test environmentFunctional testing – Iteration 2System testingRegression testingUser Acceptance TestingResolution of final defects and final build testingDeploy to Staging environmentPerformance testingRelease to Production

8.0 CONTROL PROCEDURESProblem ReportingDocument the procedures to follow when an incident is encountered during the testing process. If a standard form is going to be used, attach a blank copy as an "Appendix" tothe Test Plan. In the event you are using an automated incident logging system, writethose procedures in this section.

Change RequestsDocument the process of modifications to the software. Identify who will sign off on the changes and what would be the criteria for including the changes to the current product. If the changes will affect existing programs,these modules need to be identified.

9.0 FEATURES TO BE TESTEDIdentify all software features and combinations of software features that will be tested.

10.0 FEATURES NOT TO BE TESTEDIdentify all features and significant combinations of features which will not be tested and the reasons.

11.0 RESOURCES/ROLES & RESPONSIBILITIESSpecify the staff members who are involved in the test project and what their roles are going to be (for example, Mary Brown (User) compile Test Cases for AcceptanceTesting). Identify groups responsible for managing, designing, preparing, executing, and resolving the test activities as well as related issues. Also identify groups responsible for providing the test environment.These groups may include developers, testers, operations staff, testing services, etc.

12.0 SCHEDULESMajor Deliverables {Mandatory}Identify the deliverable documents. You can list the following documents:

Deliverable For Date / Milestone

Test PlanProject Manager; QA Director; Test Team

Traceability MatrixProject Manager; QA Director

Test Status report QA Manager, QA DirectorTest Result Report Project Manager

13.0 SIGNIFICANTLY IMPACTED DEPARTMENTS (SIDs)

Department/Business Area Bus. Manager Tester(s)

14.0 DEPENDENCIESIdentify significant constraints on testing, such as test-item availability, testing-resource availability, and deadlines.

15.0 RISKS/ASSUMPTIONSIdentify the high-risk assumptions of the test plan. Specify contingency plans for each (for example, delay in delivery of test items might require increased night shiftscheduling to meet the delivery date).

16.0 TOOLSList the Automation tools you are going to use.

List also the Bug tracking tool here.

17.0 APPROVALS

Specify the names and titles of all persons who must approve this plan. Provide space for the signatures and dates.

Name (In Capital Letters) Signature Date1.2.3.

4.

Defect Report Template

In most companies, a defect reporting tool is used and the elements of a report can vary. However, in general, a defect report can consist of the following elements.

ID Unique identifier given to the defect. (Usually, automated)Project Project name.Product Product name.Release Version Release version of the product. (e.g. 1.2.3)Module Specific module of the product where the defect was detected.Detected Build Version

Build version of the product where the defect was detected (e.g. 1.2.3.5)

Summary Summary of the defect. Keep this clear and concise.Description Detailed description of the defect. Describe as much as possible but

without repeating anything or using complex words. Keep it simple but comprehensive.

Steps to Replicate Step by step description of the way to reproduce the defect. Number the steps.

Actual Result The actual result you received when you followed the steps.Expected Results The expected results.Attachments Attach any additional information like screenshots and logs.Remarks Any additional comments on the defect.Defect Severity Severity of the Defect. (See Defect Severity)Defect Priority Priority of the Defect. (See Defect Priority)Reported By The name of the person who reported the defect.Assigned To The name of the person that is assigned to analyze/fix the defect.Status The status of the defect. (See Defect Life Cycle)Fixed Build Version Build version of the product where the defect was fixed (e.g. 1.2.3.9)