Software Test Plan (STP) Template

Items that are intended to stay in as part of your document are in bold;
explanatory comments are in italic text. Plain text is used where you
might insert wording about your project.
This document is an annotated outline for a Software Test Plan,
adapted from the IEEE Standard for Software Test ocumentation !Std
"#$%&$$"'.
Tailor as appropriate. (here you decide to omit a section, you might
)eep the header, but insert a comment saying why you omit the
element.


Luz y Vida en las Naciones
Sistema de Gestin Acadmica
Centro Luz y Vida
Software Quality Assurance Plan

Versin !"# $ate !%&'()'(%"*#

Document History and Distribution
"+ ,e-ision .istory
Revision # Revision Date Description of Change Author
(+ $istri/ution
Recipient Name Recipient Organization Distribution Method

0A1L2 34 C3N02N0S

"+ 5N0,3$6CC57N.................................................................................................................................................1
(+ 02S0 5028S........................................................................................................................................................3
9+ 42A06,2S 03 12 02S02$................................................................................................................................4
*+ 42A06,2S N30 03 12 02S02$.....................................................................................................................4
&+ APP,3AC.............................................................................................................................................................4
:+ PASS ' 4A5L C,502,5A........................................................................................................................................6
)+ 02S05NG P,3C2SS.............................................................................................................................................
;+ 2NV5,3N82N0AL ,2Q65,282N0S................................................................................................................
<+ C.ANG2 8ANAG282N0 P,3C2$6,2S.......................................................................................................!
"%+ PLAN APP,3VALS............................................................................................................................................."
"+ 5N0,3$6CC57N
El plan de pruebas de software !STP' est* dise+ado para prescribir el alcance, el enfo,ue,
los recursos y los horarios de todas las acti-idades de prueba. Este plan identificar* los
elementos a ensayar, las caracter.sticas para ser e-aluadas, los tipos de pruebas a reali/ar, el
personal responsable de las pruebas, los recursos y el horario necesario para completar las
pruebas y los riesgos asociados con el plan.
0as t1cnicas para encontrar problemas en un programa son extensamente -ariadas y -an desde el
uso del ingenio por parte del personal de prueba hasta herramientas automati/adas ,ue ayudan a
ali-iar el peso y el costo de tiempo de esta acti-idad.
0a prueba es el proceso de ejecuci2n de un programa con la intenci2n de descubrir un error. 3n
buen caso de prueba es a,uel ,ue tiene una alta probabilidad de mostrar un error no descubierto
hasta entonces. 3na prueba tiene 1xito si descubre un error no detectado hasta entonces.
0a prueba es entonces, un proceso de an*lisis de software ,ue sir-e para detectar las
diferencias entre las condiciones existentes y las condiciones re,ueridas. Es un elemento cr.tico
,ue nos ayudara a garanti/ar la calidad del software dise+ado y ser-ir* como una re-isi2n final de
las especificaciones del dise+o y codificaci2n.
"+" 3/=eti-os
El objeti-o principal de este documento es especificar ,u1 elementos o
componentes se -an a probar. 4s., gracias a este documento se podr* reali/ar el
proceso de -alidaci2n y -erificaci2n de los re,uerimientos funcionales y no
funcionales del proyecto.
5tra idea fundamental del documento de pruebas es identificar informaci2n sobre
los errores# defectos o fallas ,ue pueda tener el sistema ,ue permita reali/ar
correcciones pertinentes para asegurar la calidad del producto ,ue se est*
entregando al cliente.
1.1.1 $b%eti&os del Sistema
Identificar, describir y desarrollar los casos de pruebas para el Sistema de
6esti2n 4cad1mica 78entro 0u/ y 9ida:.
Estructurar y documentar la planificaci2n de las pruebas de aceptaci2n del
sistema a reali/ar, as. como la estrategia a utili/ar para su ejecuci2n.
etectar un error del software antes de su explotaci2n para e-itar
futuros problemas durante su ejecuci2n.
Plantear estrategias y criterios adecuados, para tener una mayor
probabilidad de mostrar un error no descubierto.
0ista los elementos entregables de las acti-idades de prueba.
1.1.2 'cti&idades de Prueba
Este documento presenta el plan de pruebas a utili/ar en el proyecto. 0as pruebas
a implantar son b*sicas en el sistema. 4 continuaci2n presentamos una lista las de
las pruebas m*s importantes a reali/arse en el documento con una bre-e
descripci2n de cada una;
Pruebas 3nitarias; Se validaran las piezas individuales del software como
una unidad independiente, bucles, condicionales, etc.
Pruebas de Integraci2n; Se validara la integracin entre los diferentes
mdulos que componen la solucin.
Pruebas de Sistema; Se realizaran en base a los requerimientos no
funcionales del sistema.
Pruebas de Interface: Para verificar que la interfaz del componente se
realiza correctamente.
Pruebas de Implantacin: 0a finalidad de las pruebas de implantaci2n son
comprobar el funcionamiento correcto del sistema en el entorno de operaci2n y
permitir ,ue el usuario determine, desde el punto de -ista de operaci2n, la
aceptaci2n del sistema instalado en su entorno real, seg<n el cumplimiento de
los re,uisitos especificados.
Pruebas de 4ceptaci2n; 9erificaciones ,ue -an dirigidas a -alidar ,ue el
sistema cumple los re,uisitos de funcionamiento esperado.
Existen di-ersos tipos de pruebas ya sean funcionales o no funcionales. En la
secci2n = de este documento mencionaremos algunas pruebas m*s y
profundi/aremos sobre las expuestas anteriormente.
1.1.3 Hitos y (ntre)as
El principal producto de trabajo, es el plan de pruebas de software y los resultados
de las pruebas aplicables al desarrollo nuestro sistema.
0os hitos de este plan de pruebas son;
esarrollar casos de prueba.
Ejecutar pruebas.
Informe de defectos.
Informe de prueba completo.
.
1.1.4 *ecursos
En la siguiente tabla se muestran los elementos base de software ,ue son
re,ueridos en el ambiente de pruebas para este Plan.
(lemento de
Software
+ersi,n Descripci,n
>a-a 9irtual
?achine !>@'
A o mayor Es la aplicaci2n donde corren los
programas hechos en >a-a, es nati-a
del sistema operati-o
>a-a Bun
En-ironment !>BE'
&.= o mayor Es un n<cleo y motor ,ue funciona
como )ernel para el 0enguaje >494.
Ser-idor de Case de
atos 5racle
5racle Express
&& DE.
El ser-idor de Case de atos. 0a
diferencia entre las -ersiones de 5racle
no legaran a afectar el rendimiento del
sistema
Sistema 5perati-o (indows E
(indows DP
El Sistema 5perati-os del sistema.
Fuestro sistema est* enfocado a estos
# sistemas operati-os actualmente
manejados en la instituci2n objeti-o.
Sin Embargo no se descarta la
funcionalidad en otras plataformas,
0inux especialmente, al estar
desarrollado en >a-a.
Tabla 1 *ecursos y re-uerimientos del sistema
1.1.5 Pro)rama .aestro de 'lto /i&el (0alendario)
escribimos el programa maestro de alto ni-el para este plan de pruebas con
las acti-idades y duraci2n por acti-idad en la siguiente tabla;
'cti&idad Duraci,n
esarrollo del ocumento de Plan de
Pruebas
el #G de ?ayo de #H&G hasta el #& de
?ayo de #H&G.
Elaboraci2n de casos de prueba el #H de ?ayo de #H&G al #E de ?ayo de
#H&G
Entrega del ocumento de Plan de Pruebas #" de ?ayo de #H&G
Tabla 1 Pro)rama .aestro de 'lto /i&el
1.1.6 Presupuesto
El presupuesto de la elaboraci2n de pruebas, desarrollo y ejecuci2n no est*
contemplado en la elaboraci2n de este documento al ser un caso de
implementaci2n real. El apoyo la instituci2n 70u/ y 9ida:, y el presupuesto
brindado ser* para modificar las instalaciones y actuali/ar los e,uipos actualmente
utili/ados. El plan de pruebas no se considera un presupuesto extra en este sentido.
Por su parte se cuenta con el apoyo y permiso para reali/ar las pruebas del
software con los recursos de la instituci2n.
"+( 2strate>ia de Prue/as
0a prueba es el proceso de an*lisis de un elemento de software para detectar las
diferencias entre las condiciones existentes y las condiciones re,ueridas y para
e-aluar las caracter.sticas del elemento software. En la secci2n = del documento se
-er*n a detalle los planes de pruebas espec.ficos.
0as estrategias de Prueba permiten identificar las 8aracter.sticas de 8alidad ,ue
deben ser e-aluadas en un software; Iiabilidad, 3sabilidad, Eficiencia,
?antenibilidad, Portabilidad, etc
0as estrategias de Pruebas integran las t1cnicas de dise+o de casos de prueba en
una serie de pasos bien planificados ,ue dan como resultado una correcta
construcci2n del software.
El siguiente grafico muestra las estrategias de pruebas y su a-ance en el sistema;
2lustraci,n 1 (strate)ias de Prueba 3uente4
5ttp466fc-i.ti%.uabc.m76usuarios6luis)mo6data6!.3819prb:cal:mant.pdf
4 lo largo del documento implementaremos como estrategia de prueba la prueba
de casos de uso, la prueba de unidad y la prueba de integraci2n principalmente;
1.2.1 0asos de ;so4 A partir del escenario de caso de uso crearemos los Casos de
Prueba, que son la descripcin de las actividades que se van a ejecutar con el fin
de validar la aplicacin (Casos de Uso vs. Casos de Prueba:
http:testeandosoft!are.comcasos"de"uso"vs"casos"de"prueba#
3n caso de uso representa la interacci2n !o conductas obser-adas' asociados con
el logro o el abandono de una meta. 3n escenario de caso de uso representa uno
de los posibles caminos a tra-1s de un caso de uso. 3n caso de prueba representa
un conjunto de entradas de datos !acti-idades' ,ue ejecutan un solo escenario de
caso de uso para obtener unos datos de salida esperados !resultados', es decir,
cada uno tiene un objeti-o concreto.
3n procedimiento de prueba es una especificaci2n de c2mo lle-ar a cabo la
preparaci2n, ejecuci2n, y e-aluaci2n de los resultados de un caso de prueba
particular.
1.2.2 Prueba de unidad4 Se la toma en cuenta debido a ,ue centra el proceso de
-erificaci2n en la menor unidad del dise+o del software; el m2dulo. Se ejercitan
todos los caminos independientes de la estructura de control para asegurar ,ue
todas las sentencias del m2dulo se ejecuten por lo menos una -e/.
3sando la descripci2n del dise+o detallado como gu.a, se probar*n los
caminos de control importantes, con el fin de descubrir errores dentro del m2dulo.
Tambi1n se probar* la interfa/ para asegurar ,ue la informaci2n fluye de forma
adecuada hacia y desde la unidad del programa ,ue est* siendo probada.
Se examinar* las estructuras de datos locales para asegurar ,ue los datos, ,ue se
mantienen temporalmente, conser-an su integridad durante la ejecuci2n del
sistema.
1.2.3 Pruebas de 2nte)raci,n4 0a prueba de integraci2n detecta errores de
interacci2n. El procedimiento adecuado se llama integraci2n incremental con el
cual se construye y se prueba en pe,ue+os segmentos en los ,ue los errores son
m*s f*ciles de aislar y corregir. Fuestro Sistema especialmente cuenta con -arios
m2dulos pe,ue+os ,ue deben adaptarse entre y usar la informaci2n. Se puede
acceder de distintas formas a cada m2dulo para ,ue la experiencia del usuario se
r*pida y eficiente. Esta prueba tiene gran importancia en el sistema.
"+9 Alcance
Este Plan de Pruebas aplica a todos los componentes necesarios para registrar,
modificar la proforma presupuestaria y registrar las transacciones presupuestarias
durante el proceso de ejecuci2n presupuestaria. Pretende dar una -isi2n general
sobre las acti-idades a reali/ar; sobre las pruebas consideradas; adem*s de una
explicaci2n global ,ue se consider2 para la reali/aci2n de los documentos a
entregar, ya ,ue dar*n una mayor informaci2n relacionada a la e-aluaci2n y
reportes de este tipo de pruebas.
0as pruebas, se reali/aran tanto a los re,uerimientos funcionales, y a los no%
funcionales !facilidad de uso, eficiencia, etc.'. 8on esto se pretende lograr los
siguientes puntos.
8orrecci2n; Eliminar la ambigJedad en los re,uerimientos y componentes
8ompletitud; Especificaci2n completa y clara del problema. Kue el sistema
y los componentes puedan abarcar todos los re,uerimientos del sistema
8onsistencia; Kue no haya re,uisitos contradictorios.
0os tipos de prueba a reali/arse se nombran en la secci2n 7&.# % Estrategia de
Pruebas: en este documento.
0uego de finali/ar las pruebas de re,uerimientos funcionales y no funcionales o
7pruebas del sistema:, el programa se debe encontrar completamente ensamblado,
y corregido y se procede a la etapa de las pruebas de -alidaci2n de re,uerimientos
o 7pruebas de aceptaci2n:, enfocadas a las acciones ,ue reali/a el usuario y a las
salidas obtenidas. Estas deben corresponder a las expectati-as del usuario descritas
en el documento de Be,uerimientos de Software
"+* 8aterial ,eferencial
Plan de Proyecto
Especificaci2n Be,uerimientos de Software
Iormularios de Inscripciones en la Iglesia y la Escuela 0u/ y 9ida.
"+& $efiniciones y Acrnimos
0a siguiente tabla muestra las definiciones utili/adas en este documento, ,ue
pueden ser de ayuda para la profundi/aci2n en el tema.
'cr,nimo Definici,n
STP Software Test Plan % Plan de pruebas de
Software
+<+ 9erification and 9alidation L
9erificaci2n y 9alidaci2n
'S 4r,uitectura de Software
2S Ingenier.a del Software
=;2 Interfa/ grafica
D'$ ata 4ccess 5bject % Objeto de cceso a
!atos
>0? >ob 8ontrol 0enguaje %
Tabla 3 Definiciones# acr,nimos y abre&iaciones

( P,3$6C03S $2 P,621A
(+" 8dulos del Pro>rama
4 continuaci2n se describen las pruebas a reali/ar por el desarrollador para
cada m2dulo ,ue se est* construyendo;
Para esto reali/aremos algunas definiciones;
.odulo4 8onjunto de Elementos ,ue tienen una finalidad en com<n
Pruebas4 Tipo de Pruebas 3tili/adas dentro del 8omponente
Descripci,n4 Explicaci2n del objeti-o de la prueba
.odulo Pruebas Descripci,n
02gica del Fegocio
?embres.a
Iuncionalidad
El sistema debe poder reali/ar los
re,uerimientos funcionales del sistema en
ambos m2dulos. 02gica del Fegocio
Escuela
Propiedades del
Sistema
Fo Iuncionales
El sistema debe cumplir con todos los
re,uerimientos no funcionales planteados
en el documento de re,uerimientos.
63I Interfa/
El sistema debe ser f*cil de manejar. El
usuario debe poder reali/ar todas las
acciones re,ueridas de manera 2ptima.
ebe poder hacer las tareas re,ueridas en
el momento re,uerido.
0oo) 4nd Ieel 0a apariencia mostrada al usuario.
45 Persistencia El sistema debe ser capa/ de guardar
datos para ser usados en otro momento, o
por otros usuarios. 4dem*s debe tener
acceso a ellos sin tener ning<n problema
de consistencia e integridad.
Tabla 4 .,dulos del pro)rama
(+( Procedimientos de 6suario
Para utili/ar la herramienta de manera adecuada se necesitan gu.as o manuales
,ue sean claros, correctos, completos $ coherentes, para ,ue el usuario pueda
manejar la herramienta de forma correcta y pueda comprender los conceptos
tras la funcionalidad, adem*s de apro-echarla al m*ximo. 4 continuaci2n se
describen las G propiedades de calidad de estos procedimientos;
0lara4 las instrucciones proporcionadas en el documento, deben ser lo
suficientemente explicitas para ,ue el usuario pueda desen-ol-erse dentro del
entorno de la herramienta.
0orrecta4 Fo existen errores sem*nticos, sint*cticos, ortogr*ficos ni de enlace
dentro de la documentaci2n proporcionada al usuario.
0ompleta4 la informaci2n debe estar completa, desde la parte t1cnica hasta la
parte funcional.
0o5erente4 no existen ambigJedades, ni incongruencias dentro del documento
,ue puedan confundir al usuario.
0os documentos a entregar con la herramienta son;
.anual de pruebas4 ?anual ,ue tiene las instrucciones para poder manejar la
herramienta sin problemas.
.anual de la instalaci,n4 ?anual ,ue tiene las instrucciones sobre c2mo
instalar la herramienta.
(+9 Procedimientos de o?erador
0os procedimientos de prueba deben demostrar ,ue la aplicaci2n se puede
ejecutar y admite un entorno de producci2n !-entanas de ayuda al usuario'
Para esto debemos asegurarnos ,ue la aplicaci2n se puede correr sin problemas
en las plataformas indicadas, en este caso (indows E y (indows DP. Fo est*
de m*s reali/ar pruebas ,ue demuestren ,ue se puede correr en distintas
plataformas para dar una opci2n a la instituci2n con la ,ue se trabaja.
Todas las -entanas de ayuda al usuario tambi1n deber*n correrse sin problema.
Se deber* probar ,ue estas corren son de -erdadera ayuda al usuario y no
perjudican en su trabajo.
9 CA,AC02,5S05CAS A P,31A,
El plan de pruebas para este proyecto tiene por objeti-o probar el 7Sistema 0u/ y 9ida:. En esta
secci2n se encuentran las caracter.sticas del software y las combinaciones de caracter.sticas de
software para ser probados.
0as principales pruebas consideradas en este documento, siendo las ,ue m*s importancia pueden
tener en nuestro sistema, son; pruebas unitarias, de inte%racin, del sistema, de implantacin $
pruebas de aceptacin., nombradas en la secci2n &.&.# de este documento, y nos ser-ir*n para
-erificar c2mo se reali/a cada funci2n del sistema, y una prueba global del software para -erificar
el funcionamiento general del mismo.
4 continuaci2n se detallan las principales caracter.sticas ,ue deber*n ser probadas;
Registro de Miembros: 0a secretaria o la Pastora, pueden registrar miembros en cual,uier
momento. 8ada miembro tiene una serie da caracter.sticas. Para su registro se debe adjuntar la
fotocopia del carnet, del certificado de nacimiento, carta de transferencia, etc. Esto debe ser igual a
los formularios ,ue se entregaban normalmente para la inscripci2n. Todos los datos deben
guardarse correctamente en una base de datos para su posterior an*lisis.
Modificar datos de Miembros: ebido a la cantidad de datos registrados y especialmente a los
archi-os ,ue se pueden subir !fotograf.a, certificados, etc., es menester ,ue se le permita a la
secretaria la modificaci2n de los elementos r*pida y precisa, o el poder a+adir nue-os datos. Se
deben actuali/ar los campos en su actuali/aci2n y controlar ,ue no se pierda ning<n dato en el
proceso.
Bsqueda e informe de datos: Es importante ,ue el sistema pueda mandar reportes de la manera
habitual. 0a comunicaci2n con el software Excel tiene ,ue funcionar correctamente como esta
aclarado en el ocumento de Be,uerimientos para cuando el Pastor de la Iglesia necesite datos
para planificaci2n de acti-idades, la secretaria o la pastora ,ue trabajaran con el sistema puedan
en-iar la informaci2n r*pida y precisa. Se debe comprobar ,ue al buscar informaci2n y al generar
reportes no se pierda informaci2n o se a+ada 7informaci2n basura:
Registrar Aumnos en os cursos !orrectos: Se abrir*n -arios cursos en los ,ue registraran los
alumnos. Es importante ,ue el alumno pueda inscribirse en los cursos correctos y se guarde el
registro para su posterior calificaci2n, certificados, etc. Es importante impedir ,ue los alumnos
tomen materias e,ui-ocadas !,ue no correspondan con su a-ance', ,ue crucen los horarios de sus
materias o se supere el limite alumnos en un curso.
A"ertura # !ierre de cursos: Fo todas las materias estar*n abiertas todo el tiempo. 0a apertura de
una materia se reali/ara cuando el pastor lance una con-ocatoria ,ue tenga un buen n<mero de
respuestas. 0a apertura del curso deber* contemplar un periodo de tiempo, incluido el tiempo para
asignar calificaciones, asistencias, etc. 0o m*s importante es -erificar ,ue los cursos puedan ser
creados sin perjudicarse entre ellos en aulas, horas con los mismos docentes, etc.
Registrar as notas de os aumnos "or materia # gesti$n: Se debe comprobar ,ue las notas se
mantengan y ,ue sean de f*cil manejo para ,ue no haya problemas al subir las notas o al hacer una
re-isi2n hist2rica.
!one%i$n # dis"onibiidad con a base de datos:
*+ 42A06,2S N30 03 12 02S02$
ebido al tiempo para la reali/aci2n y la implementaci2n del software, en esta secci2n se
presentan algunas caracter.sticas y combinaciones espec.ficas de caracter.sticas ,ue no -an a
ser probadas a detalle.
!reaci$n de carrearas # materias nue&as: Esta opci2n no ser* probada a detalle debido a
,ue no se utili/ara con frecuencia ni en este preciso instante. Se cubre la posibilidad para un
futuro contemplado en los re,uerimientos tomando en cuenta ,ue actualmente solo hay una
7carrera: con materias est*ticas.
&+ APP,3AC.
(&escribe the overall approaches to testin%. 'he approach should be described in sufficient
detail to permit identification of the major testin% tas(s and estimation of the time required
to do each tas(. )dentif$ the t$pes of testin% to be performed alon% !ith the methods and
criteria to be used in performin% test activities. &escribe the specific methods and
procedures for each t$pe of testin%. &efine the detailed criteria for evaluatin% the test
results.#
(*or each level of testin% there should be a test plan and the appropriate set of deliverables.
)dentif$ the inputs required for each t$pe of test. +pecif$ the source of the input. Also,
identif$ the outputs from each t$pe of testin% and specif$ the purpose and format for each
test output. +pecif$ the minimum de%ree of comprehensiveness desired. )dentif$ the
techniques that !ill be used to jud%e the comprehensiveness of the testin% effort. +pecif$ an$
additional completion criteria (e.%., error frequenc$#. 'he techniques to be used to trace
requirements should also be specified.#
&+" Com?onent 0estin>
('estin% conducted to verif$ the implementation of the desi%n for one soft!are
element (e.%., unit, module# or a collection of soft!are elements. +ometimes
called unit testin%. 'he purpose of component testin% is to ensure that the
pro%ram lo%ic is complete and correct and ensurin% that the component !or(s as
desi%ned.#

&+( 5nte>ration 0estin>
('estin% conducted in !hich soft!are elements, hard!are elements, or both are
combined and tested until the entire s$stem has been inte%rated. 'he purpose of
inte%ration testin% is to ensure that desi%n objectives are met and ensures that the
soft!are, as a complete entit$, complies !ith operational requirements.
)nte%ration testin% is also called +$stem 'estin%.#
&+9 Con-ersion 0estin>
('estin% to ensure that all data elements and historical data is converted from an
old s$stem format to the ne! s$stem format.#
&+* @o/ Stream 0estin>
('estin% to ensure that the application operates in the production environment.#
&+& 5nterface 0estin>
('estin% done to ensure that the application operates efficientl$ and effectivel$
outside the application boundar$ !ith all interface s$stems.#
&+: Security 0estin>
('estin% done to ensure that the application s$stems control and auditabilit$
features of the application are functional.#
&+) ,eco-ery 0estin>
('estin% done to ensure that application restart and bac(up and recover$ facilities
operate as desi%ned.#
&+; Performance 0estin>
('estin% done to ensure that that the application performs to customer
e,pectations (response time, availabilit$, portabilit$, and scalabilit$##.
&+< ,e>ression 0estin>
('estin% done to ensure that that applied chan%es to the application have not
adversel$ affected previousl$ tested functionalit$.#
&+"% Acce?tance 0estin>
('estin% conducted to determine !hether or not a s$stem satisfies the acceptance
criteria and to enable the customer to determine !hether or not to accept the
s$stem. Acceptance testin% ensures that customer requirements- objectives are met
and that all components are correctl$ included in a customer pac(a%e.#
&+"" 1eta 0estin>
('estin%, done b$ the customer, usin% a pre"release version of the product to verif$
and validate that the s$stem meets business functional requirements. 'he purpose
of beta testin% is to detect application faults, failures, and defects.#
:+ PASS ' 4A5L C,502,5A
(+pecif$ the criteria to be used to determine !hether each item has passed or failed
testin%.#
:+" Sus?ension Criteria
!+pecif$ the criteria used to suspend all or a portion of the testin% activit$ on test
items associated !ith the plan.#
:+( ,esum?tion Criteria
(+pecif$ the conditions that need to be met to resume testin% activities after
suspension. +pecif$ the test items that must be repeated !hen testin% is resumed.#
:+9 A??ro-al Criteria
(+pecif$ the conditions that need to be met to approve test results. &efine the
formal testin% approval process.#
". 02S05NG P,3C2SS
()dentif$ the methods and criteria used in performin% test activities. &efine the specific
methods and procedures for each t$pe of test. &efine the detailed criteria for evaluatin%
test results.#
)+" 0est $eli-era/les
()dentif$ the deliverable documents from the test process. 'est input and output
data should be identified as deliverables. 'estin% report lo%s, test incident reports,
test summar$ reports, and metrics- reports must be considered testin%
deliverables.#
)+( 0estin> 0asAs
()dentif$ the set of tas(s necessar$ to prepare for and perform testin% activities.
)dentif$ all intertas( dependencies and an$ specific s(ills required.#
)+9 ,es?onsi/ilities
()dentif$ the %roups responsible for mana%in%, desi%nin%, preparin%, e,ecutin%,
!itnessin%, chec(in%, and resolvin% test activities. 'hese %roups ma$ include the
developers, testers, operations staff, technical support staff, data administration
staff, and the user staff.#
)+* ,esources
()dentif$ the resources allocated for the performance of testin% tas(s. )dentif$ the
or%ani.ational elements or individuals responsible for performin% testin%
activities. Assi%n specific responsibilities. +pecif$ resources b$ cate%or$. )f
automated tools are to be used in testin%, specif$ the source of the tools,
availabilit$, and the usa%e requirements.)
)+& ScBedule
()dentif$ the hi%h level schedule for each testin% tas(. /stablish specific
milestones for initiatin% and completin% each t$pe of test activit$, for the
development of a comprehensive plan, for the receipt of each test input, and for
the deliver$ of test output. /stimate the time required to do each test activit$.#
(0hen plannin% and schedulin% testin% activities, it must be reco%ni.ed that the
testin% process is iterative based on the testin% tas( dependencies.#
;+ 2NV5,3N82N0AL ,2Q65,282N0S
!Specify both the necessary and desired properties of the test en-ironment including the
physical characteristics, communications, mode of usage, and testing supplies. 4lso pro-ide
the le-els of security re,uired to perform test acti-ities. Identify special test tools needed and
other testing needs !space, machine time, and stationary supplies. Identify the source of all
needs that is not currently a-ailable to the test group.'
;+" .ardware
()dentif$ the computer hard!are and net!or( requirements needed to complete
test activities.#
;+( Software
()dentif$ the soft!are requirements needed to complete testin% activities.#
;+9 Security
()dentif$ the testin% environment securit$ and asset protection requirements.#
;+* 0ools
()dentif$ the special soft!are tools, techniques, and methodolo%ies emplo$ed in
the testin% efforts. 'he purpose and use of each tool shall be described. Plans for
the acquisition, trainin%, support, and qualification for each tool or technique.#
;+& Pu/lications
()dentif$ the documents and publications that are required to support testin%
activities.#
;+: ,isAs and Assum?tions
()dentif$ si%nificant constraints on testin% such as test item availabilit$, test
resource availabilit$, and time constraints. )dentif$ the ris(s and assumptions
associated !ith testin% tas(s includin% schedule, resources, approach and
documentation. +pecif$ a contin%enc$ plan for each ris( factor.#
<+ C.ANG2 8ANAG282N0 P,3C2$6,2S
()dentif$ the soft!are test plan chan%e mana%ement process. &efine the chan%e
initiation, chan%e revie!, and chan%e authori.ation process.#
"%+ PLAN APP,3VALS
()dentif$ the plan approvers. 1ist the name, si%nature and date of plan approval.#