Explore topic-wise InterviewSolutions in .

• Make the plan concise. Avoid redundancy. If you think you do not need a section that has been mentioned in the template above, go ahead and DELETE that section in your test plan.
• Be SPECIFIC. For example, when you specify an operating system as a property of a test ENVIRONMENT, mention the OS Edition/Version as well, not just the OS Name.
• Make use of lists and tables wherever possible. Avoid lengthy paragraphs.
• Have the test plan reviewed a number of times prior to base lining it or sending it for approval. The quality of your test plan speaks volumes about the quality of the testing you or your team is going to perform.
• Update the plan as and when necessary. An outdated and unused document stinks and is worse than not having the document in the FIRST place.

• Approvals states who can consent a process as complete and ALLOW the project to PROCEED to the next stage.
• This depends on the level of TEST plan and can differ from a test team leader to a more EXECUTIVE employee.
• The type of knowledge at each level of test plan differs SIGNIFICANTLY. For example, programmers may understand the technical side of software but not the managerial or commercial side.

• Scheduling should be based on REALISTIC and validated ESTIMATES for software testing. 
• Milestones should be identified with schedules being specified for each milestone.
• Depending on the LEVEL of test, the size of this section will DIFFER, e.g. Master test PLAN will involve all the test plan schedules below it making it fairly large.
• Dependent/Relative Dating.

• This section identifies all PERSONNEL and the hierarchies relevant to the test plan.
• This includes all areas of the plan such as setting risks, selecting testing and non-testing features, SCHEDULING and most importantly CRITICAL go/no go decisions.

Example: STAFF will require TRAINING on new equipment.

Example: Staff will require training on new equipment.

• This section aims to identify the overall RISKS to the PROJECT with an EMPHASIS on the testing PROCESS. Identified risks are then given possible solutions.
• Think BACK to “Risk Issues”.
• “Backup and Recovery of the EDI transmission files, local databases and restart of the translation process, must be carefully checked.”
• The section should in turn identify how to plan for risks stated earlier in the test plan.

• Environmental Requirements STATES any SPECIAL requirements for this test plan including necessary hardware and software required for testing to proceed.
• Documenting the physical COMPONENTS required for test execution helps to IDENTIFY potential gaps in what is required and what actually exists.

Example: Access to a nightly backup/recovery system.

Example: Access to a nightly backup/recovery system.

This section is used to specify what is to be DELIVERED as PART of this test plan

• NOTE: One thing that is not a test deliverable is the software itself!
• Examples of Deliverables are,
• Test logs
• INCIDENT reports
• OUTPUTS
• Corrective actions taken

This section is used to specify what is to be delivered as part of this test plan

This section identifies the strategy for this test plan, differing DEPENDING on the level of test plan (Unit, Integration, Acceptance).

• The APPROACH stated should be appropriate and in agreement with all higher and lower LEVELS of test plans.
• The level of detail of this section differs depending on the level of test plan. For example, a Unit test plan will go into much detail on individual unit TESTS and test data.
• The bulk of INFORMATION on testing techniques and methodologies will be included in this section.

This section identifies the strategy for this test plan, differing depending on the level of test plan (Unit, Integration, Acceptance).

All risks ASSOCIATED with the software and its testing need to be identified in this section.

Why: Plan for risks and contingencies

• This could include complex functions, NEW VERSIONS of cooperating software, etc...

Test planners should be aware of:

• Vague, unclear or non-testable requirements
• Misunderstanding of requirements

Example: Backup and Recovery of the EDI transmission files, local DATABASES and restart of the translation PROCESS, must be carefully checked.

All risks associated with the software and its testing need to be identified in this section.

Why: Plan for risks and contingencies

Test planners should be aware of:

Example: Backup and Recovery of the EDI transmission files, local databases and restart of the translation process, must be carefully checked.

Identifying the test items is a section that basically specifies the THINGS that are to be tested within the scope of this test plan:

• Functions of the SOFTWARE
• Requirements STATED in the Design stage

The Test Plan should ensure CORRECT NAMES and versions as listed.

Software and hardware needed for testing will also be listed here, along with other test materials and participating organizations. 

Example: EXTOL EDI package, Version 3.0

Identifying the test items is a section that basically specifies the things that are to be tested within the scope of this test plan:

The Test Plan should ensure correct names and versions as listed.

Software and hardware needed for testing will also be listed here, along with other test materials and participating organizations. 

Example: EXTOL EDI package, Version 3.0

We need plan IDENTIFIER for,

• Software Document.
• To ASSIST in coordinating software and TEST ware versions.

Revision numbers are also USED as plan identifier.

EXAMPLE: RS-MTP01.3

We need plan Identifier for,

Revision numbers are also used as plan identifier.

Example: RS-MTP01.3

A test plan DOCUMENT will commence with a unique test plan identifier

• Unique company GENERATED NUMBER.
• IDENTIFIES the Test Plan, its test level and the level of software it’s related to.

A test plan document will commence with a unique test plan identifier

Test Plan covers – What needs to be TESTED, how testing is going to be performed? Resources needed for testing, Timelines and Risk associated. 

For efficient and effective test planning we don’t REALLY need IEEE-829 template for test plan. Planning can be done without test plan document also. IDENTIFY your test Approach (strategy) and go with your testing. Many test plans are being CREATED just for the sake of PROCESSES.

Note – We are not against Test Plan documents. Use test plan documents if they really contains some useful information.

Test Plan covers – What needs to be tested, how testing is going to be performed? Resources needed for testing, Timelines and Risk associated. 

For efficient and effective test planning we don’t really need IEEE-829 template for test plan. Planning can be done without test plan document also. Identify your test Approach (strategy) and go with your testing. Many test plans are being created just for the sake of processes.

Note – We are not against Test Plan documents. Use test plan documents if they really contains some useful information.

PLANS for major types of TESTING like FUNCTIONAL Test Plan, Performance Test Plan and SECURITY Test Plan.

Plans for major types of testing like Functional Test Plan, Performance Test Plan and Security Test Plan.

Plans for each level of testing like

• UNIT TEST Plan
• INTEGRATION Test Plan
• SYSTEM Test Plan
• Acceptance Test Plan

Plans for each level of testing like

A SINGLE high-level TEST PLAN for a project/product that UNIFIES all other test PLANS.

A single high-level test plan for a project/product that unifies all other test plans.

The DIFFERENT test PLAN TYPES are

• Master Test Plan
• TESTING LEVEL Specific Test Plans
• Testing Type Specific Test Plans

The different test plan types are

A test describes the input to a test. This can include the data, the screen that will be used and the parameters that may drive the test. It will describe the steps necessary to execute the test case. It will describe the output and the results that are to be EXPECTED. It may include manipulation of the input data to test the PARTICULAR case. A Test Case WALKTHROUGH is a review of the test case by Testing Peers. It can highlight steps that may have been missed or test cases that may have been missed.

A test describes the input to a test. This can include the data, the screen that will be used and the parameters that may drive the test. It will describe the steps necessary to execute the test case. It will describe the output and the results that are to be expected. It may include manipulation of the input data to test the particular case. A Test Case Walkthrough is a review of the test case by Testing Peers. It can highlight steps that may have been missed or test cases that may have been missed.

The test ware is:

• The subset of software which helps in performing the testing of application. 
• Test ware are REQUIRED to plan, DESIGN, and execute tests. It contains documents, SCRIPTS, inputs, expected results, set-up and additional software or utilities used in testing. 
• Test ware is TERM given to combination of all utilities and application software that required for testing a software package.

Test ware is special because it has:

• Different purpose
• Different metrics for quality and
• Different users

The test ware is:

Test ware is special because it has:

Below mentioned are some of the objectives behind running the TEST cases.

• FIND the defects in software products.
• Verify that the software meets the end user requirements.
• Improve software quality.
• Minimize the maintenance and software support costs.
• Avoid POST deployment RISKS.
• Compliance with processes.
• Help management to make software delivery decisions.

Below mentioned are some of the objectives behind running the test cases.

The TEST strategy INCLUDES introduction, resource, scope and schedule for test ACTIVITIES, test TOOLS, test priorities, test planning and the TYPES of test that has to be performed.

The test strategy includes introduction, resource, scope and schedule for test activities, test tools, test priorities, test planning and the types of test that has to be performed.

A TEST STRATEGY document is a high LEVEL document and normally developed by project manager. This document defines “SOFTWARE Testing Approach” to achieve testing objectives. The Test Strategy is normally derived from the Business Requirement Specification document.

A Test Strategy document is a high level document and normally developed by project manager. This document defines “Software Testing Approach” to achieve testing objectives. The Test Strategy is normally derived from the Business Requirement Specification document.

The LEVEL of TEST Plan defines what the test plan is being created for e.g. SUBSECTIONS of testing:

• Integration
• Unit
• Acceptance
• A Test Plan DOCUMENT will follow the same structure for each level of test plan. The only DIFFERENCE being the content and detail.
• Hierarchy of Test Plans will exist.

The Level of Test Plan defines what the test plan is being created for e.g. subsections of testing:

Components of the test plan DOCUMENT INCLUDE:

• Test Plan id
• INTRODUCTION
• Test items
• FEATURES to be tested
• Features not to be tested
• Test techniques
• Testing tasks
• Suspension criteria
• Features pass or fail criteria
• Test environment (Entry criteria, Exit criteria)
• Test deliverables
• Staff and training NEEDS
• Responsibilities
• Schedule
• Approvals
• Risks and Contingencies

This is a standard approach to prepare test plan and test strategy documents, but things can vary company-to-company.

Components of the test plan document include:

This is a standard approach to prepare test plan and test strategy documents, but things can vary company-to-company.