LogiGear Test Plan Template

snortfearServers

Dec 4, 2013 (3 years and 11 months ago)

103 views

LogiGear Test Plan Template

LG
-
WI
-
TPT
-
HQN
-
0
-
01
-
080500


Date

Copyright © 2003
, LogiGear Corporation

All Rights Reserved


W.650.572.1400

F.650.572.2822

E
-
mail:
info@logigear.com


www.logigear.com


Product Name

Test Plan

Author Name Version 1.0

I. Overview

1. Test Plan Identifier

[LG]
-
[client’s init]
-
[project’s init]
-
[author’s init]
-
[phase#][serial#]
-
[dist. date]

Example:

LG
-
WI
-
TPT
-
HQN
-
0
-
01
-
080500


LG

LogiGear
Corporation

WI

Widget Inc.

TPT

Test Plan Template project

HQN

Hung Q. Nguyen

0

0 = Development Phase; 1 = Final Phase

01

The first distributed draft

080500

Distributed date: August 5, 2002

2. Introduction

An introduction of the overall project.

3.
Objective

What we strive to accomplish, taking the following factors into account: quality, schedule,
and cost.

4. Approach

The overall testing strategy to satisfy the testing objectives.

II. Testing Synopsis

1. Test Items

Deliverable products or applicati
ons to be tested.

1.1. Software Application Items

1.1.1. Main Application Executables

1.1.2. Installer/Uninstaller

1.1.3. Utilities/Tool Kits

1.1.4. Online Help

1.2. Software Collateral Items

1.2.1. Font

1.2.2. Clip Art

1.2.3. Related Multimedia Items

1.2.
4. Sample/Tutorial

1.2.5. Readme

1.2.6. Others

1.3. Publishing Items

1.3.1. Reference/User Guide

1.3.2. CD/Disk Label

1.3.3. Packaging

1.3.4. Marketing/Product Fact Sheet/Advertising Blurb

2. Features to Be Tested

List of features to be tested. The list ma
y include the environment to be tested under.

3. Features Not to Be Tested

List of features that will not be covered in this test plan.

4. System Requirements

SERVER HARDWARE AND SOFTWARE CONFIGURATION REQUIREMENTS




Pentium PC (Pentium II or higher recomme
nded)



128 Mb RAM



100 Mb of free disk space



Windows 2000 Server



Microsoft Internet Information Server 4.0 or higher



Microsoft SQL Server 7.0 with Service Pack

CLIENT REQUIREMENTS




An active LAN or Internet connection



Microsoft Internet Explorer 4.x or highe
r



Netscape Navigator 4.x

MICROSOFT INTERNET INFORMATION SERVER




Microsoft IIS 5 is bundled as part of the Windows 2000 Server and Windows 2000
Advanced Server Operating Systems.



Microsoft IIS 4 is available, free of charge, as part of the Windows NT 4.0 Op
tion Pack.

DATABASE SUPPORT




Microsoft SQL Server 7.0

SUPPORTED BROWSERS




Supports clients using Microsoft Internet Explorer 4.x or higher, or Netscape Navigator
4.x on any hardware platform.

[The software and hardware requirements to run the application.
Normally, this
information is found in the product specification or user manual. See the preceding
example.]

5. Product Entrance/Exit

Describe the milestone/acceptance criteria.

6. Standard/Reference



IEEE Standard for Software Test Documentation (ANSI/IEEE

std 829
-
1983)



Cem Kaner et al.
Testing Computer Software
, 2nd ed. New York: John Wiley, & Sons,
Inc., 1993



LogiGear Corporation Test Plan Template



XXXX 3.0 Test Matrix

[List of any standards, references used in the creation of this test plan. See the
prec
eding example.]

7. Test Deliverables

List of test materials developed by the test group during the test cycle to be delivered upon
the completion of this project.

7.1. Test Plan

7.1.1. The Original Approved Development Test Plan

Essentially, this complete
document with appropriate approvals.

7.1.2. The Executed Development Test Plan

Test
-
case tables, matrices, and other test
-
related materials (as part of this test plan) with
appropriate check
-
marking as verification of test completion.

7.1.3. The Original A
pproved Final Test Plan

Usually, the final test plan is a scaled
-
down version of the development test plan. This plan
is produced and used in the final testing cycle. Appropriate approvals should also be
included.

7.1.4. The Executed Final Test Plan

Test
-
c
ase tables, matrices, and other test
-
related materials (as part of the final test plan)
with appropriate check
-
marking as verification of test completion.

7.2. Bug
-
Tracking System

7.2.1. Bug Reports



Summary list of all bugs found



Full description copies of

all bugs found

7.2.2. Bug Database

A soft copy of the bugbase containing all bugs found during the testing cycles, including
paper
-
form reports.

7.3. Final Release Report

The Final Release Report should be submitted prior to the release of this project. T
his report
is a quality assessment document that describes the scope of the testing project, testing
completeness, test results focused primarily on the areas of concern, and release
recommendation (for or against).

III. Testing Project Management

1. The P
roduct Team

List of product team members and their roles.

2. Testing Responsibilities

Who will lead up the testing efforts? Other people resources and responsibilities.

3. Testing Tasks



Develop test plans, including test cases, matrices, schedule, and so o
n.



Conduct test
-
plan reviews and obtain appropriate approvals.



Procure hardware/software/tools required.



Create bug database.



Perform tests.



Report bugs.



Conduct bug deferral meeting.



Produce weekly status report.



Produce final release report.

4. Developme
nt Plan and Schedule

What is to be delivered for testing? Schedule: when the preceding items will be delivered.

5. Milestone Entrance/Exit Criteria

Milestone definitions, descriptions, and measurable criteria.

6. Test Schedule and Resource

6.1. Schedule

Te
sting task grouping: list of task groups and their descriptions. Preliminary schedule
matched with resource needs and test tasks.

6.2. Resource Estimate

Estimates of people resources required for completing the project.

7. Training Needs

Identify training
needs.

8. Environmental Needs

8.1. Test Components

List of all software and hardware resources needed to complete the project. Resources
availability and strategies to acquire them.



Hardware



Software



Online account

8.2. Test Tools



Off
-
the
-
shelf tools



In
-
ho
use tools



Tools to be developed

8.3. Facilities

All testing will be done at [Company Name’s] lab. If there is need to outsource some of the
testing tasks, we’ll update this plan accordingly.

9. Integration Plan

Is there an integration plan? If yes, how it
would fit in the testing strategy?

10. Test Suspension and Resumption

When should testing be suspended? When should a suspended testing process be
resumed?

11. Test Completion Criteria

When should testing stop?

12. The Problem
-
Tracking Process

12.1. The Pr
ocess

Describe the bug
-
tracking process.

12.2. The Bug
-
Tracking Tool (database)

Describe the bug
-
tracking tool.

12.3. Definition of Bug Severity

Bug severity is a subjective method used by reporters to grade the severity level of each
report. Following are

guidelines for grading bug severity.

12.3.1.1

Critical

Severity 1

Critical

(show
-
stopper)
bugs

are those that result in loss of key functionality,
usability, and performance of a product in normal operation; there is no workaround solution
available. Thes
e also include nonprogrammatic bugs such as an obviously embarrassing
misspelling of a product or company name in the splash screen, wrong video clip in the intro
screen, erroneous instructions for a frequently used feature, and so on. Following are a few
sample categories:



Crash or core dump



Data loss or corruption



Failure of key feature

12.3.2.2

Serious

Severity 2

Serious bugs

include key features that don’t function under certain conditions or
nonkey features that don’t function at all, degradation of fu
nctionality or performance in
normal operation, difficult
-
to
-
use key features, and so on. Usually, these bugs should be
fixed during the normal development cycles. Only during the final testing phase, these bugs
might be carefully assessed and perhaps cons
idered defer as appropriate.

12.3.3.3

Noncritical

Severity 3

Noncritical bugs

are those that represent some inconvenience to the user but
perhaps don’t happen frequently. These include minor display/ redraw problems, poorly
worded error messages, minor des
ign issues, and the like. Usually, these bugs should be
fixed provided time permitting or minimum efforts required by the programming team. Keep
in mind that if many Severity 3 noncritical bugs get deferred; there will be a definite quality
-

degradation ef
fect to the product.

13. Status Tracking and Reporting



In what form will the status be reported?



What is the reporting frequency?



What types of information will be reported?

14. Risks and Contingencies

Risks and possible adjustments to the plan.

15. The Ap
proval Process

15.1. Test Plan Approval

How is the test plan approved?

15.2. Final Release Approval

What is the approval process for releasing the tested product?