You are on page 1of 109

Calidad de Software

Ingeniera de Software - AIEP


Graciela Mardones V.
Otoo, 2016

Relacin entre Calidad y


Prueba de Software
Cul es la naturaleza de la prueba de
software?
Qu relacin existe entre prueba de
software y aseguramiento de calidad?
Cules son las principales actividades
de la Prueba de Software?
Cul es la calidad requerida de la
documentacin para dar sustento a al
proceso de prueba?

Naturaleza de la Prueba de Software


Verificacin y Validacin (V&V) son el conjunto de
procesos utilizados para Asegurar la Calidad (QA)
de una maquina construida
Validacin: Construir la mquina correcta

Asegurando que satisfaga las necesidades y


deseos de quien requiere que la mquina
sea construida.
Verificacin: Construir la maquina bien

Asegurar que la maquina cumpla con los


requerimientos, y que los artefactos
intermedios sean consistentes entre si.

Naturaleza de la Prueba de Software


Cundo comienza la Verificacin y Validacin de
Software? Cundo est completa?
Qu tcnicas en particular deben ser aplicadas
durante el desarrollo?
Cmo puede evaluarse el grado de preparacin /
disponibilidad del producto? est listo para operar?
Cmo puede controlarse la calidad de las
sucesivas liberaciones?qu sucede cada vez que
mantengo el producto?
Cmo puede mejorarse el proceso de prueba de
software?

Naturaleza de la Prueba de Software


Cundo comienza la Verificacin y
Validacin de Software? Cundo
est completa?
inicia cuando se decide construir un
producto de software (a veces antes).
dura ms all de la entrega del
producto; continua mientras el producto
est en uso para controlar su evolucin
y adaptacin a nuevas condiciones.

Naturaleza de la Prueba de Software


Qu tcnicas en particular deben ser aplicadas
durante el desarrollo?

Naturaleza de la Prueba de Software


Qu tcnicas en particular deben ser
aplicadas durante el desarrollo?
Las tcnicas se utilizan de manera
combinada porque:
Eficacia de diferentes clases de las fallas,
Aplicabilidad en diferentes momentos de un
proyecto,
Las diferencias en el propsito,
Cambios
internos
en
el
costo
y
aseguramiento (garanta).

Naturaleza de la Prueba de Software


Cmo puede evaluarse el grado de preparacin /
disponibilidad del producto? est listo para
Ejemplo Medidas de
operar?
Fiabilidad
El anlisis y testing durante el desarrollo
Disponibilidad: mide la calidad
buscan revelar las fallas,
del servicio en trminos del
No pueden eliminarse todas las tiempo
fallas,
de funcionamiento versus
tiempo sin funcionar.
A&T no pueden ejecutarse indefinidamente
Debe
saberse
si
el
requerimientos de calidad,

Tiempo Medio
entre Fallos
producto
cumple
los

(MTBF): mide la calidad del


servicio en terminos del MTBF
fallos.
nivel entrerequerido
de

Debe especificarse el
fiabilidad y cundo ese nivel es Confiabilidad:
alcanzado.
indica la fraccin
de todas las operaciones que
intent completar con xito.

Naturaleza de la Prueba de Software


Cmo puede evaluarse el grado de preparacin /
disponibilidad del producto? est listo para operar?
Ejemplo Aplicacin Web:

50 interacciones terminan con cargo a la tarjeta de crdito.


El software siempre funciona a la perfeccin hasta el punto en
que se registra el cargo en la tarjeta de crdito, pero la mitad
de los intentos de cargos cobran (cargan) un monto errado.

Cul es la fiabilidad del sistema?

Si se cuenta la fraccin de interacciones individuales que se


llevan a cabo correctamente, slo una operacin en 100 falla:
El sistema es un 99% confiable.
Si se cuenta todo el perodo de sesiones, slo el 50% es
fiable, ya que la mitad de las sesiones resultan en un cargo
indebido a la tarjeta de crdito

Naturaleza de la Prueba de Software


Cmo puede controlarse la calidad de las
sucesivas liberaciones?qu sucede cada vez que
mantengo el producto?
Los productos de software operan durante
perodos de tiempo extensos (aos), y sufren
cambios:
Deben adaptarse a los cambios de ambiente,
Evolucionan para servir a los propsitos de los nuevos y
cambiantes requerimientos de usuarios.

Tareas de Calidad despus de la entrega:


Probar y analizar el cdigo nuevo y modificado,
Re-ejecutar las pruebas de sistemas,
Registro de las operaciones realizadas y sus resultados.

Naturaleza de la Prueba de Software


Cmo puede mejorarse el proceso de prueba
de software?
Analizar si los mismos defectos se encuentran (se
repiten) proyecto tras proyecto.
Mejorar la calidad de los procesos implica mejorar los
procesos mediante:

Identificacin y remocin de debilidades en el proceso de


desarrollo,
Identificacin y remocin de debilidades en las pruebas y
anlisis que permiten que dichas debilidades no sean
detectadas.

Aplicacin de Tcnicas de SPI (Software Process


Improvement)

Naturaleza de la Prueba de Software


Requerimientos
actuales

Validacin
Incluye pruebas
de usabilidad,
feedback del
usuario.

Especificaciones
de SW

Sistema

Verificacin
Incluye testing
(anlisis
dinmico),
revisiones e
inspecciones
(anlisis esttico)

Naturaleza de la Prueba de Software


Modelo Cascada (Royce, 1970)

Naturaleza de la Prueba de Software


Modelo
Espiral
(Boehm,
1988)

Naturaleza de la Prueba de Software


Proceso de Desarrollo de SW
Unificado (Jacobson, 1999)

Naturaleza de la Prueba de Software


En resumen la prueba de software
corresponde a la aplicacin de un
control de calidad que involucra la
ejecucin de parte y/o la totalidad de
un sistema.

Relacin entre prueba de software y


aseguramiento de calidad
El aseguramiento de calidad corresponde a la
definicin de los atributos de calidad
relativos cliente y desarrollador, adems
de la definicin de los controles de
calidad
que
explicitaran
mediante
evidencia la presencia de dichos atributos
en el producto y la documentacin que lo
acompaa (para parte o la totalidad de este).
La prueba de software corresponde un
mecanismo de control de la calidad.

Relacin entre prueba de software y


aseguramiento de calidad
Prueba de Modulo evidencia si el modulo es capaz de llevar a
cabo la funcin especificada en el diseo del sistema. atributos
relacionados con el desarrollador
Prueba de Paquete evidencia que las funciones de los mdulos
en el paquete estn correctas verificando su funcionamiento en
conjunto. atributos relacionados con el desarrollador
Prueba de Integracin evidencia que las interfaces entre
paquetes /mdulos estn correctas y que las funciones
implementadas en parte del sistema se han construido
correctamente. atributos relacionados con el desarrollador y
luego con el cliente
Pruebas de Sistema y aceptacin verifican que las
funcionalidades y restricciones establecidas para el sistema han
sido implementadas correctamente. atributos relacionados con
el cliente.

Actividades de la Prueba de
Software
Inspecciones (ejercicio prxima clase)
Revisiones (ejercicio prxima clase)
Pruebas ejecutables:
De
De
De
De
De
De

Mdulo (caja negra / caja gris / caja blanca)


Paquete
Integracin
Sistemas
Aceptacin
Regresin

Actividades de la Prueba de
Software
Por ejemplo:
las pruebas de caja blanca requieren del
conocimiento
de
la
estructura
del
programas el cdigo a probar.
Las pruebas de caja negra no requieren el
conocimiento de la estructura del programa,
tan solo de los parmetros de entrada y
las salidas esperadas.

las pruebas de mdulo o unidad deberan


ser de caja negra o caja blanca?

Actividades de la Prueba de
Software
Por ejemplo las pruebas de paquete se
utilizan en sistema estructurados de
dicha manera; donde el paquete
corresponde a una coleccin de mdulos
relativos al manejo de un grupo de datos
o enfocados a la implementacin de una
funcionalidad.
Las pruebas de paquetes sirven para
asegurar que los mdulos en dicho paquete
trabajan correctamente en su conjunto.

Conocimientos previos

Conocimientos previos
Conoce o recuerda alguna tcnica
de prueba???
Particin equivalente (PA)
Anlisis de valor lmite (AVL)
Pares-Sabios (PS)

Pruebas de Unidad
Definicin Unidad
Corresponde a un mtodo/funcin/procedimiento.
Coleccin
de
mtodos/funciones/procedimientos
relacionados.

Definicin Prueba de Unidad


Corresponden al proceso de desarrollo de software en
el cual son probadas las partes ms pequeas
de la aplicacin, de manera que sean revisadas de
forma individual e independiente.
Prueba de software individual o unidades de
hardware o grupos de unidades relacionadas
[IEEE610.12]
PAQUETE

Pruebas de Unidad
Definicin Prueba de Unidad (cont.)
Una prueba ejecutada por el desarrollador en un
ambiente de laboratorio, que debe demostrar que
el programa cumple con los requerimientos
establecidos en la especificacin de diseo
[Koomen and Pol 00]
Prueban los componentes de software individuales o
colecciones de componentes. Los testers definen el
domino de entrada para las unidades en cuestin
e ignoran el resto del sistema. [Whittaker 00]

Esta actividad a menudo es automatizada, pero


tambin puede efectuarce manualmente.

Pruebas de Unidad
Qu?

Cundo?

Tcnicas

En cada construccin/
da/semana
Cmo?
Basada en estructura Toma segundos u
horas correrla
No formalmente

Quin?

Por qu?

Aseguramiento de las
Desarrollador (grupo)
funcionalidades
No un tester o QA

Preguntas Claves para la Prueba de


Unidad
Qu?
Tcnica
Especificada o

Definicin
Probar componente
singular o grupos de
no?
componentes.
Fortaleza
Identificacin del
componente (unidad).
Debilidades
Pruebas GUI
Identificacin de unidades.
Mantenimiento de los
scripts de prueba.
Estructuras de datos.

Preguntas Claves para la Prueba de


Unidad
Definicin

Basada en estructura Basada en estructuras.


Preferentemente
No formalmente
automatizada.
Fortaleza
Marco de trabajo para la
prueba.
Debilidades
Documentacin.
Seleccin de Pruebas.
Seleccin de metricas.

Cmo?

Preguntas Claves para la Prueba de


Unidad
Definicin
Por desarrollador.
Desarrollador (grupo)
Fortaleza
No un tester o QA
Independencia para prueba.
Redes competentes.
Debilidades
Independencia.
Introduccin de estrategias.

Quin?

Preguntas Claves para la Prueba de


Unidad
Cundo?
Definicin
En cada construccin/
da/semana
Feedback rpido.
Toma segundos u horas
Fortaleza
correrla
Pruebas de regresin
continua.
Debilidades
Criterios para finalizacin
de la prueba.

Preguntas Claves para la Prueba de


Unidad
Por qu?

Aseguramiento de las Definicin


Aseguramiento de la
funcionalidades
funcionalidad.
Fortaleza
Aplicacin de mtodos
diversos (giles).
Debilidades
Costos v/s valor
obtenido.

Resumiendo la Prueba de Unidad


Objetivo de la Prueba de Unidad:
Encontrar defectos en la lgica, datos o algoritmos del
componente (mdulo).

Caractersticas
Pueden abarcar desde un componente a un grupo de
grupo de componentes o un programa completo
Suelen realizarse por personal de desarrollo
Inspeccin de cdigo (walkthrough) tipicamente por el equipo
Compilacin y remocin de los errores de sintxis remanentes
Pruebas de Caja Negra

Basadas en la Especificacin
No puedo ver dentro del componente
Pruebas de Caja blanca

Basadas en programa
Puedo ver dentro del componente

Ejemplo clsico
John
John works hard. He codes everyday. The project
deadline is tomorrow. He types in about two hundred
new lines per hour, and thinks that after 6 hours and
roughly a thousand new lines added the program would
work flawlessly.

Betty
Betty works hard. She codes everyday. The project
deadline is tomorrow. She types in about one hundred
new lines per hour, and keeps testing each method she
adds. She does not proceed to write new codes unless all
previously written pieces work correctly.

Guess who will go to bed earlier?

Todo desde el punto de


vista del programador y
su relacin con el
cdigo

Pruebas de Unidad
Caractersticas
mbito: unidad individual
A menudo corresponde a la nocin de unidad de
compilacin para un lenguaje de programa.

Foco: correctitud de la unidad


Tcnicas:
Estrategia bsica: Caja negra y caja blanca.
Programacin eXtrema

Es responsabilidad del desarrollador.


Surge el concepto del desarrollador-testeador, es cual
es un componente importantsimo para el paradigma
de programacin eXtrema.

Pruebas de Unidad & IEEE


Std.

Fases

Planificacin
Planificar los acercamientos generales, recursos y
calendario.
Determinar caractersticas a probar
Refinar el plan general

Adquisicin del set de pruebas


Disear el set de pruebas
Implementar y refinar el plan y el diseo

Medicin
Ejecutar los procedimientos de prueba
Verificar la finalizacin
Evaluar el esfuerzo de prueba y unidad

Pruebas de Unidad & IEEE


Std.

Pruebas de Unidad & IEEE


Std.
Planificacin
Planificar los acercamientos generales, recursos y
calendario.
Entradas: planes de proyecto y documentacin de
requerimientos de software.
Tareas
Especificacin de la aproximacin general a las pruebas de unidad
Identifica reas de riesgo a ser cubiertas por las pruebas,
Especifica restricciones, diseo e implementacin de las pruebas.
Especia fuentes de entrada, salida y estado de datos.
Tcnicas asociadas a salida, recoleccin y validacin de datos.
Especificacin de la completitud de los requerimientos
Identificacin de las reas a cubrir y el grado de cobertura.
Especificacin de la terminacin de los requerimientos
Determina los requerimientos para la finalizacin normal del proceso de
prueba de unidad.

Pruebas de Unidad & IEEE


Std.

Planificacin (cont.)

Planificar los acercamientos generales,


recursos y calendario.
Tareas (continuacin)
Determina requerimiento de los recursos
Estima los recursos requeridos para la adquisicin del
ser de pruebas, su ejecucin y subsecuente
repeticin.
Especifica un Calendario General

Salidas:
Informacin de la planificacin de las pruebas de unidad.
Peticiones generales de recursos para las pruebas de
unidad.

Pruebas de Unidad & IEEE


Std.

Planificacin (cont.)

Determinar caractersticas a probar


Entradas
Documentacin de requerimientos de unidad
Documentos de arquitectura del diseo.

Tareas
Estudio de requerimientos funcionales
Identificacin de requerimientos adicionales y
procedimientos
Identificacin de los estados de la unidad

Salidas
Listado de elementos a incluir en la prueba
Peticiones de clarificacin de requerimientos de unidad.

Pruebas de Unidad & IEEE


Std.

Planificacin (cont.)

Refinar el plan general


Refinar entradas
Listado de elementos a incluir en el testing.
Informacin general de la planificacin de la prueba de unidad

Refinar Tareas
Acercamientos al refinamiento
Especificacin de requerimientos especiales de recursos
Especificacin detallada de la calendarizacin

Refinar salidas
Informacin especifica de la planificacin de la prueba de
unidad
Peticin de recursos especiales para la prueba de unidad

Pruebas de Unidad & IEEE


Std.
Adquisicin del set de pruebas
Disear el set de pruebas
Entradas

Documentacin de requerimientos de unidad


Listado de elementos a incluir en la prueba
Informacin de planificacin de l aprueba de unidad
Especificacin de las pruebas previas que este disponible

Tareas

Disear la arquitectura del set de pruebas.


Obtener en forma explicita los procedimientos de prueba
Obtener la especificacin de los casos de prueba
Aumentar, segn sea requerido, la especificacin de los casos
de prueba basado en a informacin de diseo
Completar la especificacin de casos de prueba

Pruebas de Unidad & IEEE


Std.
Adquisicin del set de pruebas
Disear el set de pruebas (cont.)
Salidas

Especificacin de diseo de la prueba de unidad


Especificacin de procedimientos separados de prueba
Especificacin de procedimientos separados de caso de prueba
Solicitud de mejora del diseo de unidad.

Implementar y refinar el plan y el diseo


Entradas
Informacin de la planificacin de las pruebas de unidad
Especificacin de los casos de prueba en la especificacin de diseo
de la prueba de unidad
Descripcin de la estructura de datos del software
tems de prueba
Informacin de las pruebas previas

Pruebas de Unidad & IEEE


Std.

Adquisicin del set de pruebas

Implementar y refinar el plan y el diseo


(cont.)
Tareas
Obtener y verificar datos
Obtener recursos especiales
Obtener los tems de prueba

Salidas

Datos de prueba verificados


Recursos para el soporte de pruebas
Configuracin de los tems de prueba
Informacin sobre el resumen inicial

Pruebas de Unidad & IEEE


Std.
Medicin
Ejecutar los procedimientos de prueba
Ejecutar pruebas
Determinar resultados
Salidas
Informacin de ejecucin de las pruebas incluida en el reporte de
resumen.
Especificacin de pruebas revisada
Datos de prueba revisados

Verificar la finalizacin
Chequeo de entradas
Chequeo de tareas
Chequeo de salidas

Evaluar el esfuerzo de prueba y unidad

Pruebas de Unidad & IEEE


Std.
Medicin
Verificar la finalizacin
Chequeo de entradas

Requerimientos de completitud y terminacin.


Informacin de ejecucin
Especificacin de pruebas
Descripcin de la estructura de datos del software

Chequeo de tareas
Chequeo de la finalizacin normal del proceso de testing
Chequeo de la terminacin anormal del proceso de testing
Set de pruebas suplementarias

Chequeo de salidas
Chequeo de la informacin en el reporte de resumen de pruebas
Especificaciones de pruebas revisadas o adicionales
Datos de prueba adicionales

Pruebas de Unidad & IEEE


Std.
Medicin
Evaluar el esfuerzo de prueba y unidad
Evaluacin de Entradas

Especificacin del diseo de pruebas


Informacin de ejecucin
Informacin de chequeo
Especificacin de casos de prueba separada

Evaluacin de tareas

Descripcin del estado de las pruebas


Descripcin del estado de la unidad
Completar el reporte de resumen
Asegurar la preservacin delos productos del tetsing

Evaluacin de Salidas
Reporte de resumen de prueba
Coleccin y almacenamiento completo de los productos del testing

Pruebas de Unidad & IEEE


Std.
INICIO

Pruebas de Unidad & IEEE


Std.
I
N
I
C
I
O

Pruebas de Integracin
Definicin Prueba de Unidad
Corresponde a un proceso de desarrollo de software
en el cual las unidades de programas son combinadas
y probadas como grupo en mltiples formas.

Caractersticas
Expone problemas relativos a las interfaces entre los
componentes de programa.
Las pruebas de integracin resultan crticas para
asegurar
la correctitud funcional del sistema
integrado.
Su objetivo es descubrir errores en la interface de los
elementos que estn siendo integrados.

Drivers & Stubs

Driver invoca al
mdulo bajo prueba.
Entrega los datos de
entrada para la
prueba.

Arns de Pruebas
Drive
r

T
D
Stub

Stub es un procedimiento,
modulo o unidad tonto que
ocupa el lugar de la seccin
no finalizada del sistema

http://amit-badola.blogspot.com/2007/10/drivers-and-stubs.html

Pruebas de Integracin
Categoras de I&T
Incremental

Expande
el
grupo
progresivamente.

de

mdulos

integrados

No Incremental

Los mdulos de software son combinados y probados en


forma aleatoria.
Las pruebas de integracin son, a menudo, las que ms
tiempo consumen y tambin las mas caras.

Cundo se llevan a cabo?

Cuando se integran unidades o mdulos para formar componentes.


Componentes para formar producto.
Productos para formar sistemas.

Pruebas de Integracin
Estrategias
Instantnea v/s incremental

La prueba de integracin instantnea o acercamiento big bang,


localiza errores sutiles que puede ser difciles de encontrar
despus del bang.
Los resultados de la prueba de integracin incremental pueden
reducir significativamente la localizacin de errores y el tiempo de
correccin.
El
ptimo
acercamiento
incremental
es
inherentemente y dependiente del proyecto individual y de los
pros y contras de varias alternativas.

En que orden deben integrarse los mdulos?

Top down?
Botton up?
Los mdulos crticos o de alto riesgo primero?
Por generalidad?

Pruebas de Integracin
Integracin TOP-DOWN
Las rutinas de control son probadas primero,
en lo posible con las estructuras de control en
el nivel medio, presentes slo como stubs
(bloques de cdigo para prueba).
Stubs son subprogramas incompletos, utilizados slo
para permitir que las rutinas de control de alto nivel
sean probadas.
El nivel superior, usualmente el que controla los componentes,
es testeado por si mismo. Luego, todos los componentes
llamados por el/los componente(s) probado(s) son combinados
Prueb
Prueb
para probarse como una
unidad mayor. Este acercamiento se
Prueb
a
a
replica hasta que ha sido incorporado
el ltimo componente.
a
A, B,
B, C,
A
C, D,
D
E, F

Pruebas de Integracin
Integracin TOP-DOWN
Puede ser ejecutado en

En Profundidad

En Amplitud

Cada mdulo es probado cada vez en mayor detalle, reemplazando


ms y ms niveles de detalle con cdigo real en lugar de stubs.
Refinamiento de todos los mdulos en el mismo nivel de control a
travs de la aplicacin.

En la practica se aplica una combinacin de las dos


tcnicas

En etapas iniciales todo los mdulos pueden ser parcialmente


funcionales, posiblemente implementados slo para manejar data no
errnea. Esto debe ser probado por medio de integracin en amplitud.
Despus de un cierto perodo de tiempo, los sucesivos refinamientos
sern reemplazados por acercamientos a la funcionalidad completa.
Esto permite probar primero en profundidad un mdulo, para luego
ejecutarlo simultneamente con mdulos probados primeramente en
amplitud.

Pruebas de Integracin
Integracin TOP-DOWN
Ventajas

Permite la verificacin temprana del comportamiento de los


niveles superiores.
Un mdulo driver (al menos) es requerido.
Los mdulos pueden ser agregados de uno a la vez de ser
requerido.
Presenta soporte tanto para integracin en profundidad como
en amplitud.

Desventajas

Demora la verificacin del comportamiento de los niveles


inferiores.
Los stubs son requeridos por elementos perdidos.

Mostrar mensajes, mostrar parmetros, retornar valores desde tablas,


retornar valores seleccionados por parmetros.

Las entradas y salidas de los casos de prueba pueden ser


difciles de formular o interpretar.

Pruebas de Integracin
Integracin TOP-DOWN

Pruebas de Integracin
Integracin TOP-DOWN

TestA

LayerI

TestA,B,C,D

LayerI+II

LayerI

LayerII

LayerIII

Test
A,B,C,D,
E,F,G
AllLayers

Pruebas de Integracin
Integracin BOTTON-UP

En este tipo de pruebas de integracin, donde un mdulo es probado


individualmente desde un arns de pruebas (scaffolding). Una vez
que un set individual de mdulos ha sido probado, estos son
combinados en una coleccin de mdulos conocidos como
construcciones, los cuales entonces son probados por un segundo
arns de pruebas. Este proceso puede continuar hasta que las
construcciones consistan en una aplicacin completa.

Se requiere un mdulo conductor (driver) para cada mdulo que


alimenta el caso de prueba de entrada a la interface del mdulo que
est siendo testeado.

Los stubs no son necesarios dado que se inicia con los


mdulos terminales y se utilizan mdulos que ya han
sido probados cuando se estn probando mdulos en
niveles inferiores

Pruebas de Integracin
Integracin BOTTON-UP

Pruebas de Integracin
Integracin BOTTON-UP

TestE
E

TestB,E,F

LayerI

TestF
TestC

TestD,G
TestG

Test
A,B,C,D,
E,F,G

LayerII

LayerIII

Pruebas de Integracin
Integracin BOTTON-UP
Ventajas

Permite la verificacin temprana del comportamiento de los


niveles inferiores.
No se requieren stubs.
Fcil para la formulacin de los datos de entrada para
algunos sub rboles; fcil para interpretar los datos de
salida de otros.

Desventajas

Retrasos en la verificacin en el comportamiento de niveles


superiores.
Se requiere de conductores (drivers) para los elementos
perdidos.
A medida que los sub-rboles son combinados, un gran
nmero de elementos pueden ser integrados de una sola
vez.

Pruebas de Integracin
Integracin por SANDWICH
Combina las estrategias Top-Down y
Botton-Up.
El sistema se ve como si lo estructurara
3 capas:
Una capa cetral (objetivo).
Una capa sobre la capa objetivo.
Una capa bajo la capa objetivo.

Las pruebas convergen en la capa


objetivo.
Cmo se selecciona la capa objetivo si

Pruebas de Integracin
Integracin por SANDWICH
Se aplica a los proyectos de software grandes,
desarrollados por un cierto nmero de sub-equipos, o
en los proyectos pequeos donde los diferentes
mdulos son construidos individualmente.
Los sub equipos o los equipos individuales deben
conducir las pruebas botton-up de los mdulos que
construyeron antes de liberarlos al equipo de
integracin, el cual los ensamblar mediante pruebas
top-down.
Las capas Superior e Inferior pueden testearse en
forma paralela.
No se debe probar concienzudamente los subsistemas
en forma individual antes de la integracin.

Pruebas de Integracin
Integracin por SANDWICH
E

TestB,E,F
TestF

TestG

TestD,G

TestA,B,C,D
Top
Layer
Tests

LayerI
C

TestE

Bottom
Layer
Tests

TestA

Test
A,B,C,D,
E,F,G

LayerII

LayerIII

Pruebas de Integracin
Integracin
modificado

por

SANDWICH

Prueba en paralelo

Capa central con drivers y stubs


Capa superior con stubs
Capa inferior con drivers
Capa superior accesa capa media (la capa
superior reemplaza a los drivers)
Capa inferior accesada por capa media
(capa inferior reemplaza a los stubs)

Pruebas de IntegracinDouble
Double
A

TestB

TestE
Triple
Triple
TestI
TestI

Triple
Triple
TestI
TestI

TestB,E,F

TestI
TestI

Double
Double
TestII
TestII

TestD,G

LayerII
LayerIII

Test
A,B,C,D,
E,F,G

TestG
TestA,C

TestA
TestC

Double
Double
TestII
TestII

TestF
TestD

LayerI

Double
Double
TestI
TestI

Integracin por
SANDWICH modificado

Pruebas de Integracin
Integracin Big Bang
Definida por Myers en 1979; establece que,
cuando todos los componentes son probados
en forma aislada, es una gran tentacin
mezclarlos como si fueran el sistema final para
ver si funciona a la primera.
Prueba
A, B,
C, D

Prueba
A

Prueba
B
Prueba
C

Prueba
D

Pruebas de Integracin
Integracin Big Bang
Muchos programadores utilizan el acercamiento
big-bang para sistemas pequeos, pero no es
practico para los sistemas grandes.
De hecho, se han encontrado una serie de
desventajas por las cuales no es recomendado
para todos los sistemas
Requiere tanto de stubs como de drivers para probar
los componentes independientemente.
Es difcil encontrar la causa de todas las fallas porque
todos los componentes estn fundidos en uno.
Los bugs de interface no pueden ser distinguidos
fcilmente de otro tipo de faltas.

Pruebas de Integracin
Integracin Big Bang
VENTAJAS:
Ninguna

DESVENTAJAS:
Dificultad para debugging.
Mucho cdigo desechable.
Mdulos
crticos
y
perifricos
no
distinguibles.
Los usuarios no ven el producto hasta
etapas finales del ciclo de desarrollo.

Pruebas de Integracin
Comparacin entre las estrategias

Pruebas de Integracin
Pasos genricos
1.1.Basados
Basadosen
enestrategias
estrategiasde
de
integracin,
integracin,seleccione
seleccioneun
un
componente
componentepara
paraser
serprobado.
probado.
Aplique
Apliquepruebas
pruebasde
deunidad
unidadalal
. componente.
componente.
2.2.Coloque
Coloquelos
loscomponentes
componentes
seleccionados
seleccionadosjuntos;
juntos;realice
realice
cualquier
cualquierarreglo
arreglonecesario
necesariopara
para
hacer
hacerlalaprueba
pruebade
deintegracin
integracin
operacional
operacional(drivers,
(drivers,stubs).
stubs).
3.3.Realice
Realicepruebas
pruebasfuncionales:
funcionales:
Defina
Definalos
loscasos
casosde
deprueba
prueba
asociado
asociadoaalalafuncionalidad
funcionalidaddel
del
componente
componenteseleccionado.
seleccionado.

4.4.Realice
Realicepruebas
pruebasestructurales:
estructurales:
Defina
Definalos
loscasos
casosde
deprueba
pruebaque
que
ejerciten
ejercitenelelcomponente
componente
seleccionado.
seleccionado.
5.5.Ejecute
Ejecutelas
laspruebas
pruebasde
dedesempeo.
desempeo.
6.6.Lleve
Lleveregistro
registrode
delos
loscasos
casosde
de
prueba
pruebayylas
lasactividades
actividadesde
de
prueba.
prueba.
7.7.Repita
Repitalos
lospasos
pasos11aa77hasta
hastaque
queelel
sistema
sistemacompleto
completohaya
hayasido
sido
probado.
probado.
El
Elobjetivo
objetivoprimario
primariode
delalaprueba
pruebade
de
integracin
integracines
esidentificar
identificarlos
loserrores
errores
en
enlalaconfiguracin
configuracindel
delcomponente
componente
actualmente
actualmenteprobado.
probado.

Pruebas de Integracin
Qu estrategia escoger?
Factores
Factoresaaconsiderar
considerar
Cantidad
Cantidadde
depruebas
pruebasde
derutina
rutina
(stubs
(stubs&drivers)
&drivers)
Ubicacin
Ubicacinde
delas
laspartes
partes
crticas
crticasen
enelelsistema
sistema
Disponibilidad
Disponibilidadde
dehardware
hardware
Disponibilidad
Disponibilidadde
de
componentes
componentes
Asuntos
Asuntosconcernientes
concernientesaa
calendarizacin
calendarizacin
Acercamiento
AcercamientoBottom-Up
Bottom-Up
Buena
Buenapara
parametodologas
metodologas
orientadas
orientadasaaobjetos,
objetos,
Deteccin
Deteccinde
deerrores
erroresde
de
diseo
diseopospuestos
pospuestoshasta
hastaelel
final
finalde
delas
laspruebas,
pruebas,

Componentes
Componentesde
denivel
nivel
superior
superiorusualmente
usualmenteson
son
importantes
importantesyyno
nopuede
puede
restarceles
restarcelesimportancia
importanciahasta
hasta
elelfinal
de
las
pruebas.
final de las pruebas.
Acercamiento
AcercamientoTop-down
Top-down
Los
Loscasos
casosde
deprueba
pruebapueden
pueden
definirse
en
trminos
de
definirse en trminos delala
funcin
funcinexaminada,
examinada,
Requiere
Requieremantener
mantenerlala
correctitud
correctitudde
delas
laspruebas
pruebasque
que
utilizan
utilizanstubs,
stubs,
Escribir
Escribirlos
losstubs
stubspuede
puedeser
ser
complicado.
complicado.

Pruebas de Integracin

Botton-up extensin
de las pruebas de unidad
Botton-up extensin
de las pruebas de unidad

Pruebas de Sistemas
La entrada a la prueba de sistema, es el
sistema conformado por la integracin de la
totalidad de sus componentes.
Las pruebas de sistemas
Son una actividad de verificacin,
Estn focalizadas en las propiedades a nivel
de sistema,
Son realizadas por el equipo de desarrollo,
Validan la utilidad y satisfaccin con el producto, y
Se consideran la culminacin de las pruebas de
integracin.

Pruebas de Sistemas
Las
pruebas
constitudas por
diferentes, cuyo
profundamente el

de
sistemas
estn
una serie de pruebas
propsito es ejercitar
sistema.

Prueba Funcional
Prueba de Estructura
Prueba de Desempeo
Prueba de Aceptancin
Prueba de Instalacin
Etc., (ver PSS0510)

Pruebas de Sistemas
Impacto de los requerimientos en las pruebas de
sistema
Mientras ms explcitos los requerimientos, mas fcil
resultan de probar.
La calidad
de
los
componentes
(en OO
implementados por medio de UML seran los casos de
uso), determina la facilidad para probar la funcionalidad.
La calidad de descompocicin de subsistemas
determina la facilidad para hacer pruebas de estructura.
La calidad de los requerimientos no funcionales y
los no funcionales de restricciones determinan la
facilidad de ejecutar pruebas de desempeo.

Plan Pruebas de
Sistemas
Planificacin
Se construye el Plan de Pruebas de Sistema
definido en la etapa de Requerimientos de
Sistema (o Software) y se documenta en el SVVP.
El SVVP debe cubrir

mbito (para verificar la formalizacin con los objetivos


del sistema establecidos en el SRD), acercamiento,
recursos y calendarizacin de las pruebas de sistema
que se pretende ejecutar .

Debiese definirse una prueba para cada uno de


los requerimientos claves de software o para cada
requerimiento implementado.

Diseo

Plan Pruebas de
Sistemas

Sub-secuencia de los pasos ejecutados en la fase DD (diseo


detallado).
Debe especificar el detalle de las pruebas para cada
requerimiento de software especificado en el SRD e identificar
los casos de prueba asociados y los procedimientos de prueba.
La descripcin del acercamiento debe establecer tipos de
pruebas necesarios.
Pruebas de Seguridad
Tipos de pruebas a considerar:
Prueas de Portabilidad
Pruebas Funcionales
Pruebas de Mantencin
Pruebas de Desempeo
Pruebas de Interfase
Pruebas de Confiabilidad
Pruebas de Operacin
Pruebas de Regresin
Pruebas de Recursos.
Pruebas de Stress
Etc.

Plan Pruebas de
Sistemas

Reporte de Pruebas

Los resultados deben ser reportados y


registrados
Formularios de resultados de pruebas de
EJE
M P LO : C a s o s d e P r u e b a d e C O M PAT I B I L I D A D p a ra S O LU C I N W E B
sistema,
N
Compati
Plataforma
Navegador
Versin
# Si # No
Pruebas
ble
Professional SP3 Microsoft
deInternetregistros
tiempo
Windows XPArchivos
Explorer
7.0 en12
12
0
Si de
Windows XP Professional SP3 Microsoft Internet Explorer
8.0
12
12
0
Si
Windows XPejecucin,
Professional SP3 Mozilla Firefox
3.5
12
12
0
Si
Windows
Windows
SP2
Windows
SP2
Windows
SP2
Windows
SP2

XP Professional SP3 Google Chrome


Vista Home Premium
Microsoft Internet Explorer
Vista Home Premium
Vista Home Premium
Vista Home Premium

3.0

12

12

Si

7.0

12

12

Si

Microsoft Internet Explorer

8.0

12

12

Si

Mozilla Firefox

3.5

12

12

Si

Google Chrome

3.0

12

12

Si

Pruebas de Sistemas
Algunos tipos de pruebas de sistemas
PRUEBA FUNCIONAL

Escencialmente lo mismo que una prueba de caja


blanca.
Objetivo: Probar las funcionalidades del sistema
Los casos de prueba son diseados desde el
documento de anlisis de requerimientos y
centrados en torno a los requerimientos y sus claves
funcionales,
El sistema es tratado como una caja negra,
Los casos de prueba de unidad pueden reutilizarse,
pero al final se debern desarrollar casos de prueba
orientados al usuario.

Pruebas de Sistemas
Algunos tipos de pruebas de sistemas
PRUEBA FUNCIONAL
Ejemplo a nivel de unidad
Asegurar que cada lnea de cdigo es ejecutada
apropiadamente:
Cobertura funcional: cada funcin o mtodo es
ejecutada al menos en un caso de prueba.
Cobertura de declaraciones: cada lnea de
cdigo es cubierta al menos en un caso de
prueba.
Cobertura de caminos: cada posible camino a
travs del cdigo es cubierto por al menos un
caso de prueba.

Pruebas de Sistemas
Algunos
sistemas

tipos

de

pruebas

de

PRUEBA FUNCIONAL
Ejemplo a nivel de integracin
Asegurar que el sistema es integrado con
otros sistemas de manera tal que no los
afecte:
Este tipo de pruebas busca lograr la
interoperabilidad y cooperacin entre
aplicaciones.
Aqu se definen objetivos de prueba
que ejerciten comunicacin.

Pruebas de Sistemas
Algunos
sistemas

tipos

de

pruebas

de

PRUEBA FUNCIONAL
Ejemplo a nivel de Sistemas
Asegurar que todas las funciones son
combinadas
adecuadamente
para
entregar el resultado de negocios
deseado:
Considerar todos los subsistemas que
deben ser probados primero o si todas
las capas de un subsistemas deben ser
probadas antes de ser combinadas.

Pruebas de Sistemas
Algunos tipos de pruebas de sistemas
PRUEBA DE ESTRUCTURA
Esencialmente igual que una prueba de caja blanca
Objetivo: Cubrir el camino del diseo del sistema
Ejercitar todas los parmetros de entrada y
salida para cada componente.
Ejercitar todos los componentes y todas las
llamadas (cada componente es llamado al
menos una vez y todo componente es llamado
por todas las posibles llamadas).
Utilice pruebas condicionales y de iteracin
como pruebas de unidad.

Pruebas de Sistemas
Algunos tipos de pruebas de sistemas
PRUEBAS DE DESEMPEO

Se definen como el proceso para determinar la velocidad o


efectividad de una computadora, red, o dispositivo o
programa de software.
Este proceso involucra pruebas cuantitativas realizadas en
laboratorio:

Considera atributos cualitativos como:

Medidas de tiempo de respuesta,


Clculo del nmero de millones de instrucciones por segundo al cual
funciona un sistema.
Confiabilidad,
Escalabilidad, e
Interoperabilidad.

Considera un conjunto de pruebas de estrs.

Pruebas de Sistemas

Algunos tipos de pruebas de


sistemas
Prueba de Estrs
Estresar los lmites del sistema (mximo # de
usuarios, peak de demandas, operaciones
extendidas)
Prueba de Volumen
Probar que sucede si se manejan grandes
cantidades de datos
Prueba de Configuracin
Probar varias configuraciones de HW y SW
Prueba de Compatibilidad
Probar hacia atrs la compatibilidad con otros
sistemas existentes
Prueba de Seguridad
Tratar de violar los requerimientos de seguridad

Prueba de Tiempo
Evaluar los tiempos de respuesta y de
rendimiento para una funcin
Prueba de medioambiente
Probar la tolerancia al calentamiento,
humedad, moviemiento, portabilidad
Prueba de Calidad
Probar confiabilidad, habilidad de
mantencin y disponibilidad del sistema
Prueba de Recuperacin
Probar la respuesta del sistema ante la
precencia de errores por prdida de datos
Pruebas de Factor Humano
Pruebas de interface con el usuario

PRUEBAS DE DESEMPEO

Definicin Pruebas de
Aceptacin
The
International Software Testing Qualifications
Board
(ISTQB) Standard glossary of terms, version
1.3 (dd. May, 31, 2007), la definicin
sindicada es la siguiente:
"Formal testing with respect to user needs,
requirements,
and
business
processes
conducted to determine whether or not a system
satisfies the acceptance criteria and to enable
the user, customers or other authorized entity to
determine whether or not to accept the system."

Pruebas de aceptacin
Propsito: guiar la decisin de si el producto
en su estado actual debe o no
serseliberado.
Cmo
determina esta
Objetivo: demostrar que el decisin?
sistema se
encuentra listo para su utilizacin operacional:

Errores en la especificacin y en el desarrollo, as como cambios en las


espectativas del usuario, pueden resultar en un producto que no cubra
completamente las necesiades del usuario y an as hubiese pasado
las pruebas de sistemas.
El tipo de pruebas es definido por el cliente/usuario.
La mayora de los bugs en el software son tipicamente encontrados por
el clientes despus de que el sistema se ha puesto en uso, no por los
desarrolladores o los igenieros de pruebas.
Tipos de pruebas: ALFA / BETA

Pruebas de aceptacin
Pruebas ALFA
Se lleban acabo en el lugar de desarrollo con un
stakeholder por parte del cliente y con el desarrollador
como observador, registrando los errores encontrados y
los problemas de uso.
Se ejecutan en entornos controlados. Este tipo de pruebas

Pruebas BETA

determinan SLO perfiles


operacionales

El usuario hace uso del sistema en el lugar de trabajo, y


es este quien anota los errores encontrados.
El desarrollor no se encuentra presente.
Segun los resultados obtenidos, sern las modificaciones
que realizar el desarrollador para preparar una nueva
versin del producto.

Pruebas de aceptacin
Desde la perspectiva de la ESA
Segn el estandar ESA PSS050, las pruebas de
aceptacin se refieren al proceso de probar el
sistema contra los requerimientos de usuario.
La entrada a las pruebas de aceptacin
corresponde al software exitosamente probado a
nivel de sistema.
Plan de Pruebas de Aceptacin:
Es construdo y documentado en el SVVP.
Se define durante la fase UR y debe describir el
mbito, acercamiento, recursos y calendario de las
pruebas de aceptacin que se pretende realizar.

Pruebas de aceptacin
Diseo de Pruebas de Aceptacin:
el diseo de pruebas de aceptacin debe especificar el
detalle de las pruebas de acercamiento para los
requerimientos de usuario, o combinaciones de los
requerimientos de usuario; e identificar los casos de
prueba y procedimientos de prueba asociados.
Aqui no se requiere del conocimiento de cmo trabaja el
software internamente no utilizar pruebas de caja blanca.
La especificacin de requerimientos de usuario (URD) debe
ser dividida en requermientos de capacidad y de restriccin
para el acercamiento de pruebas.
Pruebas de Capacidad
Pruebas de Restriccin

Pruebas de aceptacin
Especificacin de las pruebas de aceptacin:

Los casos de prueba deben ser descritos en el SVVP, especificando


entradas, resultados esperados y las condiciones de ejecucin del
caso de prueba.

Especificacin de los procedimientos de prueba de


aceptacin:

Descrito en el SVVP, debe proporcionar una descripcin paso a paso


de cmo conducir cada uno de los casos de prueba.
El esfurzo requerido por el usuario para validar el software debe ser
minimizado mediante herramientas para pruebas.

Reportes de prueba de aceptacin:

Formularios de registro de resultados de prueba de aceptacin.


Archivos de registro en tiempo de ejecucin (logfile).
Los resultados de las pruebas de aceptacin deben referenciarse en
los Reportes de Problema de Software.

Pruebas de aceptacin
Desventajas
Los usuarios no saben como probar o no son
entrenados para probar el producto de software.
Bajo las restricciones de tiempo, se le entregan al
usuario suit de pruebas que ejecutan los caminos
seguros, y no se ejecutan pruebas exhaustivas o bajo
condiciones interesantes que permitan evidenciar
errores en la funcionalidad.

Consideraciones de Planificacin de Pruebas:


Importante es considerar un pequeo traslapo entre
las pruebas de sistemas y las de aceptacin, de
modo tal de potenciar la ejecucin de las pruebas.

Pruebas de aceptacin
Cul es el error en la propuesta de
acercamiento para pruebas de aceptacin
siguiente?
Voy a darles una breve introduccin de cmo el sistema
funciona. Luego les proporcionare un manual de usuario
y algunos datos de ejemplo (como listados de productos
que han sido previamente ingresados al sistema) y
quisiera que utilicen la aplicacin para completar las
tareas para las cuales la aplicacipon debe ser utilizada.
Miestras
trabajen,
por favor
proporcione informacin
Lo que
debe buscarse
tiene relacin
con:
su experiencia
con de
la acuerdo
aplicacin
enseel
sobre
Los usuarios
del sistema estn
con que
ha formulario
dado
adjunto.
satisfaccin. a las necesidades que ellos plantearon para el sistema?"

Pruebas de aceptacin
No olvidar qu se espera del ingeniero de
pruebas que disea las pruebas de aceptacin,
eso implica que conteste a la interrogante:
Cmo diseo pruebas de aceptacin que satisfagan las
necesidades de la gerencia de proyecto para determinar
si el usuario final estar de acuerdo con que los
requerimientos han sido logrados, a la vez que cumplo
con mi obligacin de capturar la informacin que
requiero para proporcionar una satisfaccin global al
usuario con
LA RESPUESTA
ES: respecto al producto a travs de una
comprensiva
para el
mismo???
evaluacin
Suits de pruebas
altamente
estructuradas,
con scripts
de aceptacin paso a paso por parte del usuario, que
contengan criterios de aprobacin/rechaso especficos y
derivados desde los requerimientos del sistema, de
manera tal que proporcionen el tiempo y mecanismo de
feedback requeridos.

Pruebas de aceptacin
Resumen
Las pruebas de aceptacin verifican la adecuacin a
las necesidades del usuario.
Las pruebas de aceptacin son llebadas a cabo por
grupos de pruebas que involucran usuarios.
Las pruebas de aceptacin verifican la correctitud y
completitud del producto de software.
Las pruebas de aceptacin son una actividad de
validacin que busca lograr, primeramente, la
aceptabilidad del producto; incluye juicios sobre su
utilidad actual y su usabilidad, ms que la
conformidad con los requerimientos de especificacin.

Pruebas de Regresin
Definicin
Es el proceso de probar los cambios para un
programa de computadoras asegurndose de que
el programa antiguo seguir funcionando con los
nuevos cambios.

Estas pruebas son una parte normal del proceso de


desarrollo de un programa, y en compaas grandes,
las llevan a cabo especialistas de prueba.
Antes que una nueva versin del producto de software
sea liberada, los casos de pruebas viejos son
ejecutados contras las nuevas versiones para
asegurarse de que las capacidades antiguas aun
funcionan.

Pruebas de Regresin
Definicin
Corresponde a la ejecucin de un conjunto de
casos de prueba a un programa con el fin de
garantizar que su revisin (y consecuente
mantencin correctiva, adaptativa o evolutiva)
no produce defectos no deseados, que no
implica un retroceso, es decir, se vuelva menos
eficaz que lo que haba sido en el pasado.
Asegura que los cambios hechos durante la
mantencin no destruyan las funcionalidades
existentes.

Pruebas de Regresin
Por qu las pruebas de regresin son un
problema?
Los sistemas grandes pueden tomar MUCHO tiempo
en ser re-testeados.
Puede ser difcil y altamente demandante, en
trminos de tiempo, crear las pruebas.
Puede ser difcil y altamente demandante evaluar
las pruebas

Algunas veces se requiere de ms de una persona en el


loop creativo y que evale los resultados...

Los costos de estas prueba pueden reducir recursos


disponibles para el mejoramiento del software.

Seleccin de Pruebas de
Regresin
La reduccin de costos: seleccionar un sub grupo
Definicin

de la suit de pruebas de regresin que prueben


los cambios.

Objetivo: minimizar los recursos requeridos para las


pruebas de regresin en una nueva versin.

Se logra tpicamente minimizando el nmero de casos de


prueba aplicados a la nueva versin.

Necesario porque

Las suits de pruebas de regresin crecen con cada versin,


resultando en casos de pruebas rotos, obsoletos,
incontrolables y redundantes.

Se deben analizar las relaciones entre los casos de


prueba y los elementos de software a cubrir.
Se debe utilizar la informacin sobre los cambios para
seleccionar los casos de prueba.

Seleccin de Pruebas de
Regresin
Ejemplo

Seleccin de Pruebas de
Regresin
Ejemplo 2

Pruebas de Regresin
Cmo escribir una pruebas de regresin en el
Plan de Pruebas?
Cul es el objetivo de la prueba?

Ayuda a comprender que tipo de riesgos se enfrentarn y


cunto desea cubrirse con la prueba.

Qu riesgos afrontar la prueba de regresin y cules


no?

Basado en el objetivo de la prueba, se determina los riesgos


especficos que sern abordados con la prueba y cuales no.

Qu clase de cobertura se desea para la prueba de


regresin?

Una prueba puede cubrir mltiples riesgos o mltiples reas


de una aplicacin.

Pruebas de Regresin
Cmo escribir una pruebas de regresin en el Plan de Pruebas?

Qu tcnicas se emplearn para ejecutar y mantener las


pruebas?

Establecer qu pruebas sern manuales y cules automatizadas.


En caso de ser automatizadas definir las herramienta a utilizar,
infraestructura, como sern mantenidas a travs del tiempo, etc.

Qu medioambientes son requeridos para ejecutar las


pruebas?

Se ve cul es o son los medioambientes necesarios y cundo


sern requeridos. Qu datos se requiere estn disponibles, como
se administrar, etc.

Cmo reportar el estado de la prueba?

Relativo a la especificacin de los niveles de detalle, que


informacin se requiere primero, etc.

Glossary
Test planning: The activity of establishing or updating
a test plan.
Test plan: A document describing the scope,
approach, resources, and schedule of intended test
activities. It identifies, amongst others, test items,
the features to be tested, the testing tasks, who will
do each task, the degree of tester independence, the
test environment, the test design techniques and
entry and exit criteria to be used and the rationale
for their choice, and any risks requiring contingency
planning. It is a record of the test planning process.

Glossary
Test case: A set of input values, execution preconditions,
expected
results,
and
execution
post-conditions
developed for a particular objective or test condition,
such as to exercise a particular program path or to verify
compliance with a specific requirement.
Test condition: An item or event of a component or
system that could be verified by one or more test cases
(e.g., a function, transaction, feature, quality attribute, or
structural element).
Test execution: The process of running a test on the
component or system under test, producing actual
result(s).

Glossary
Test procedure: A document specifying a
sequence of actions for the execution of a test.
Also known as test script or manual test script.
Test control: A test management task that deals
with developing and applying a set of
corrective actions to get a test project on track
when monitoring shows a deviation from what
was planned.
Test implementation: The process of developing
and prioritizing test procedures, creating test
data, and, optionally, preparing test harnesses
and writing automated test scripts.

Glossary
Test script: Commonly used to refer
to a test procedure specification,
especially an automated one.
Test log: A chronological record of
relevant details about the execution
of tests.
Test
logging:
The
process
of
recording information about tests
executed into a test log.

Glossary
Exit criteria: The set of generic and specific conditions, agreed upon
with the stakeholders, for permitting a process to be officially
completed. The purpose of exit criteria is to prevent a task from
being considered completed when there are still outstanding parts
of the task that have not been finished. Exit criteria are used to
report against and to plan when to stop testing.
Test closure: During the test closure phase of a test process, data is
collected from completed activities to consolidate experience,
testware, facts, and numbers. The test closure phase consists of
finalizing and archiving the testware and evaluating the test
process, including preparation of a test evaluation report.
Test summary report: A document summarizing testing activities
and results. It also contains an evaluation of the corresponding test
items against exit criteria.

You might also like