What is a template for a test plan?

Testing is responsible for checking the quality level of a program and effective testing requires an effective and efficient test plan.

HOW SHOULD A TEST PLAN BE?
- The test plan should be practical so that it can be easily implemented.
- A test plan is prepared keeping in view the test approach which is suitable for a particular kind of software testing.
- The other important things that are kept in mind while drawing out the test plan are functional specs, design specs and requirements.
- The test plan is a way of implementing the test approach.
- It makes use of test cases specifically designed for a kind of particular testing.

DOCUMENTATION OF TEST PLAN
The test plan is also documented and the documentation serves the following purposes:

1. It gives the details about the test approach used to test the software system or application.
2. The different aspects of a software system or application are identified.
3. The procedure to be followed for the testing is specified.
4. The tools to be used in the software testing are also mentioned in the documentation.
5. The resources to be used in the testing of the software product are specified.
6. The scheduling plan for the test plan is listed.
7. Sometimes it may also include the contact information of the people who are involved in the whole testing process.
8. It lists all the risks that may affect the software and also mentions their effect on the software.
9. The contingency plan is also included.
10.The test plan also specifies the bugs and errors and procedures to manage them.
11.The criterion for the development of the software is specified.

The scheduling plan or the test schedule is prepared by the lead tester. It is based up on the project schedule prepared by the product manager. A test plan template is like a sample on which you can build up your own test plan.

BASIC TEST SAMPLE
1. Introduction
The introduction part covers up the description of the documentation, schedules and other related documents.
(a) Description:
- This documentation contains a test plan for the project: “project name” which has been produced by both quality control and quality assurance.
- The test plan enlists and describes the test strategy and also the test approach.
- Quality assurance has been used for validating the quality of this software product prior to its release.
- Apart from software product, there are other resources which are required for successful execution of this software project.
- The “ project name” aims at improving the development strategy, maintenance and deployment by providing the following new features:

(b) Schedule: (schedule coverage and information based on the estimates of the quality assurance.)
(c) Related documents: (related documents attached to the documentation like design specifications list and functional and non functional specifications list.)

2. Resource Requirements:
It describes all the hardware and software components of the software product.
(a) Hardware:(hardware requirements of the project)
(b) Software:(software requirements of the project and tools used in the testing of the software)
(c) Staffing:(list of the names of the people who are involved in the project along with their responsibilities and what all trainings are required.)

3. Aspects to be tested and test approach: (provides the list of the aspects tested).
4. Aspects not to be tested.
5. Test outcomes
6. Risks
7. Exit criteria

What are different types of design patterns?

The Composite View Design Pattern
- The context of composite view pattern is that it allows the development of the view more manageable through the creation of a template to handle common page elements for a view.
- The problem comes in modifying and managing the layout of multiple views.
- The solution is to use this pattern when a view is composed of multiple atomic sub-views. Each component of the template may be included into the whole and the layout of the page may be managed independently of the content.
- A benefit of using this pattern is that interface designer can prototype the layout of the page, plugging in static content on each component.
- The drawback is that there is a runtime overhead associated with it.

The Front Controller Design Pattern
- It provides a centralized controller for managing requests.
- The problem is that the system needs a centralized access point for presentation-tier request handling to support the integration of system data retrieval, view management, and navigation.
- The solution to the above problem is that a controller is used as an initial point of contact for handling a request. It centralizes decision-making controls.

Data Access Object Design Pattern
- It separates resource's client interface from its data access mechanisms.It allows data access mechanism to change independently of the code that uses the data.
- The problem is that data will be coming from different persistent storage mechanism and access mechanism varies based on the type of storage.
- The solution to the above problem is to use the Data Access Object to abstract and encapsulate all access to the data source. It implements the access mechanism required to work with the data source.

Data Flow Diagram - Some template locations

There are numerous locations on the internet where data flow templates can be found. Here are a few of the sites where you can find and use DFD templates.

Flowcharttools (depiction of what a template should look like) - Click here

Sample of what a Data Flow Diagram looks like (click here)

Sample DFD at docstoc (click here)

Samples at Gene Sarson (click here)

Templates at smartdraw (click here)

Example of DFD at conceptdraw (click here)

Visio and Word templates for DFD (click here)

Flowchart samples at edrawsoft (click here)

Software test plan and templates

Now that previous posts have discussed to some details about the need for the test plan, let's talk a bit about what the test plan covers:

Test plans, also called test protocol, are formal documents that typically outline requirements, activities, resources, documentation and schedules to be completed.

A sample of what a test plan (a template) is available at the following location: sqatester.com. The actual word document template is available at this link.

A lot of details about what a test plan covers, including the contents of the test plan, references (documents that support the test plan including project plan, SRS, design documents (HLD, LLD)), issues and risks, features included for testing in the test plan and to be excluded from the test plan, and overall approach are all included in the Wikipedia page. This is a good reference page to read if you want to get a lot of detail about what a test plan should cover.

For a shorter reading of what a test plan should cover, refer to this paragraph below where the test plan is broken down into 3 main sections:
1. Beginning of the plan: This contains background information such as header information, title, author, date, project number/code, project description, references to related documents, an explanation of the test objectives, definition, key words.
2. Middle section of the plan: This section starts to contain some meat about the plan, including a data collection / sampling plan, test environment including setup, resources to be used, assumptions that need to be made, customer specific needs, and how to report test-related problems such as failures.
3. Ending section of the plan: This section typically contains analysis information, statistical techniques, what was the original testing need, a definition for test success or failure, how to conduct data analysis, what to do in case testing results in insufficient information, how to present the final information, references.