Test Planning and Writing a Test Plan

Test planning is the activities of identifying and designing the testing process.  The planning phase provides an opportunity for the tester to determine what to test and how to test it. Creating a Master Test Plan is the best way to do it and is a major output of test planning.
Test Plan is the most important ongoing document which is created by QA team and helps to manage test project.
Test Planning is one of the MUST have skill for a software tester, including the selection of techniques and methods to be used to validate the product against its approved requirements and design. Test planning assesses the business and technical risks of the software application, and then develops a plan to determine if the software minimizes those risks. Test planners must understand the development methods and environment to effectively plan for testing. Test plan generally includes:

Test Scope – what is to be tested 
Requirements/Traceability – defines the tests needed and relates those tests to the requirements to be validated.

Estimating – determines the amount of resources and time frames required to accomplish the planned activities.
Scheduling – establishes milestones for completing the testing effort and their dependencies on meeting the rest of the schedule.

Staffing – selecting the size and competency of staff needed to achieve the test plan objectives.
Test Approach – methods, tools, coverage and techniques used to accomplish test objectives. 
Test Check Procedures (i.e., test quality control) – set of procedures based on the test plan and test design, incorporating test cases that ensure that tests are performed correctly and completely. 
Maximizing test Effectiveness – methods to assure test resources will be used most effectively.

Test Planning Steps:
Step 1. Build Test Plan:
Identified all those mentioned above, gather some ideas and then focus on writing the Test Plan.
1.1 Prepare Introduction
1.2 Define High level functional Approach
1.3 Identify types of test
1.4 Identify Exit Criteria
1.5 Establish regression testing strategy.
1.6 Organize Test team
1.7 Establish test environment
1.8 Define dependencies
1.9 Create Test Schedule
1.10 Select Test Tool
1.11 Establish defect tracking procedures
1.12 Establish change request procedures
1.13 Establish Version control procedures
1.14 Define Build configuration procedures
1.15 Establish reporting procedures
1.16 Define approval procedure


Step 2. Define metrics objectives:
2.1 Define Metrics
2.2 Define Metric points
Step 3. Review/Approve
3.1 Schedule/Conduct Review
3.2 Obtain approval

A tester need to know about Logical and Physical design..

Business requirements are defined during the requirement phase. It is followed by logical design and refines requirement. Logical design is an abstract, conceptual not physical.

Logical design is all about detail system framework and logical architecture is the manner in which logical components of a solution are organized and integrated. The Architectural Design phase, where a software architecture for the implementation of the requirements is designed and specified, identifying the components within the software and the relationships between the components.

Physical Design describes how an information system will be physically implemented in order to meet its logical requirements. This involves specifying the technical (hardware and software) components that will enable the logical design specifications to be implemented.

The logical design phase is verified with static techniques. for example one module may need a particular data created by another module is not provided correctly. Static anlaysis can be applied to detect these types of control flow errors.

Integration test cases is a good approach to test it and determine whether all components interface properly, parameters are passed, and the file processing is correct. It doesnot verify that functionality is correct, only it perfrm as it is designed,

Roll of a Tester in different phase of SDLC

Requirement Phase:
The testing process should begin early stage in application development cycle.

Testers need a solid understanding of the product so they can devise better and more complete test plans, designs, procedures, and cases. Early test-team involvement can eliminate confusion about functional behavior later in the project life cycle. In addition, early involvement allows the test team to learn over time which aspects of the application are the most critical to the end user and which are the highest-risk elements. This knowledge enables testers to focus on the most important critical and high priority part of application.

During the requirement phases of SDLC. the business requirements are defined on high level. During this phase a tester can come up with document testing approach to verify its quality, completeness, and correctness, can point out contradictory requirements.

More systematically, during the requirement phase, a tester can build a Acceptance Test Plan There are some formal approaches and documents which can be created during this phase. Such as:

Inspection/ Walkthrough:

System/Acceptance Test Plan:

Checklist:

Requirement Checklist:

Logical and Physical design..

Business requirment are defined during the requirment phase. It is followd by logical design and refines requirement. Logical design is an abstract, and it is conceptual not physical.

Logical design is al about detail system framework and Logical architecture is the manner in which logical components of a solution are organized and integrated. The Architectural Design phase, where a software architecture for thei mplementation of the requirements is designed and specified, identifying the components within the software and the relationships between the components.

Physical Design describes how an information system will be physically implemented in order to meet its logical requirements. This involves specifying the technical (hardware and software) components that will enable the logical design specifications to be implemented.

The logical design phase is verified with static techniques. for example one module may need a particular data created by another module is not provided correctly. Static anlaysis can be applied to detect these types of control flow errors.

Integration test cases is a good approach to test it and determine whether all components interface properly, parameters are passed, and the file processing is correct. It doesnot verify that functionality is correct, only it perfrm as it is designed,

Traceability matrix

What is it?
 

Traceability matrix can be made more elaborate by tracing the requirements to the design to the code to the test cases. In this way we can come to know which requirement change will affect which part of the design and which part of the code and the test case.Usually this is an excel sheet. Traceability matrix is one which tells the deviation in the current test process with the actual. A   requirement Traceability Matrix is a document that traces user requirements from analysis through implementation. It can be used as a completeness check to verify that all requirements are present or that there are no unnecessary/ extra feature.

At each step in development cycle, the requirements code and associated test cases are recorded to ensure that requirement is addressed in the final system. Both user and developer have ability to easily cross - reference the requirements to the design , programming, test cases.