Test plan is in high demand. Ya it should be! Test plan reflects your
entire project testing schedule and approach. This article is in
response to those who have demanded sample test plan.
In my previous article I have outlined Test plan Index.
In this article I will elaborate that index to what each point mean to
do. So this Test plan will include the purpose of test plan i. e to
prescribe the scope, approach, resources, and schedule of the testing
activities. To identify the items being tested, the features to be
tested, the testing tasks to be performed, the personnel responsible for
each task, and the risks associated with this plan.
Find what actually you need to include in each index point.
I have included link to download PDF format of this test plan template at the end of this post.
Test Plan Template:
(Name of the Product)
Prepared by:
(Names of Preparers)
(Date)
TABLE OF CONTENTS
1.0 INTRODUCTION
2.0 OBJECTIVES AND TASKS
2.1 Objectives
2.2 Tasks
3.0 SCOPE
4.0 Testing Strategy
4.1 Alpha Testing (Unit Testing)
4.2 System and Integration Testing
4.3 Performance and Stress Testing
4.4 User Acceptance Testing
4.5 Batch Testing
4.6 Automated Regression Testing
4.7 Beta Testing
5.0 Hardware Requirements
6.0 Environment Requirements
6.1 Main Frame
6.2 Workstation
7.0 Test Schedule
8.0 Control Procedures
9.0 Features to Be Tested
10.0 Features Not to Be Tested
11.0 Resources/Roles & Responsibilities
12.0 Schedules
13.0 Significantly Impacted Departments (SIDs)
14.0 Dependencies
15.0 Risks/Assumptions
16.0 Tools
17.0 Approvals
1.0 INTRODUCTION
A brief summary of the product being tested. Outline all the functions at a high level.
2.0 OBJECTIVES AND TASKS
2.1 Objectives
Describe the objectives supported by the Master Test Plan, eg.,
defining tasks and responsibilities, vehicle for communication, document
to be used as a service level agreement, etc.
2.2 Tasks
List all tasks identified by this Test Plan, i.e., testing, post-testing, problem reporting, etc.
3.0 SCOPE
General
This section describes what is being tested, such as all the functions
of a specific product, its existing interfaces, integration of all
functions.
Tactics
List here how you will
accomplish the items that you have listed in the “Scope” section. For
example, if you have mentioned that you will be testing the existing
interfaces, what would be the procedures you would follow to notify the
key people to represent their respective areas, as well as allotting
time in their schedule for assisting you in accomplishing your activity?
4.0 TESTING STRATEGY
Describe
the overall approach to testing. For each major group of features or
feature combinations, specify the approach which will ensure that these
feature groups are adequately tested. Specify the major activities,
techniques, and tools which are used to test the designated groups of
features.
The approach should be described in sufficient detail to
permit identification of the major testing tasks and estimation of the
time required to do each one.
4.1 Unit Testing
Definition:
Specify the minimum degree of comprehensiveness desired. Identify the
techniques which will be used to judge the comprehensiveness of the
testing effort (for example, determining which statements have been
executed at least once). Specify any additional completion criteria (for
example, error frequency). The techniques to be used to trace
requirements should be specified.
Participants:
List the names of individuals/departments who would be responsible for Unit Testing.
Methodology:
Describe how unit testing will be conducted. Who will write the test
scripts for the unit testing, what would be the sequence of events of
Unit Testing and how will the testing activity take place?
4.2 System and Integration Testing
Definition:
List what is your understanding of System and Integration Testing for your project.
Participants:
Who will be conducting System and Integration Testing on your project?
List the individuals that will be responsible for this activity.
Methodology:
Describe how System & Integration testing will be conducted. Who
will write the test scripts for the unit testing, what would be sequence
of events of System & Integration Testing, and how will the testing
activity take place?
4.3 Performance and Stress Testing
Definition:
List what is your understanding of Stress Testing for your project.
Participants:
Who will be conducting Stress Testing on your project? List the individuals that will be responsible for this activity.
Methodology:
Describe how Performance & Stress testing will be conducted. Who
will write the test scripts for the testing, what would be sequence of
events of Performance & Stress Testing, and how will the testing
activity take place?
4.4 User Acceptance Testing
Definition:
The purpose of acceptance test is to confirm that the system is ready
for operational use. During acceptance test, end-users (customers) of
the system compare the system to its initial requirements.
Participants:
Who will be responsible for User Acceptance Testing? List the individuals’ names and responsibility.
Methodology:
Describe how the User Acceptance testing will be conducted. Who will
write the test scripts for the testing, what would be sequence of events
of User Acceptance Testing, and how will the testing activity take
place?
4.5 Batch Testing
4.6 Automated Regression Testing
Definition:
Regression testing is the selective retesting of a system or component
to verify that modifications have not caused unintended effects and that
the system or component still works as specified in the requirements.
Participants:
Methodology:
4.7 Beta Testing
Participants:
Methodology:
5.0 HARDWARE REQUIREMENTS
Computers
Modems
6.0 ENVIRONMENT REQUIREMENTS
6.1 Main Frame
Specify both the necessary and
desired properties of the test environment. The specification should
contain the physical characteristics of the facilities, including the
hardware, the communications and system software, the mode of usage (for
example, stand-alone), and any other software or supplies needed to
support the test. Also specify the level of security which must be
provided for the test facility, system software, and proprietary
components such as software, data, and hardware.
Identify special
test tools needed. Identify any other testing needs (for example,
publications or office space). Identify the source of all needs which
are not currently available to your group.
6.2 Workstation
7.0 TEST SCHEDULE
Include test milestones identified in the Software Project Schedule as well as all item transmittal events.
Define
any additional test milestones needed. Estimate the time required to do
each testing task. Specify the schedule for each testing task and test
milestone. For each testing resource (that is, facilities, tools, and
staff), specify its periods of use.
8.0 CONTROL PROCEDURES
Problem Reporting
Document the procedures to follow when an incident is encountered
during the testing process. If a standard form is going to be used,
attach a blank copy as an “Appendix” to the Test Plan. In the event you
are using an automated incident logging system, write those procedures
in this section.
Change Requests
Document the
process of modifications to the software. Identify who will sign off on
the changes and what would be the criteria for including the changes to
the current product. If the changes will affect existing programs,
these modules need to be identified.
9.0 FEATURES TO BE TESTED
Identify all software features and combinations of software features that will be tested.
10.0 FEATURES NOT TO BE TESTED
Identify all features and significant combinations of features which will not be tested and the reasons.
11.0 RESOURCES/ROLES & RESPONSIBILITIES
Specify
the staff members who are involved in the test project and what their
roles are going to be (for example, Mary Brown (User) compile Test Cases
for Acceptance Testing). Identify groups responsible for managing,
designing, preparing, executing, and resolving the test activities as
well as related issues. Also identify groups responsible for providing
the test environment. These groups may include developers, testers,
operations staff, testing services, etc.
12.0 SCHEDULES
Major Deliverables
Identify the deliverable documents. You can list the following documents:
- Test Plan
- Test Cases
- Test Incident Reports
- Test Summary Reports
13.0 SIGNIFICANTLY IMPACTED DEPARTMENTS (SIDs)
Department/Business Area Bus. Manager Tester(s)
14.0 DEPENDENCIES
Identify significant constraints on testing, such as test-item availability, testing-resource availability, and deadlines.
15.0 RISKS/ASSUMPTIONS
Identify
the high-risk assumptions of the test plan. Specify contingency plans
for each (for example, delay in delivery of test items might require
increased night shift scheduling to meet the delivery date).
16.0 TOOLS
List the Automation tools you are going to use. List also the Bug tracking tool here.
17.0 APPROVALS
Specify the names and titles of all persons who must approve this plan. Provide space for the signatures and dates.
Name (In Capital Letters) Signature Date
1.
2.
3.
4.
http://www.softwaretestinghelp.com/test-plan-sample-softwaretesting-and-quality-assurance-templates/
Sumario -> Las precondiciones y postcondiciones contenidos en
los casos de uso que nos llegan con el requerimiento que nos comunica el
área funcional y/o de desarrllo (según el esquema de contratación que
tengamos) para generar los lotes de prueba, constituyen la materia prima
de los casos de prueba que debemos identificar para saber si podemos
reutilizar scripts o bien, diseñar nuevos, sin perder de vista el/los
resultado/s esperado/s.
Detalle -> En ambos casos lo que se representa es un estado y no
la ejecución de una serie de acciones (previas o posteriores al caso de
uso).
Muchos analistas funcionales consideran importante y necesario incluirlos para una mayor claridad de ‘Entendimiento’.
Para nosotros es necesario entender el alcance de estas variables ya
que nos permitirá llevar a cabo la ‘Preparación de los Datos’ que se
usarán en la ejecución de las pruebas considerando las Precondiciones, y
tambien para aquellas donde algunas de los Postcondiciones sean Inputs
(precondiciones) en otros casos de uso y/o casos de prueba.
Toda esta información estará contenida en el documento de ‘Enfoque de
Prueba’, siempre y cuando este tipo de documento haya sido definido
como parte del portfolio de documentos internos y entregables del
proyecto de testing.
Ahora bien, pasemos a ver la forma de gestionar estas variables (pre y pos condición).
Dependiendo del conocimiento, experiencia y presupuesto con el que cuente el grupo de testing, se registrarán en:
1. Templates Word
2. Templates Excel
3. Herramienta Open Source
4. Herrqmienta Arancelada
Estas variables también nos definen complejidad, criticidad y
dependencia/s, tema no menor a la hora de planificar y/o replanificar
‘Regresiones’ con la detección de fallos, ademas de permitir evaluar el
impacto cuando se necesita concretar unn pasaje a ‘Producción’, habiendo
quedado ‘bugs’ por corregir.
Fuente de inspiración: Las precondiciones y postcondiciones en los casos de uso
http://jummp.wordpress.com/2011/07/22/las-precondiciones-y-postcondiciones-en-los-casos-de-uso/
http://testingbaires.com/las-precondiciones-postcondiciones-y-resultado-esperado/
