1. Test Plan A document that indicates what testing will occur, how it will occur, and what resources will be necessary for it to occur. A test plan also details how results and defect reporting will occur.

2. Purpose of Test Plan This document describes the general approach, along with the specific methodologies and techniques used by the Quality Assurance testing team to plan, organize and manage the testing activities for the overall testing

3. When Test Plan comes into picture After completion of Test Process finalization, for corresponding project, Author(Test Manager or Test Lead) prepares the document. Test plan is prepared based on the BRS and SRS documents. Before writing the Test plan the below workbench follow. 1. Team Formation 2. Identify Tactical Risks 3. Test Plan writing 4. Test Plan Review

4. Team Formation Test Manager concentrate on below factor to form Testing Team for corresponding project. Test Manager will check for Availability of test engineers (Selection will be made in 3:1 ratio)

5. Identifying Tactical risks During Test Plan writing author concentrate on identifying risks w.r.t team formation Lack of knowledge of Testers in the domain. Lack of Budget. Lack of Resources. Delays in Delivery. Lack of Test Data. Lack of Development Process Rigor. Lack of communication (In between testing team and development team) After completion of Team Formation and Risk Finding, Author(Test manager or Test Lead) start writing Test Plan document Here are the steps of writing the test plan.

6. Test plan Identifier Some type of unique company generated number to identify this test plan, its level and the level of software that it is related to. The number may also identify whether the test plan is a Master plan, a Level plan, an integration plan or whichever plan level it represents.

7. References The following documents are useful for reference in preparing the Test Plan Document. Documents that can be referenced include: Business Requirements Specifications(BRS) Functional Requirements Specifications(FRS) Project Plan High level design document (HLD) Low level design document (LLD)

8. Introduction Describes about the Testing policy, Test strategy(Applicable Test process), Company Standards and purpose of the test plan. Test Item (Feature as a module or function or service) In this section, we are going to describe the things we intend to test.

9. Features to be tested This is a listing of what is to be tested from the USERS viewpoint of what the system does. (Based on BRS QA Manager decides the Features to be tested) We can set the level of risk for each feature that need to test. We can use a simple rating scale such as (H-High, M- Medium, L-Low). These types of levels are understandable to a User. We need to be prepared to discuss why a particular level was chosen.

10. Features not to be tested This is a listing of what is NOT to be tested from both the Users viewpoint of what the system does and a configuration management/version control view. We need to identify and justify why the feature is not to be tested, there can be any number of reasons. We can see some of the reasons below. Not to be included in this build or release of the Software. Low risk has been used before and is considered stable(if the priority is low). (QA Manager will decide which Features not to be tested based on BRS)

11. Test design specification for responsible module There are 2 Types of Test Design Specifications 1)Business logic based test case design 2)Input Domain based test case design

12. Business logic based test case design A Tester prepares list of Test Cases depends on Use cases or Functional Requirements Specifications in SRS(System Requirements Specification). One Use case describes that how a user can access a specific functionality in the system Using the process below testers write the test cases.

13. BRS FRS /UC Test Case Progra m HLD LLD Write Execute

14. Input domain based test case design Sometimes use cases are Functional Specifications does not provide size and type of input objects, because the main purpose of use case is to define functionality To cover this type of input objects sizes and types Testers concentrate on Input domain based test case design method. In this method test engineers follow below approach to write the test case. 1)Study data model of the application (ER diagrams in LLD) 2)Identify and study the attributes of each identity in terms of size data type and constraints. 3)Identify the critical attributes that are used for data manipulations and retrieving.

15. Attribute /Object ValidInvalidMaxMin User Name a-z 0-9 -- A-ZBlank -- Middle Space Special Character -- Example

16. Approach (Strategy) Test strategy defines an applicable Test Process to achieve quality that we promise to user.This is your overall test strategy for this test plan Test Strategy changes from project to project Are any special tools to be used and what are they(Need to mention the tools that are using in the current project)? Will the tool require special training? Software(Need to mention the software if we are using specially) If this is a master test plan the overall project testing approach and coverage requirements must also be identified.

17. Feature pass or fail criteria This is one type of metrics, where we can know the pass/fail test criteria of the test case for module or feature, based on the Functional requirement documents Suspension Criteria Need to know when to pause in a series of tests. If the number or type of defects reaches a point, where the follow on testing has no value, it makes no sense to continue the test. In this section we specify the reasons that constitutes stoppage for a test or series of tests.

18. Environmental Needs In this section we mention the Test Hardware Requirements,Web/Application Servers, Database Servers that are required for the corresponding project.

19. Test Deliverables What is to be delivered as part of this plan? Test Plan. Test Cases. Test Scripts. Defect Reports. Test Summary Report.

20. Staffing and Training needs In this section we specify the names of the testing team those who involve in this project Training on the application/system Need to provide training if the Testers are not aware of the domain Training for any test tools to be used Need to provide schedule for training to the Testers on the required tool of the project.

21. Roles and Responsibilities In this section the Roles and Responsibilities of all the Testing Team right from QA manger to Tester is specified. For example let’s take the Responsibility of a tester. Understanding Requirments Writing test cases Executing test cases Preparing test log Defect reporting

22. Schedule (Dates and Times) Should be based on realistic and validated estimates. If the estimates for the development of the application are inaccurate, the entire project plan will slip and the testing is part of the overall project plan. We need to explain how slippages in the schedule will to be handled should also be addressed here. If the users know in advance that a slippage in the development will cause a slippage in the test and the overall delivery of the system, they just may be a little more tolerant, if they know it’s in their interest to get a better tested application.

23. Risks (list of Finding Risks) We need to 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 a new package/tool, etc. C. Extremely complex functions. D. Poorly documented modules or change requests. Approvals The final authority of the QA(Ex. Test manager) has to approve the test plan, test cases…

24. Review Test plan After completion of Test Plan writing, The author of Test Plan and corresponding Test Engineers review the test plan document for completeness and correctness depends on the below factors. Business requirement based coverage (Brs) Functional specifications based coverage (S/Wrs)

25. BRSUse Cases(SWRS)Test cases XXXX After completion of test plan review QA Manager prepares the Traceability matrix. Traceability Matrix defines mapping between User requirements (BRS)and Corresponding Test Cases. In Traceability Matrix we Will check if we are meeting the user requirements.