Topic: Test Plan

A test plan is a systematic approach to testing a system such as a machine or software. The plan typically contains a detailed understanding of what the eventual workflow will be.
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.

There are three steps in Test Plan Development:
Steps:

    * Assembling the Test Team

    * Risk Assessment

    * Establish Test Objectives.

Step I - Assembling the test team

The test team should be organized concurrently with the development team. The purpose of the test team is to perform verification and validation as it relates to implementation. For a specific project, the purpose of the test team is:

    * To perform verification and validation for the deliverables from development and solution delivery

    * To act as consultants to the development team during Unit Testing.

Task I.I - Identify Key Application Areas

This task identifies the key application areas that must be involved in testing. It should also identify the testing group's responsibilities to those areas. For example, testing might be responsible to development for integration testing and system testing, and to solution delivery for release testing.
Output:

Statement of Application Areas

Task I.II - Identify Key Individuals

This task identifies important individuals who will be involved, both directly and indirectly, in the testing process. The persons selected as members of the test team will be directly responsible for testing activities while others that act as sponsors will be indirectly involved.

Specific individuals involved in testing should include the following:

   1. Quality Assurance Manager

   2. Quality Assurance Analysts

   3. Test Manager

   4. Test Analysts

   5. Project Manager

   6. Project Team Leader(s)

   7. Analysts

   8. Programmers

   9. Database Services Personnel

  10. Network Services Personnel

  11. Data Center (Operations) Personnel

  12. Customers (Application Users)

Output:

Statement of team member responsibilities - This statement assigns specific responsibilities to the members of the test team. This should be the first step in the creation of the Test Work plan that is described in Task I.III. The work plan should be developed in Microsoft Project or in the management component of an automated test tool.

The first action is to list the testing tasks to be completed. This should be followed by a review of the tasks by all of the test team members. When consensus has be reached that the list is correct and complete, an individual team member must be assigned to each task. A final review based on each member's % of the workload should be completed. MS Project makes this easy as it has several reports that will provide workload, as well as, other statistics.

Task I.III - Assign Individual Responsibilities

The test team members will be responsible for:

   1. Developing the test Plan

   2. Developing the required test resources

   3. Designing the test cases

   4. Constructing test cases

   5. Executing test cases according to the test plan

   6. Managing test resources

   7. Analyzing Test results

   8. Issuing test reports

   9. Recommending application improvements

  10. Network Services Personnel

  11. Data Center (Operations) Personnel

  12. Maintaining Test statistics

Individual assignments must be made so that each area of responsibility is covered and someone can be held accountable.

Output:

Team Work Plan - The work plan defines milestones and tentative completion dates for all assigned tasks. A project management tools such as Microsoft Project can make this task very easy and the resulting document
is a Gantt Chart that illustrates who is responsible for what and when.

The purpose of business risk analysis during software testing is to identify high-risk application components that must be tested more thoroughly, and to identify error-prone components within specific applications, which must be tested more rigorously. The results of the analysis can be used to determine the testing objectives (see Step III) during test planning.

The key to performing a successful risk analysis is to formalize the process. An informal approach to risk analysis methods leads to an ineffective analysis process.

There are four main 'risk analysis' methods which testers can employ. Each method applies a different level of formality to the risk assessment procedure.

The first is Judgment and Instinct. This is the most common approach to performing risk assessment during testing. It is an informal approach using the tester's Knowledge, and experience with past projects, to estimate the amount of testing required for the current project. This can be an effective method, but the fact that the tester's experience is not readily transferable to other testers is its primary fault. In terms of the SEI Maturity model, this risk assessment process would be somewhere between levels 1 and 2. It is a repeatable approach, but is not formally written down for others to use.

The second method is Dollar Estimation. This approach quantifies business risk using dollars as its unit of measure. It requires a great deal of precision and is difficult to use because results are based on estimates of frequency of occurrence and the loss per occurrence. Thus, the precision is not always there.
The third approach is Identifying and Weighting Risk Attributes. This approach identifies the attributes that that cause a risk to occur. The relationship of the attributes to the risk is determined by weighting. The tester uses weighted numerical scores to determine what the high risk areas are. The scores can be used to decide what application components should be tested more thoroughly than others, and total weighted scores can be used to compare one application to another.

The fourth approach is The Software Risk Assessment Package. This is an automated approach that involves purchasing an assessment package from a vendor. The advantage is the ease of use and the ability to do What-If-Analysis with risk characteristics. Automated risk assessment software packages exist which use the second and third approaches above, however, testers can create their own risk assessment questionnaires with MS Word and do the what-if-analysis with MS Excel.

Any of these approaches could be used for testing projects, however, the third approach, Identifying and Weighting Risk Factors, is the most practical and applies a reasonable level of formality. It also produces the most accurate estimate of risk. This approach identifies and weights risk factors along three project dimensions.
Risk Dimensions

The risk dimensions are identified as Project Structure, Project Size, and Experience with Technology.

With respect to project structure, the more structured a project the less the risks. Thus, software development projects that employ some type of project management / development life cycle approach should be at less risk.

Project size is directly proportional to risk. The larger the project in terms of cost, staff, time, number of functional areas involved, etc., the greater the risk.

Technology experience is inversely proportional to project risk. The more experience the development team has with the hardware, the operation system, the database, the network, and the development language the less the risk.





Edited by Mithi25 - 08Jul2009 at 1:19am