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.

Software test plan - process

What are the various testing types that a software test plan can be used for ?
The Test Plan is used to perform system testing, subsystem testing, assembly testing, subassembly testing, module testing, user acceptance testing. The Test Plan includes step by step instructions for the various types of testing that will occur during the project lifecycle; it also defines the required test equipment, calibration requirements, test facility requirements, and other key factors.

A formal test plan is a document that provides and records important information about a test project, for example:

* project and quality assumptions
* project background information
* resources
* schedule & timeline
* entry and exit criteria
* test milestones
* tests to be performed
* use cases and/or test cases

Creating a software test plan - Need

Anybody who has worked in the field of software development would have heard of a software test plan. How many of you have actually understood the need for a software test plan?

Some of the reasons for making a comprehensive test plan are:

* Preparation: To assure that all reasonable aspects of running a test have been considered including getting test data in place, getting the required hardware and software.
* Communication and Training: To train those who need to assist with the test and to enable them to understand the overall perspective.
* Effectiveness: To provide a mechanism for outlining test needs, limitations (listing assumptions), and justification for purposes of setting expectations, acquiring resources, investigating unexpected results, assuring normalcy and effectiveness.
* Legal and Regulatory Prudence: To enable replication and protection of discoveries made, to mitigate potential litigation costs from use of those discoveries, and to help provide evidence to show regulatory bodies of efficacy. A test plan is an important of various software quality process such as ISO and CMM, and helps provide internal or external customers with the confidence that the testing activity is being well planned
* Improve testing coverage and efficiency. Without some form of test plans and scripts available, the testing effort typically degenerates into an ad-hoc effort where no one knows what their colleagues are testing and management can never say for sure that the application has been tested sufficiently.
* Test plans are useful tools to organize, manage and schedule the testing effort. Since the complexity of software and Web applications continues to grow, a well thought-out test plan can greatly facilitate the testing work.

So what is a test plan?
The Test Plan describes the overall approach to development, integration, qualification, and acceptance testing. It describes plans for testing software systems; test environment to be used for the testing; identifies tests to be
performed, and provides schedules for test activities. The process of preparing a test plan is a useful way to think through the efforts needed to validate the acceptability of a software product. The completed document will help people outside the test group understand the 'why' and 'how' of product validation. It should be thorough enough to be useful but not so thorough that no one outside the test group will read it.

Details of a test plan:
In software testing, a test plan gives detailed testing information regarding an upcoming testing effort, including

* Scope of testing
* Schedule
* Test Deliverables
* Release Criteria
* Risks and Contingencies

Validation and verification explained

There is typically a lot of confusion about what the terms of validation and verification mean with respect to software testing. Both of these are valid terms, used in the context of software testing, but mean different things. If you are looking for a one-line definition of both:

Verification is about building the product right.
Validation is about building the right product.

Together, these 2 activities ensure that the testing process is complete and the software product that is built is correct and meets all the user requirements. Some more details of these terms:

Verification:
- Ensure that the process being used is correct and is being followed. The review of interim work steps and interim deliverables during a project to ensure they are acceptable. To determine if the system is consistent, adheres to standards, uses reliable techniques and prudent practices, and performs the selected functions in the correct manner.
- Low level activity.
- Performed during development on key artifacts, like walkthroughs, reviews and inspections, mentor feedback, training, checklists and standards.

Validation:
- To ensure that the product meets all the specifications and requirements. Determining if the system complies with the requirements and performs functions for which it is intended and meets the organization’s goals and user needs. It is traditional and is performed at the end of the project.
- High level activity
- Determination of correctness of the final software product by a development project with respect to the user needs and requirements

Need for software testing

When you talk about the process of software development, one of the major parts (and a full science by itself) is the process of software testing. One cannot talk about software development without talking about software testing.
Let us first talk about the process of software development. Software development is the process of developing a software application, built to order on the basis of a set of requirements. These requirements could be from a client (where the software is built on the requirements particular to the client), or could be based on a mix of market needs and competitor analysis when a shrink-wrapped software product is being built.
An integral part of the software development process is the software testing process. The scope and details of the software development practice is huge by itself, covering by itself a number of different processes. And what does this software testing process do ? There is the need for a process to ensure that the requirements against which the software is being built is adhering to the requirements as much as possible. In more technical words, the process of testing ensures that a process of validation and verification is being carried out during the entire development process. In less technical words, software testing ensures that somebody is checking that the development process is happening in the right way, that the application is matching the needs of the client.
Testing follows a process to ensure that the process is effective, with the preparation for testing entailing preparation of a test plan and detailed test cases. And there are many additional processes that form a part of software testing, such as test automation, white box testing, black box testing, etc. The usage of specific testing processes during a software development project depends on the kind of project it is. For example, in a project where there is no exposure of details of the code to the testing team, there is no question of white box testing, and so on.

Prototyping process

How to go about prototyping:

1. Identify the base set of requirements

2. Develop the initial prototype

3. Get the prototype reviewed by end-users and customers

4. Based on this review and other work, revise the prototype until it has broad agreement with the customers and end-users



2 main types of prototypes:

1. Evolutionary prototypes: The objective of evolutionary prototyping is to deliver a working system to end-users. Used for systems where the specification cannot be developed in advance such as user interface systems and where verification is impossible because there is no specification.

2. Throw-away prototypes: The objective of throw-away prototyping is to validate or derive the system requirements. Throwaway or Rapid Prototyping refers to the creation of a model that will eventually be discarded rather than becoming part of the finally delivered software. After preliminary requirements gathering is accomplished, a simple working model of the system is constructed to visually show the users what their requirements may look like when they are implemented into a finished system.