Apuntes ISTQB Foundation Formandobits

APUNTES ISTQB CTFL
(Certified Tester Foundation

Level)
v. 2014-09 Adaptacin realizada por Formandobits.com

Basada en el Programa de estudio nivel bsico de SSTQB (sstqb.es) ISTQB
(istqb.org)
ISTQB es una marca registrada del International Software Testing
Qualifications Board
Se permite la reproduccin total o parcial de este documento indicando las
referencias indicadas en este apartado.
1
NDICE
1. Principios bsicos del proceso de pruebas..................................................................5
1.1 Por qu es necesario el proceso de pruebas?........................................................5
1.1.1 Contexto de los sistemas software (K1)...........................................................5
1.1.2 Causas de los defectos de software (K2)..........................................................5
1.1.3 Funcin del proceso de pruebas en el desarrollo, mantenimiento y operaciones de
software (K2)......................................................................................................5
1.1.4 Proceso de pruebas y calidad (K2)..................................................................6
1.1.5 Con cuntas pruebas es suficiente? (K2)........................................................6
1.2 En qu consiste el proceso de pruebas? (K2)........................................................6
1.3 Siete principios para las pruebas (K2)...................................................................7
1.4 Proceso bsico de pruebas (K1)...........................................................................8
1.4.1 Planificacin y control de pruebas (K1)............................................................9
1.4.2 Anlisis y diseo de pruebas (K1)...................................................................9
1.4.3 Implementacin y ejecucin de pruebas (K1).................................................10
1.4.4 Evaluacin de los criterios de salida e informes (K1)........................................10
1.4.5 Actividades de cierre de pruebas (K1)...........................................................10
1.5 La psicologa de las pruebas (K2).......................................................................11
1.6 Cdigo deontolgico (K2)..................................................................................11
2. Pruebas durante todo el ciclo de vida del software (K2)..............................................13
2.1 Modelos de desarrollo de software (K2)...............................................................13
2.1.1 Modelo V (Modelo de desarrollo secuencial) (K2).............................................14
2.1.2 Modelo de desarrollo iterativo-incremental (K2)..............................................15
2.1.3 Pruebas en un Modelo de Ciclo de Vida (K2)...................................................15
2.2 Niveles de prueba (K2).....................................................................................15
2.2.1 Pruebas de componente/unitarias (K2)..........................................................17
2.2.2 Pruebas de integracin (K2).........................................................................18
2.2.3 Pruebas de sistema (K2).............................................................................19
2.2.4 Pruebas de aceptacin (K2).........................................................................19
2.3 Tipos de prueba (K2)........................................................................................21
2.3.1 Pruebas de funciones (Pruebas funcionales) (K2)............................................23
2.3.2 Pruebas de caractersticas no funcionales del software (Pruebas no funcionales)
(K2).................................................................................................................23
2.3.3 Pruebas de estructura/arquitectura de software (Pruebas estructurales) (K2)......24
2.3.4 Pruebas asociadas a cambios: Repeticin de pruebas y pruebas de regresin (K2)
.......................................................................................................................24
2.4 Pruebas de mantenimiento (K2).........................................................................25
3. Tcnicas estticas (K2).........................................................................................27
3.1 Las tcnicas estticas y el proceso de pruebas (K2)..............................................27
3.2 Proceso de revisin (K2)...................................................................................28
3.2.1 Actividades de una revisin formal (K1).........................................................29
3.2.2 Funciones y responsabilidades (K1)...............................................................29
3.2.3 Tipos de revisiones (K2)..............................................................................30
3.2.4 Factores de xito de las revisiones (K2).........................................................31
3.3 Anlisis esttico con herramientas (K2)...............................................................32
2
4. Tcnicas de diseo de pruebas (K4)........................................................................35
4.1 El proceso de desarrollo de pruebas (k3).............................................................35
4.2 Categoras de tcnicas de diseo de pruebas (K2) ................................................37
4.3 Tcnicas basadas en la especificacin o tcnicas de caja negra (K3) .......................38
4.3.1 Particin (Clase) de equivalencia (K3)............................................................38
4.3.2 Anlisis de valores lmite (K3)......................................................................39
4.3.3 Pruebas de tabla de decisin (K3).................................................................40
4.3.4 Pruebas de transicin de estado (K3)............................................................40
4.3.5 Pruebas de caso de uso (K2)........................................................................41
4.4 Tcnicas basadas en la estructura o tcnicas de caja blanca (K4)............................42
Antecedentes.....................................................................................................43
4.4.1 Pruebas de sentencias y cobertura (K4).........................................................43
4.4.2 Pruebas de decisin y cobertura (K4)............................................................43
4.4.3 Otras tcnicas basadas en la estructura (K1)..................................................44
4.5 Tcnicas basadas en la experiencia.....................................................................44
4.6 Seleccin de tcnica de prueba (K2)...................................................................45
5 Gestin de pruebas (K3).........................................................................................46
5.1 Organizacin de pruebas (K2)............................................................................46
5.1.1 Organizacin de pruebas e independencia (K2)...............................................46
5.1.2 Tareas del Lder de Pruebas y del Probador (K1)..............................................47
5.2 Planificacin y estimacin de pruebas (k3)...........................................................48

5.2.1 Planificacin de pruebas (k2).......................................................................48
5.2.2 Actividades de planificacin de pruebas (K3)..................................................49
5.2.3 Criterios de entrada (K2).............................................................................50
5.2.4 Criterios de salida (K2)................................................................................50
5.2.5 Estimacin de pruebas (K2).........................................................................50
5.2.6 Estrategia de pruebas, enfoque de pruebas (K2).............................................51
5.3 Seguimiento y control del progreso de las pruebas (K2).........................................52
5.3.1 Seguimiento del progreso de las pruebas (K1)................................................52
5.3.2 Informes de pruebas (K2)............................................................................53
5.3.3 Control de pruebas (K2)..............................................................................53
5.4 Gestin de la configuracin (K2)........................................................................54
5.5 Riesgos y pruebas............................................................................................55
Antecedentes.....................................................................................................55
5.5.1 Riesgos de proyecto (K2) ............................................................................55
5.5.2 Riesgos de producto (K2)............................................................................56
5.6 Gestin de incidencias (K3)...............................................................................57
6 Herramientas de soporte de pruebas (K2).................................................................59
6.1 Tipos de herramientas de pruebas (K2)...............................................................59
6.1.1 Significado y objetivo de las herramientas de soporte de pruebas (K2)...............60
6.1.2 Clasificacin de herramientas de prueba (K2).................................................61
6.1.3 Herramientas de soporte para la gestin de pruebas (K1).................................61
6.1.4 Herramientas de soporte para las pruebas estticas (K1).................................62
3
6.1.5 Herramientas de soporte para la especificacin de prueba (K1).........................62
6.1.6 Herramientas de soporte para la ejecucin y el registro de pruebas (K1)............62
6.1.7 Herramientas de soporte para el rendimiento y la monitorizacin (K1)................63
6.1.8 Herramientas de soporte para necesidades de pruebas especficas (K1)..............63
6.2 Uso efectivo de las herramientas: Ventajas potenciales y riesgos (K2).....................64
6.2.1 Ventajas potenciales y riesgos de las herramientas de soporte de pruebas (para
todas las herramientas) (K2)................................................................................64
6.2.2 Consideraciones especiales para algunos tipos de herramientas (K1)..................65
6.3 Introduccin de una herramienta en una organizacin (K1)....................................66
ANEXO IEEE 829 NORMA PARA LA DOCUMENTACIN DE PRUEBAS SOFTWARE.................68
Secciones plantilla de especificacin de diseo de pruebas........................................68
Secciones plantilla de especificacin de caso de prueba............................................68
Secciones plantilla de especificacin de procedimiento de prueba...............................68
Secciones del plan de pruebas .............................................................................68
Secciones informe de resumen de pruebas ............................................................69
Secciones registro de pruebas .............................................................................69
Informe de transmisin de los tems de pruebas (comnmente llamado notas de
versiones) .......................................................................................................69
Informe de incidencias........................................................................................69
4
1. Principios bsicos del proceso de pruebas
1.1 Por qu es necesario el proceso de pruebas?

Error/Equivoca
Accin humana que produce un resultado incorrecto.
cin
Defecto/Falta/B
Imperfeccin en un componente o sistema que puede causar que el componente o sistema
ug falle al desempear las funciones requeridas, por ejemplo una sentencia o una definicin de
datos incorrectas. Si se localiza un defecto durante una ejecucin puede causar un fallo en el
componente o sistema.
Fallo/Falla
Desviacin del componente o del sistema respecto de prestacin, servicio o resultado
esperado.
Calidad
Grado en el cual un componente, sistema o proceso satisface requisitos especificados y/o
necesidades y expectativas del usuario/cliente.
Riesgo
Factor que puede resultar en futuras consecuencias negativas, expresada normalmente como
impacto y probabilidad.
1.1.1 Contexto de los sistemas software (K1)
Software que no funciona correctamente Prdida de dinero, tiempo, renombre
1.1.2 Causas de los defectos de software (K2)
Persona --- puede cometer un error/equivocacin --- puede producir un

defecto/falta/bug en cdigo o un documento --- si se ejecuta el defecto en cdigo
provoca un comportamiento no esperado: fallo/falla
No todos los defectos dan lugar a fallos (nunca llegan a ejecutarse/descubrirse).
Causas defectos:
o Las personas somos falibles + trabajo bajo presin.
o Complejidad del cdigo/infraestructuras.
o Tecnologas cambiantes
o
Adems, se pueden producir fallos por condiciones medioambientales: radiacin,
magnetismo, contaminacin, modifican las condiciones del hardware afectando a
sistemas / ejecucin de software.
1.1.3 Funcin del proceso de pruebas en el desarrollo, mantenimiento y

operaciones de software (K2)
Pruebas rigurosas:
o Reducen el riesgo de fallo (si los defectos se detectan y corrigen antes de la
operacin del sistema).
5
o Tambin para: cumplir requisitos contractuales o legales, estndares
especficos del sector,
1.1.4 Proceso de pruebas y calidad (K2)

Calidad: El grado en el cual un componente, un sistema o un proceso cumple los
requisitos especificados y/o las necesidades y las expectativas del usuario/cliente.
Pruebas miden la calidad software: se puede medir en trminos de los defectos
detectados respecto a requisitos, caractersticas funcionales y no funcionales.
o ISO 9126 / ISO 25000: Calidad de producto software (cataloga las
caractersticas del software).
Si las pruebas detectan pocos o ningn defecto: aportan fiabilidad a la calidad del
software.
o Si una prueba se pasa correctamente: reduce el nivel de riesgo de un
sistema.
o Si las pruebas detectan defectos: su correccin incrementa la calidad
software.
Aseguramiento/garanta de la calidad:
o Mejora de procesos al entender las causas raz de los defectos detectados en
proyectos previos.
o Integra actividades de pruebas, desarrollo de estndares, formacin y
anlisis de defectos.
1.1.5 Con cuntas pruebas es suficiente? (K2)

Hay que tener en cuenta:
o Niveles de riesgo (tcnicos, de seguridad, comerciales,).
o Limitaciones del proyecto (tiempo, presupuesto).
Las pruebas deben aportar informacin a los interesados para:
o Tomar decisiones sobre el lanzamiento del software / entrega a los clientes.
o Pasar a la siguiente fase de desarrollo.
1.2 En qu consiste el proceso de pruebas? (K2)

Depuracin
Proceso de encontrar, analizar y eliminar las causas de los fallos en el software.
Requisito
Condicin o capacidad necesaria para un usuario con el objeto de solucionar un
problema o lograr un objetivo que debe ser alcanzado o posedo por un sistema o
componente de un sistema, para satisfacer un contrato, estndar, especificacin u
otro documento impuesto formalmente.
Revisin
Evaluacin de un producto o del estado de un proyecto para detectar discrepancias
con los resultados planificados y para recomendar mejoras. Algunos ejemplos:
revisin de gestin, revisin informal, revisin tcnica, inspeccin y revisin guiada.
Caso de prueba
Conjunto de valores de entrada, precondiciones de ejecucin, resultados esperados y
postcondiciones de ejecucin, desarrollado con un objetivo en particular o condicin
de prueba, tales como probar un determinado camino de ejecucin o para verificar el
cumplimiento de un requisito determinado.
Probar/Pruebas
Proceso que consiste en todas las actividades del ciclo de vida software, tanto
estticas como dinmicas, concernientes con la planificacin, preparacin y
evaluacin de productos software y los productos de trabajo relacionados para
determinar que stos satisfacen los requisitos especificados, para demostrar que se
ajustan al propsito y para detectar defectos.
6
Objetivo de prueba
Razn o propsito para el diseo y la ejecucin de una prueba.
Proceso de pruebas: no solo ejecutar pruebas, sino tambin todas las actividades
que se dan antes y despus (planificacin y control, elaboracin de informes) as
como otro tipo de actividades (revisin de documentos incluyendo el cdigo fuente-,
anlisis estticos,).
Objetivos (posibles) del proceso de pruebas:
o 1) Identificar defectos (por ejemplo, en las pruebas durante el desarrollo).
o 2) Aumentar la confianza en el nivel de calidad (por ejemplo, en las
pruebas de aceptacin, donde se corrobora que el sistema se ajusta a los
requisitos previstos).
o 3) Facilitar informacin para la toma de decisiones (por ejemplo, para
evaluar la calidad del software -sin intencin de arreglar defectos- o medir el
riesgo de lanzar el sistema en un momento dado).
o 4) (Prevenir) Evitar la aparicin de defectos (por ejemplo, en la revisin
de documentos como los requisitos- o la identificacin y subsanacin de
problemas).
Diferencia entre el proceso de depuracin y el proceso de pruebas:
o Las pruebas dinmicas pueden identificar aquellos fallos que han sido
provocados por defectos (es responsabilidad del probador).
o Depuracin: Actividad de desarrollo que localiza, analiza y elimina la causa
del fallo (es responsabilidad del desarrollador).
o La posterior repeticin de las pruebas (por parte del probador) garantiza que
la correccin llevada a cabo realmente elimina el fallo).
1.3 Siete principios para las pruebas (K2)
Pruebas exhaustivas
Enfoque de pruebas donde el conjunto de pruebas abarca todas las combinaciones
de valores de entrada y precondiciones.
1. Las pruebas demuestran la presencia de defectos.

Pero no pueden demostrar que no los hay: que no se detecte ningn defecto
no es evidencia de correccin.
Reducen la probabilidad de que haya defectos.
2. Las pruebas exhaustivas no existen.
Probar todo (pruebas exhaustivas: todas las combinaciones de
entradas y precondiciones) es imposible (salvo en casos triviales).
Anlisis de riesgos y prioridades para centralizar los esfuerzos de las
pruebas.
3. Pruebas tempranas.
Se deben identificar los defectos en una etapa temprana: se iniciarn las
pruebas lo antes posible en el ciclo de vida del software.
4. Agrupacin de defectos.
La mayora de defectos detectados durante las pruebas previas al
lanzamiento y la mayora de fallos operativos se concentran en un nmero
reducido de mdulos.
Las pruebas deben concentrarse de manera proporcional en la densidad
esperada, y ms tarde observada, de los defectos de los mdulos.
5. Paradoja del pesticida.
Si repetimos las mismas pruebas una y otra vez, eventualmente la misma
serie de casos de prueba dejar de encontrar defectos nuevos.
Los casos de prueba deben revisarse peridicamente y deben escribirse
pruebas nuevas y diferentes para ejercitar distintas partes del software o del
sistema con vistas a poder detectar ms defectos.
7
6. Las pruebas dependen del contexto.
Las pruebas se llevan a cabo de manera diferente segn el contexto (la
forma de probar un software crtico para la seguridad variar de la de un sitio
de comercio electrnico).
7. Falacia de la ausencia de errores
La deteccin y correccin de defectos no servir de nada si el sistema
construido no es usable y no cumple las expectativas y necesidades de los
usuarios.
1.4 Proceso bsico de pruebas (K1)

Pruebas de confirmacin
Pruebas que ejecutan aquellos casos de prueba que hubieran fallado la ltima vez
/ Repeticin de pruebas que fueran ejecutados con el objetivo de verificar el xito de acciones correctivas.
Criterios de salida
Conjunto de condiciones genricas y especficas, acordadas con los involucrados en
el proyecto, para permitir que un proceso sea considerado concluido oficialmente. El
propsito de los criterios de salida es evitar que una tarea se considere concluida
cuando existen partes de la tarea pendientes que no hayan sido finalizadas. Los
criterios de salida son utilizados para planificar cundo parar las pruebas e informar
sobre esto.
Incidencia
Cualquier ocurrencia de un suceso que requiere investigacin
Pruebas de regresin
Pruebas de un programa previamente probado que ha sufrido modificaciones, para
asegurarse que no se han introducido o descubierto defectos en reas del software
que no han sido modificadas como resultado de los cambios realizados. Se realiza
cuando el software o su entorno han sido modificados.
Base de prueba
Todos los documentos de donde los requisitos de un componente o sistema pueden
ser inferidos. La documentacin en la que se basan los casos de prueba. Si un
documento puede ser modificado slo por medio de un procedimiento de cambio
formal, entonces la base de las pruebas se denomina base de prueba congelada.
Condicin de prueba
Elemento o evento de un componente o sistema que debera ser verificado por uno o
ms casos de prueba, por ejemplo una funcin, transaccin, caracterstica, atributo
de calidad o elemento estructural.
Cobertura de pruebas
Grado, expresado como un porcentaje, en el que un elemento de cobertura
especificado ha sido practicado por un juego de pruebas.
Datos de prueba
Datos que existen (por ejemplo en una base de datos) antes de que una prueba sea
ejecutada y que afectan o son afectados por el componente o sistema en pruebas.
Ejecucin de pruebas
Proceso de practicar una prueba sobre el componente o sistema en pruebas,
produciendo resultado(s) reales.
Registro de pruebas
Registro cronolgico de los detalles relevantes respecto a la ejecucin de pruebas.
Plan de pruebas
Documento que describe el alcance, enfoque, los recursos y planificacin de las
actividades de pruebas previstas. Identifica, entre otros, los elementos de prueba, las
prestaciones a ser probadas, las tareas de pruebas, quien realiza cada tarea, el
grado de independencia del probador, el entorno de pruebas, las tcnicas de diseo
de pruebas y los criterios de entrada y salida a utilizar, y los motivos para cada
eleccin, y cualquier riesgo que requiera un plan de contingencia. Es un registro del
proceso de planificacin de pruebas.
8
(Especificacin de)
Documento que especifica la secuencia de acciones para la ejecucin de una
Procedimiento de prueba. Tambin conocido como script de prueba o script de prueba manual.
pruebas
Poltica de pruebas
Documento de alto nivel que describe los principios, el enfoque y los principales
objetivos de la organizacin en lo referente a las pruebas.
Conjunto/Juego de
Conjunto de casos de prueba para un componente o sistema en pruebas, donde la
(casos de) prueba poscondicin de una prueba es a menudo usada como precondicin de la siguiente.
Informe resumen de
Documento que resume las actividades y resultados de las pruebas. Tambin
pruebas contiene una evaluacin de los correspondientes elementos de prueba respecto de
los criterios de salida.
Producto de soporte de
Artefactos producidos durante el proceso de pruebas necesarios para la
prueba (testware) planificacin, el diseo y la ejecucin pruebas, tales como la documentacin, scripts,
entradas, resultados esperados, procedimientos de configuracin y despejado,
archivos, bases de datos, entorno y cualquier software o utilidades adicionales
utilizadas en pruebas.
Arns de pruebas
Entorno de pruebas constituido por stubs y controladores necesarios para llevar a
cabo una prueba.
Actividades principales (pueden solaparse):

1. Planificacin y control.
2. Anlisis y diseo.
3. Implementacin y ejecucin.
4. Evaluacin de los criterios de salida e informes.
5. Actividades de cierre de pruebas.
1.4.1 Planificacin y control de pruebas (K1)
Planificacin de pruebas: Actividad de definir los objetivos de las pruebas y la

especificacin de las actividades de pruebas con vistas a cumplir estos objetivos.
Control de pruebas: Actividad constante de comparar el progreso real con el plan
previsto, e informar sobre el estado de las pruebas (incluyendo desviaciones sobre lo
planificado).
o Implica la adopcin de medidas necesarias para cumplir los objetivos del
proyecto (la planificacin de pruebas tiene en cuenta el feedback de la
actividad de control).
1.4.2 Anlisis y diseo de pruebas (K1)

Actividad durante la cual los objetivos de las pruebas se transforman en condiciones
de prueba y casos de prueba tangibles.
Tareas principales:
1. Revisar la base de pruebas (Todos los documentos de donde los requisitos de
un componente o sistema pueden ser inferidos. La documentacin en la que
se basan los casos de prueba).
2. Evaluar la testabilidad de la base de prueba y de los objetos de prueba.
3. Identificar y priorizar las condiciones de prueba.
4. Disear y priorizar los casos de prueba de alto nivel.
5. Identificar los datos de prueba necesarios para soportar las condiciones de
prueba y los casos de prueba.
6. Disear la configuracin del entorno de pruebas e identificar cualquier
infraestructura y herramientas necesarias.
7. Crear una trazabilidad bidireccional entre la base de pruebas y los casos de
prueba.
9
1.4.3 Implementacin y ejecucin de pruebas (K1)
Actividad en la que se especifican los procedimientos o guiones de prueba mediante
la combinacin de los casos de prueba en un orden determinado y la inclusin de
cualquier otra informacin necesaria para la ejecucin de las pruebas, se configura el
entorno y se ejecutan las pruebas.
Tareas principales:
1. Finalizar, implementar y priorizar los casos de prueba (incluyendo la
identificacin de los datos de prueba).
2. Desarrollar y priorizar procedimientos de prueba, crear datos de prueba y, de
manera opcional, preparar arneses de pruebas y redactar guiones de prueba
automatizados.
3. Crear juegos de pruebas a partir de los procedimientos de prueba para lograr
una ejecucin de pruebas eficiente.
4. Verificar que el entorno de pruebas ha sido correctamente configurado.
5. Verificar y actualizar una trazabilidad bidireccional entre la base de pruebas y
los casos de prueba.
6. Ejecutar los procedimientos de prueba manualmente o recurriendo a
herramientas de ejecucin de pruebas, conforme a la secuencia prevista.
7. Registrar los resultados de la ejecucin de las pruebas y registrar las
identidades y las versiones del software probado, as como las herramientas
de prueba y los productos de soporte de pruebas.
8. Comparar los resultados reales con los resultados esperados.
9. Reportar las discrepancias en forma de incidencias y analizarlas con vistas a
establecer sus causas (por ejemplo, defectos en el cdigo, defectos en
documentos de prueba,).
10. Repetir las actividades de pruebas como resultado de una medida adoptada
para cada discrepancia (por ejemplo, la repeticin de una prueba que ha
fallado anteriormente con vistas a confirmar su correccin pruebas de
confirmacin -; la ejecucin de una prueba corregida y/o la ejecucin de
pruebas con vistas a garantizar que los defectos no se han introducido en
reas no modificadas del software o que la subsanacin del defecto no ha
revelado la existencia de otros defectos pruebas de regresin-).
1.4.4 Evaluacin de los criterios de salida e informes (K1)

Actividad que evala la ejecucin de pruebas (para cada nivel de prueba) contra los
objetivos definidos.
Tareas principales:
1. Comprobar los registros de pruebas con los criterios de salida previstos en la
planificacin de la prueba.
2. Evaluar si se requieren ms pruebas o si deberan modificarse los criterios de
salida especificados.
3. Elaborar un resumen de las pruebas para las partes interesadas.
1.4.5 Actividades de cierre de pruebas (K1)

Recopilacin de los datos de aquellas actividades de pruebas finalizadas con el
objetivo de consolidar la experiencia, los productos de soporte de pruebas, los
hechos y las cifras.
Tienen lugar en los hitos del proyecto (lanzamiento de un sistema software,
finalizacin/anulacin de un proyecto de pruebas,).
Tareas principales:
1. Comprobar cules de los productos entregables previstos han sido
efectivamente entregados.
2. Cerrar los informes de incidencias o aportar modificaciones a aquellos que
siguen abiertos.
3. Documentar la aceptacin del sistema.
4. Finalizar y archivar los productos de soporte de prueba, el entorno de
pruebas y la infraestructura de pruebas para su posterior uso.
5. Entregar los productos de soporte de prueba a la organizacin de
mantenimiento.
6. Analizar las lecciones aprendidas para determinar los cambios necesarios en
futuras versiones y proyectos.
7. Utilizar la informacin recopilada para mejorar la madurez de las pruebas.
10
1.5 La psicologa de las pruebas (K2)
Prediccin de error
Tcnica de diseo de pruebas donde la experiencia de quien prueba es utilizada para
anticipar qu defectos podran estar presentes en el componente o sistema en prueba
como resultado de los errores cometidos, y disear pruebas especficas para ponerlos
al descubierto.
Independencia (de
Separacin de responsabilidades, que fomenta la realizacin de pruebas objetivas.
pruebas)
Principio de segregacin de tareas / Independencia de las pruebas: quien prueba o

revisa es diferente al que desarrolla.
La independencia de las pruebas VS conocimiento del trabajo: ser independiente no
garantiza efectividad a la hora de detectar defectos.
Diferentes niveles de independencia (de menor a mayor):
o Pruebas diseadas por las mismas personas que escribieron el software.
o Pruebas diseadas por otros miembros del mismo equipo de desarrollo.
o Pruebas diseadas por una persona de otro grupo de la organizacin (por
ejemplo, un equipo de pruebas independiente o un especialista de la
organizacin en pruebas de usabilidad o rendimiento).
o Pruebas diseadas por personas de otra organizacin o empresa
(externalizacin o certificacin por parte de un organismo externo).
Es importante establecer los objetivos de las pruebas: las personas tienden a ajustar
sus planes a los objetivos establecidos (detectar errores? Confirmar el cumplimiento
de requisitos?).
El proceso de pruebas a menudo se considera una actividad destructiva (como una
crtica contra el producto o el autor), pero es una actividad constructiva para la
gestin de los riesgos del producto.
Un probador requiere curiosidad, pesimismo profesional, ojo crtico, atencin al
detalle, buena comunicacin con los compaeros de desarrollo y experiencia sobre la
que basar la prediccin de error.
Hay que comunicar los errores, defectos o fallos de manera constructiva para evitar
malentendidos.
Formas de mejorar la comunicacin y relaciones entre los probadores y los dems:
1. Empezar juntos en lugar de enfrentados: existe un objetivo comn que
es conseguir sistemas de mejor calidad.
2. Comunicar los hallazgos del producto de una manera neutral y centrada
en los hechos, sin criticar a las personas que lo crearon, por ejemplo,
redactando informes de incidencias objetivos y revisando las
conclusiones.
3. Intentar comprender cmo se siente la otra persona y porqu reacciona
de esa manera.
4. Confirmar que la otra persona ha entendido lo que usted ha dicho y
viceversa.
1.6 Cdigo deontolgico (K2)
PBLICO: Los probadores de software certificados actuarn en coherencia con el

inters pblico.
CLIENTE Y EMPLEADOR: Los probadores de software certificados actuarn en el
mejor de los intereses de su cliente y empleador, en coherencia con el inters
pblico.
PRODUCTO: Los probadores de software certificados garantizarn que los productos
entregables que proporcionan (por lo que respecta a los productos y sistemas que
prueban) se ajustan los ms altos estndares profesionales.
CRITERIO: Los probadores de software certificados mantendrn la integridad y la
independencia en su criterio profesional.
GESTIN: Los jefes y lderes de pruebas de software certificados suscribirn y
fomentarn un enfoque tico en la gestin de las pruebas de software.
11
PROFESIN: Los probadores de software certificados aumentarn la integridad y la
reputacin de la profesin en coherencia con el inters pblico.
COMPAEROS: Los probadores de software certificados sern equitativos y
apoyarn a sus compaeros fomentando la cooperacin con los desarrolladores de
software.
NIVEL INDIVIDUAL: Los probadores de software certificados participarn en un
aprendizaje a lo largo de toda la vida por lo que respecta a la prctica de su
profesin y fomentarn la adopcin de un enfoque tico en la prctica de su
profesin.
12
2. Pruebas durante todo el ciclo de vida del software
(K2)
2.1 Modelos de desarrollo de software (K2)
Software de distribucin
Producto software que es desarrollado para el mercado general, por ejemplo, para
masiva (COTS - un gran nmero de clientes, y es distribuido a muchos clientes en formato idntico.
Commercial Off-The-Shelf
software)
Modelo en V (Modelo de
Marco de trabajo para describir las actividades del ciclo de vida de desarrollo
desarrollo secuencial) software desde la especificacin de requisitos hasta el mantenimiento. El modelo-V
ilustra cmo las actividades de del proceso de pruebas pueden ser integradas
dentro de cada fase del ciclo de vida de desarrollo software.
Modelo de desarrollo
Ciclo de vida del desarrollo donde un proyecto es dividido en un nmero de
iterativo iteraciones, generalmente grande. Una iteracin es un ciclo completo de desarrollo
que tiene como resultado una entrega (interna o externa) de un producto
ejecutable, un subconjunto del producto final en desarrollo, que crece de iteracin
en iteracin para convertirse en el producto final.
Modelo de desarrollo
Ciclo de vida de desarrollo software en el cual un proyecto es descompuesto en una
incremental serie de incrementos, cada uno de los cuales suministra una porcin de la
funcionalidad respecto de la totalidad de los requisitos del proyecto. Los requisitos
tienen asignada una prioridad y son entregados segn el orden de prioridad en el
incremento correspondiente. En algunas (pero no en todas) versiones de este
modelo de ciclo de vida, cada subproyecto sigue un mini-modelo V con sus
propias fases de diseo, codificacin y pruebas.
Verificacin Verificacin: Confirmacin por examen y a travs de la

aportacin de evidencia objetiva que se han satisfecho los
requisitos especificados.
Buscar defectos en el sistema, basndose en los

entregables de las fases, comprobando que hemos
seguido el proceso correctamente.
Estamos construyendo el sistema correctamente?
Validacin Validacin: Confirmacin por examen y a travs de la

aportacin de evidencia objetiva que han sido satisfechos
los requisitos para un uso o aplicacin previstos.
Buscar defectos en el sistema, basndose en los

entregables de las fases, comprobando que el sistema
tiene calidad desde la perspectiva del cliente.
Estamos construyendo el sistema correcto?
13
2.1.1 Modelo V (Modelo de desarrollo secuencial) (K2)
Se basa en cuatro niveles de pruebas correspondientes a los cuatro niveles de

desarrollo:
1. Pruebas de componente/unitarias.
2. Pruebas de integracin.
3. Pruebas de sistema.
4. Pruebas de aceptacin.
Base de pruebas de un nivel (o varios niveles) de pruebas: productos de
trabajo de software que se elaboran en la fase de desarrollo (casos de uso,
especificaciones requeridas, documentos de diseo, cdigo fuente, ).
o Referencias a productos de trabajo genricos: Capability Maturity Model
Integration (CMMI) o norma de 'Procesos del ciclo de vida del software'
(IEEE/IEC 12207).
14
o Niveles CMMI:
1. Inicial: proyectos imprevisibles, controlados incorrectamente,
reactivos.
2. Gestionado: Procesos establecidos a nivel de proyecto pero a
menudo reactivamente.
3. Definido: Procesos establecidos a travs de la organizacin y por
lo general proactivamente.
4. Gestionado cuantitativamente: Los procesos son medidos y
controlados en el nivel de la organizacin.
5. Optimizacin: Enfoque en la mejora continua, generalmente
dirigido por datos.
o Secciones IEEE/IEC 12207:
1. Alcance
2. Referencias normativas
3. Definiciones
4. Aplicacin del estndar a los procesos del ciclo de vida,
incluyendo su adaptacin y ajuste a la organizacin.
5. Los procesos principales del ciclo de vida para la adquisicin,
el suministro, el desarrollo, la operacin y el mantenimiento.
6. Los procesos de apoyo (publicaciones tcnicas, gestin de la
configuracin, el aseguramiento de la calidad, la verificacin y
validacin, las auditoras y la resolucin de problemas.
7. Los procesos del ciclo de vida organizacional como la gestin,
la infraestructura, el mejoramiento y la capacitacin.
La verificacin y validacin (y el diseo temprano de pruebas) pueden realizarse
durante el desarrollo de los productos de trabajo de software.
2.1.2 Modelo de desarrollo iterativo-incremental (K2)
Desarrollo iterativo-incremental: proceso de establecer requisitos, disear,

establecer y probar un sistema, realizado como una serie de ciclos de desarrollo ms
cortos (iteraciones que producen incrementos).
o Ejemplos: Prototipado, Rapid Application Development (RAD), Rational
Unified Process (RUP) y modelos de desarrollo gil.
Ejecucin de diferentes niveles de pruebas:
o Durante cada iteracin (incremento en desarrollo).
o Al finalizar cada iteracin (incremento finalizado).
Avanzando en las iteraciones: pruebas de regresin cada vez ms importantes.
Procesos de verificacin y validacin: Pueden llevarse a cabo para cada
incremento.
2.1.3 Pruebas en un Modelo de Ciclo de Vida (K2)

Buenas prcticas en pruebas (independientemente del modelo de ciclo de vida):
1. Para cada actividad de desarrollo existe una actividad de prueba
asociada.
2. Cada nivel de prueba tiene objetivos de prueba especficos para dicho
nivel.
3. Los procesos de anlisis y diseo de las pruebas para un nivel de prueba
dado deben iniciarse durante la actividad de desarrollo correspondiente.
4. Los probadores deben iniciar su participacin en la revisin de los
documentos en cuanto haya borradores disponibles en el ciclo de vida de
desarrollo.
5. Los niveles de pruebas pueden combinarse o reorganizarse (quin hace
cada prueba?) en funcin de la naturaleza del proyecto o de la
arquitectura del sistema.
2.2 Niveles de prueba (K2)

Pruebas
Pruebas dirigidas a evaluar a un componente o sistema en su entorno de operaciones.
operacionales/operati
15
vas
Pruebas alfa
Pruebas simuladas u operacionales realizadas por usuarios/clientes potenciales o por
un equipo de pruebas independiente en las dependencias de desarrollo, pero fuera de
la organizacin de desarrollo. Las pruebas alfa son utilizadas con frecuencia para
software de distribucin masiva como una forma de pruebas de aceptacin internas.
Pruebas beta/Pruebas
de campo
Pruebas operacionales realizadas por usuarios/clientes potenciales y/o existentes, en
un sitio externo no relacionado de ninguna manera con los desarrolladores, para
determinar si un componente o sistema satisface o no las necesidades del
usuario/cliente y se ajusta a los procesos de negocio. Con frecuencia las pruebas beta
se emplean como una forma de prueba de aceptacin externa para software de
distribucin masiva con el objetivo de obtener la respuesta del mercado.
Pruebas de
Pruebas de componentes software individuales.
componente/unitarias
Controlador (Driver)
Componente software o herramienta de pruebas que sustituye a un componente que
asume el control y/o la invocacin a un componente o sistema.
Stub
Implantacin estructural (esqueleto) o de propsito especial de un componente
software, usado para desarrollar o probar un componente que es dependiente de l de
algn modo. Sustituye a un componente llamado.
Arns de pruebas
Entorno de pruebas constituido por stubs y controladores necesarios para llevar a cabo
una prueba.
Requisito funcional
Requisito que especifica una funcin que un componente o sistema debe cumplir.
Integracin
Proceso de combinar componentes o sistemas en estructuras ms amplias.
Pruebas de
Pruebas realizadas con el objeto de poner en evidencia defectos en las interfaces e
integracin interacciones entre componentes o sistemas integrados. Vase tambin pruebas de
integracin de componente, pruebas de integracin de sistema.
Requisito no funcional
Pruebas de atributos de un componente o sistema que no se refieren a la funcionalidad,
por ejemplo fiabilidad, eficiencia, usabilidad, mantenibilidad y portabilidad.
Pruebas de robustez
Pruebas para determinar la robustez de un producto software.
Robustez:
Grado en el cual un componente o sistema puede funcionar correctamente en

presencia de entradas no vlidas o condiciones de entorno de estrs. Vase tambin
tolerancia al error, tolerancia a faltas.
Tolerancia al error:
Capacidad de un sistema o componente para continuar su operacin normal a pesar de

la presencia de entradas errneas.
Tolerancia a faltas:
Capacidad del producto software para mantener un nivel especificado de rendimiento

en caso de producirse faltas (defectos) en el software o infraccin de su interfaz
especificada. Vase tambin fiabilidad, robustez.
Fiabilidad
Habilidad de un producto software para llevar a cabo aquellas funciones requeridas en
condiciones establecidas para un perodo de tiempo especfico, o para un nmero
16
especfico de operaciones.
Pruebas de sistema
El proceso de pruebas un sistema integrado para verificar que cumple los requisitos
especificados.
Entorno de pruebas
Entorno que contiene hardware, instrumentacin, simuladores, herramientas sofware y
otros elementos de soporte necesarios para realizar una prueba.
Nivel de prueba
Grupo de actividades que estn organizadas y gestionadas de forma conjunta. Un nivel
de prueba esta vinculado con las responsabilidades en un proyecto. Ejemplos de
niveles de pruebas son las pruebas de componente, pruebas de integracin, pruebas
de sistema y pruebas de aceptacin.
Desarrollo guiado por

Modalidad de desarrollo software donde los casos de prueba son desarrollados, y a
pruebas (TDD) menudo automatizados, antes de que el software sea desarrollado para ejecutar esos
casos de prueba.
Pruebas de
Pruebas formales con respecto a las necesidades de usuario, requisitos y procesos de
aceptacin de usuario negocio dirigidas a determinar si el sistema satisface o no los criterios de aceptacin y a
habilitar al usuario, cliente u otra entidad autorizada a determinar si acepta o no el
sistema.
Simulador
Dispositivo, programa o sistema usado durante las pruebas, que se comporta u opera
como un sistema dado cuando se le proporciona un conjunto de entradas controladas.
Antecedentes
Caractersticas de un nivel de pruebas:

o Objetivos generales.
o Base de pruebas: productos de trabajo a los que se hace referencia para
derivar los casos de prueba.
o Objeto de la prueba: lo que se est probando.
o Defectos y fallos tpicos a detectar.
o Requisitos de arns de pruebas y soporte de herramientas
o Enfoques especficos y responsabilidades.
2.2.1 Pruebas de componente/unitarias (K2)
Objetivos generales: Localizar defectos y comprobar el funcionamiento de mdulos

de software, programas, objetos, clases, etc., que pueden probarse por separado.
o Pueden utilizarse stubs, controladores y simuladores.
Base de pruebas:
o Requisitos de componentes.
o Diseo del software.
o Modelo de datos.
o Cdigo.
Objeto de la prueba:
o Componentes.
o Programas.
o Conversin de datos / programas de migracin.
o Mdulos de base de datos.
Tipos de pruebas:
o Pruebas de funcionalidad.
o Pruebas no funcionales (por ejemplo, uso de memoria).
o Pruebas estructurales (por ejemplo, cobertura de decisin)
17
Requisitos de arns de pruebas y soporte de herramientas:
o Acceso al cdigo objetivo de las pruebas.
o Soporte de un entorno de desarrollo (marco de pruebas de unidad,
herramienta de depuracin).
Enfoques especficos y responsabilidades:
o Participacin del programador que escribi el cdigo.
o Los defectos se corrigen en el momento en que se detectan, sin gestionarlos
formalmente.
o Desarrollo guiado por las pruebas (Test Driven Development TDD):
Primero se elaboran y automatizan los casos de prueba y despus se
desarrolla el cdigo objeto de las pruebas.
Enfoque altamente iterativo:
1. Ciclos de desarrollo de casos de prueba.
2. Construir e integrar pequeas partes del cdigo.
3. Ejecutar las pruebas de componente.
4. Corregir problemas e iterar hasta que se superen
todos los casos de prueba.
2.2.2 Pruebas de integracin (K2)
Objetivos generales: Se ocupan de probar las interfaces entre los componentes,

las interacciones con distintas partes de un mismo sistema (como el sistema de
archivos o una base de datos) y las interfaces entre varios sistemas.
Base de pruebas:
o Diseo de software y sistema.
o Arquitectura.
o Flujos de trabajo.
o Casos de uso.
o Implementacin de bases de datos de subsistemas.
o Infraestructura.
o Interfaces.
o Datos de configuracin del sistema.
Tipos de pruebas:
o Diferentes niveles que se ocupan de objetos de pruebas de diferente tamao:
o Pruebas de integracin de componentes: Prueban las
interacciones entre los componentes del software y se realizan a
continuacin de las pruebas de componente.
o Pruebas de integracin de sistema: Prueban las interacciones
entre los distintos sistemas (o entre el hardware y el software), y
pueden realizarse a continuacin de las pruebas de sistema.
o Funcionales/No funcionales (por ej. rendimiento)/Estructurales.
o Estrategias de integracin sistemticas pueden basarse en:
o Arquitectura de sistema (top-down, bottom-up).
o Tareas funcionales.
o Secuencias de procesamiento de transacciones.
o
o Para facilitar el aislamiento de fallos y realizar una deteccin temprana de los
defectos: integracin incremental en lugar de tipo big bang (todo a la vez).
o En cada fase de integracin los probadores deben concentrarse
exclusivamente en la propia integracin (por ejemplo, en la comunicacin
entre mdulos, no en la funcionalidad del mdulo individual que ya se prob
en las pruebas de componente.
o (Idealmente) Los probadores deben entender la arquitectura y modificar la
planificacin de la integracin en consecuencia.
Si las pruebas de integracin se planifican antes de construir los
componentes o sistemas, dichos componentes pueden construirse en
el orden necesario para que las pruebas sean lo ms eficientes
posibles.
18
2.2.3 Pruebas de sistema (K2)
Objetivos generales: Probar el comportamiento global de un sistema/producto a

partir de un alcance claramente indicado en el Plan Maestro de Pruebas y/o en el
Plan de pruebas de Nivel para cada nivel de prueba.
Base de pruebas:
o Especificacin de requisitos del sistema y software.
o Casos de uso / Especificaciones funcionales.
o Informes de anlisis de riesgos.
o Manuales de sistema, usuario y funcionamiento.
o Configuracin del sistema.
Tipos de pruebas:
o Pruebas basadas en:

Riesgos y/o especificaciones de requisitos.
Procesos de negocio.
Casos de uso.
Otras descripciones textuales de alto nivel o modelos de
comportamiento de sistema.
o Pruebas funcionales / no funcionales (para cubrir los requisitos de cada tipo).
Pruebas funcionales:
Tcnicas basadas en la especificacin (caja negra):
Utilizacin de tablas de decisin (combinaciones de los
efectos descritos en las normas de negocio).
o Tcnicas basadas en la estructura (caja blanca): Evaluacin de la
exhaustividad de las pruebas por lo que respecta a un elemento estructural
(por ejemplo, una estructura de men o la navegacin de una pgina Web).
o El entorno de pruebas debe coincidir en la mxima medida posible con el
objetivo final o con el entorno de produccin (se busca minimizar el riesgo de
no identificar fallos especficos del entorno durante las pruebas).
o Problema: Los probadores se enfrentan a requisitos incompletos o no
documentados.
o A menudo las pruebas de sistema las realiza un equipo de pruebas
independiente.
2.2.4 Pruebas de aceptacin (K2)
Objetivos generales: Crear confianza en el sistema, partes del sistema o

caractersticas especficas no funcionales del sistema.
o No tienen como objetivo localizar defectos.
o Evalan la buena disposicin de un sistema para su despliegue y uso.
o No tienen porque constituir necesariamente el ltimo nivel de prueba:
Las pruebas de aceptacin de un sistema pueden estar seguidas de
una prueba de integracin del sistema a gran escala.
Base de pruebas:
o Requisitos del usuario.
o Requisitos del sistema.
o Casos de uso.
o Procesos de negocio.
o Informes de anlisis de riesgos.
o Procesos de negocio en sistema completamente integrado.
o Procesos operativos y de mantenimiento.
o Procedimientos de usuario.
o Formularios.
19
o Informes.
o Datos de configuracin.
Tiposde pruebas:
o Las pruebas de aceptacin pueden darse en distintos momentos del ciclo
de vida, tales como:
Despus de la instalacin o integracin (por ejemplo, en un
producto de software comercial de distribucin masiva - COTS).
Durante las pruebas de componente/unitarias (por ejemplo,
pruebas de aceptacin de la usabilidad de un componente).
Antes de las pruebas de sistema (por ejemplo, pruebas de
aceptacin de una nueva mejora funcional).
o Las pruebas de aceptacin pueden adoptar, entre otras, las siguientes
formas:
Pruebas de aceptacin de usuario: Verifican la idoneidad del uso
del sistema por parte de los usuarios comerciales.
Pruebas operativas (de aceptacin): La aceptacin del sistema
por parte de los administradores del sistema, entre las que se
incluyen:
Pruebas de backup/restauracin.
Recuperacin de desastres.
Gestin de usuarios.
Tareas de mantenimiento.
Carga de datos y tareas de migracin.
Comprobaciones peridicas de vulnerabilidades de seguridad.
Pruebas de aceptacin contractual: Toman como base los criterios
de aceptacin previstos en un contrato para fabricar un software
desarrollado a medida.
Los criterios de aceptacin debern establecerse en el
momento en que las partes aceptan contraer dicho contrato.
Pruebas de aceptacin normativa: Toman como base cualquier
normativa de obligado cumplimiento, tales como normativas
gubernamentales, legales o de seguridad.
Pruebas alfa y beta (o de campo): Utilizadas por los
desarrolladores de productos software comerciales de distribucin
masiva COTS para obtener feedback de clientes/usuarios
potenciales o existentes en su mercado (las pruebas son realizadas
por estos) antes de sacar el producto a la venta.
Pruebas alfa (o pruebas de aceptacin en fbrica): En el
emplazamiento de la organizacin de desarrollo (pero no
interviene el equipo de desarrollo en su ejecucin).
Pruebas beta (o de campo, o pruebas de aceptacin en
emplazamiento): En las instalaciones de los clientes/usuarios
potenciales o existentes.

o Las pruebas de aceptacin son a menudo responsabilidad de los clientes o
usuarios de un sistema, a pesar de que tambin pueden participar otras
partes interesadas.
20
2.3 Tipos de prueba (K2)
Pruebas de caja negra
Pruebas tanto funcionales como no funcionales, sin referencia a la estructura interna
del componente o sistema.
Cobertura de cdigo
Mtodo de anlisis que determina qu partes del software han sido ejecutadas
(cubiertas) por el juego de pruebas y qu partes no han sido ejecutadas, ejemplo
cobertura de sentencia, cobertura de decisin o cobertura de condicin.
Pruebas funcionales
Pruebas basadas en el anlisis de las especificaciones funcionales de un
componente o de un sistema
Pruebas de
Proceso de pruebas con el objeto de determinar la interoperabilidad de un producto
interoperabilidad software.
Vase tambin pruebas de funcionalidad.
Pruebas de carga
Tipo de prueba relacionado con medida del comportamiento de un componente o
sistema con una carga creciente, por ejemplo el nmero de usuarios concurrentes
y/o nmero de transacciones para determinar qu carga puede ser soportada por el
componente o sistema. Vase tambin pruebas de estrs.
Pruebas de
Proceso de pruebas para determinar el grado de mantenibilidad de un producto
mantenibilidad software.
Mantenibilidad:
Facilidad con la que un producto software puede ser modificado para corregir
defectos, cumplir con nuevos requisitos, hacer ms sencillo el mantenimiento futuro
o ser adaptado a un entorno modificado.
Pruebas de rendimiento
Proceso de pruebas para determinar el rendimiento de un producto software. Vase
tambin pruebas de eficiencia
Pruebas de eficiencia
Proceso de prueba para determinar la eficiencia de un producto de software.
Eficiencia:
Capacidad del producto software para proporcionar un rendimiento apropiado,
relativo a la cantidad de recursos usados bajo condiciones establecidas.
Pruebas de portabilidad
Proceso de pruebas para determinar la portabilidad de un producto software.
Portabilidad:
Facilidad con la que un producto software puede ser transferido de un entorno

hardware o software a otro.
Pruebas de fiabilidad
Proceso de pruebas para determinar la fiabilidad de un producto software.
Fiabilidad:
Habilidad de un producto software para llevar a cabo aquellas funciones requeridas

en condiciones establecidas para un perodo de tiempo especfico, o para un
nmero especfico de operaciones.
Pruebas de seguridad
Pruebas para determinar la seguridad (efectos adversos) de un producto software.
Seguridad:
Atributos de productos software que se refieren a su capacidad para prevenir

accesos no autorizados, sean accidentales o deliberados, a programas y datos.
21
Pruebas de estrs
Pruebas orientadas a evaluar un componente o sistema en o ms all de los lmites
especificados en los requisitos.
Pruebas de usabilidad
Pruebas para determinar en qu medida el producto software es comprensible, fcil
de aprender, fcil de operar y atractivo a los usuarios bajo condiciones
especificadas.
Usabilidad:
Capacidad del software para ser comprendido, aprendido, utilizado y atractivo al

usuario cuando es utilizado bajo condiciones especificadas.
Pruebas de caja blanca /

Pruebas basadas en un anlisis de la estructura interna del componente o sistema.
estructurales / basadas
en la estructura
22
Antecedentes
Un tipo de prueba se centra en un objetivo de prueba:

Una funcin a realizar por el software.
Una caracterstica de calidad no funcional (fiabilidad, usabilidad, ...).
La estructura o arquitectura del software o sistema.
Confirmar que se han solucionado los defectos (pruebas de confirmacin).
Localizar cambios no intencionados (pruebas de regresin).
2.3.1 Pruebas de funciones (Pruebas funcionales) (K2)
Funciones = Lo que hace el sistema.
Pruebas funcionales:
Se basan en funciones o prestaciones y en su interoperabilidad con sistemas
especficos.
Las funciones (de un sistema, subsistema o componente) se describen en productos
de trabajo:
Especificacin de requisitos.
Casos de uso.
Especificacin funcional.
O no estar documentadas (experiencia).
Pueden llevarse a cabo en todos los niveles de prueba (por ejemplo, pruebas de
componente basadas en una especificacin de componente).
Tcnicas basadas en la especificacin: obtener condiciones de prueba y casos de
prueba a partir de la funcionalidad de un software o sistema.
Las pruebas funcionales tienen en cuenta el comportamiento externo del software
(pruebas de caja negra).
Ejemplos:
Pruebas de seguridad de un cortafuegos (funciones asociadas a la deteccin de
amenazas procedentes de personas ajenas y malintencionadas).
Pruebas de interoperabilidad (evalan la capacidad del producto de software de
interactuar con uno o ms componentes o sistemas especificados).
2.3.2 Pruebas de caractersticas no funcionales del software (Pruebas no

funcionales) (K2)
Pruebas no funcionales = Cmo funciona el sistema (medida de caractersticas de los
sistemas y software que pueden cuantificarse segn una escala variable; por ejemplo:
Tiempos de respuesta en pruebas de rendimiento).
Incluyen (entre otras):

Pruebas de rendimiento.
Pruebas de carga.
Pruebas de estrs.
23
Pruebas de usabilidad.
Pruebas de mantenibilidad.
Pruebas de fiabilidad.
Pruebas de portabilidad.
Pueden ejecutarse a todos los niveles de prueba.
Pueden hacer referencia a un modelo de calidad (por ejemplo, calidad de producto
segn ISO 9126 / ISO 25000).
Tienen en cuenta el comportamiento externo del software (en la mayora de los
casos utiliza tcnicas de diseo de pruebas de caja negra).
2.3.3 Pruebas de estructura/arquitectura de software (Pruebas estructurales) (K2)

Pruebas estructurales (caja blanca) pueden realizarse en todos los niveles de prueba.
Permiten medir la exhaustividad de las pruebas mediante una evaluacin de la
cobertura de un tipo de estructura.
Cobertura: medida en que un juego de pruebas ha probado una estructura,
expresada como porcentaje de los elementos cubiertos.
Si la cobertura no es del 100% podrn disearse ms pruebas para probar los
elementos que faltan para aumentar la cobertura.
En todos los niveles de prueba (especialmente en pruebas de componente e
integracin de componentes): Hay herramientas para medir la cobertura de
cdigo (como sentencias o decisiones).
Pueden basarse en la arquitectura del sistema (por ejemplo, una jerarqua de
llamadas). Tambin pueden aplicarse a nivel de sistema, integracin de sistemas o
pruebas de aceptacin.
2.3.4 Pruebas asociadas a cambios: Repeticin de pruebas y pruebas de regresin

(K2)
Pruebas de confirmacin: Una vez detectado y corregido un defecto, el software debe

volver a probarse para confirmar que el defecto original ha sido corregido con xito.
La depuracin es una actividad de desarrollo, no una actividad de pruebas.
Pruebas de regresin: prueba reiterada de un programa ya probado, despus de
haber sido modificado (el software o su entorno), con vistas a localizar defectos
surgidos o no descubiertos como resultado del cambio.
Estos defectos pueden estar en el software objeto de las pruebas, o en cualquier
otro componente de software asociado o no asociado al cambio.
El alcance de las pruebas de regresin depende del riesgo de encontrar defectos
en el software que antes funcionaba.
Pueden realizarse en todos los niveles de prueba (incluyendo pruebas
funcionales, no funcionales y estructurales).
Pruebas de confirmacin/regresin: deben ser repetibles.
Sobre todo las de regresin: se ejecutan muchas veces y en general suelen
evolucionar lentamente. Son candidatas a automatizarse.
24
2.4 Pruebas de mantenimiento (K2)
Anlisis de impacto
Valoracin del cambio en las capas de documentacin de desarrollo,
documentacin de pruebas y componentes, con el objeto de implementar un
cambio dado en requisitos especificados.
Pruebas de mantenimiento
Pruebas de los cambios en un sistema en operacin o el impacto de un
entorno modificado para un sistema en operacin.
Se realizan en un sistema en operacin y se activan a partir de modificaciones, casos

de migracin o la retirada del software o sistema.
Entre las modificaciones se incluyen:
Modificaciones de mejora planificadas.
Modificaciones correctivas y de emergencia.
Modificaciones de entorno.
Actualizaciones previstas de sistema operativo o base de datos.
Actualizaciones previstas de software comercial de distribucin masiva.
Parches para corregir vulnerabilidades recientemente descubiertas en el
sistema operativo.
Las pruebas de mantenimiento en los casos de migracin deben incluir pruebas
operativas tanto del nuevo entorno como del software modificado.
Las pruebas de migracin (pruebas de conversin) tambin son necesarias
cuando se prev migrar datos de otra aplicacin al sistema objeto del
mantenimiento.
Las pruebas de mantenimiento para la retirada de un sistema pueden incluir pruebas
de migracin de datos o archivo si se requieren largos periodos de retencin de
datos.
Las pruebas de mantenimiento incluyen:
Probar lo que se ha modificado.
Probar otras partes del sistema (pruebas de regresin).
El alcance de las pruebas variar en funcin de:
El riesgo de la modificacin.
El tamao del sistema existente.
Las dimensiones de la modificacin.
Dependiendo de las modificaciones las pruebas podrn realizarse en:
Todos o cualquier nivel de prueba.
Todos o cualquier tipo de prueba.
Anlisis de impacto:
Determinacin de cmo el sistema existente podr verse afectado por las
modificaciones.
Sirve para ayudar a decidir cuntas pruebas de regresin son necesarias.
Situaciones problemticas para ejecutar pruebas de mantenimiento:
No se disponen de especificaciones o estn desactualizadas.
25
No hay probadores con conocimiento de dominio disponibles.
26
3. Tcnicas estticas (K2)
3.1 Las tcnicas estticas y el proceso de pruebas (K2)

Pruebas dinmicas
Pruebas que implican la ejecucin del software de un componente o sistema.
Pruebas estticas
Pruebas de un componente o sistema a nivel de especificacin o implementacin
sin ejecutar el software, por ejemplo revisiones o anlisis esttico de cdigo.
Antecedentes
Pruebas dinmicas: exigen la ejecucin del software.
Pruebas estticas: no ejecutan el cdigo. Se basan en el examen manual (revisiones) y el
anlisis automatizado (anlisis esttico) del cdigo o de cualquier otra documentacin del
proyecto.
Revisiones:
Manuales o utilizando herramientas de soporte.
Principal actividad manual: examinar un producto de trabajo y hacer comentarios.
Cualquier producto de trabajo puede ser objeto de una revisin: especificaciones de
requisitos, especificaciones de diseo, el cdigo, los planes de prueba, las
especificaciones de pruebas, los casos de pruebas, los guiones de prueba, las guas
de usuario o las pginas Web.
Beneficios de las revisiones:
Deteccin y correccin temprana de defectos (por ejemplo, en la revisin de
requisitos).
Desarrollo de mejoras de productividad.
Reduccin de los tiempos de desarrollo.
Ahorro de tiempo y dinero invertido en pruebas.

Las revisiones, el anlisis esttico y las pruebas dinmicas tienen el mismo objetivo:
identificar defectos.
Son procesos complementarios: las distintas tcnicas pueden encontrar distintos
tipos de defectos de manera eficiente y efectiva.
Las pruebas dinmicas detectan los fallos, mientras que las estticas detectan sus
causas (los defectos).
Defectos tpicos que resultan fciles de localizar en revisiones (y en esto son ms
eficaces/eficientes que las pruebas dinmicas):
Desviaciones de los estndares.
Defectos de requisito.
Defectos de diseo.
Mantenibilidad insuficiente.
Especificaciones de interfaz incorrectas.
27
3.2 Proceso de revisin (K2)
Criterios de entrada
Conjunto de condiciones genricas y especficas para permitir que un proceso
prosiga con una tarea definida, por ejemplo la fase de pruebas. El objetivo de los
criterios de entrada es evitar que una tarea comience, lo cual conllevara un
mayor esfuerzo que el necesario para eliminar los criterios de entrada fallidos.
Revisin formal
Revisin caracterizada por procedimientos y requisitos documentados, por
ejemplo la inspeccin.
Revisin informal
Revisin que no est basada en un procedimiento formal (documentado).
Inspeccin
Tipo de revisin entre pares que se basa en el examen visual de documentos
para detectar defectos, por ejemplo violaciones de estndares de desarrollo y no
conformidades a la documentacin de nivel superior. Es la tcnica de revisin
ms formal y, por lo tanto, siempre basada en un procedimiento documentado.
Vase tambin revisin entre pares.
Mtrica
Escala de medida y el mtodo utilizado para la medicin.
Moderador
Lder y principal persona responsable de una inspeccin u otro proceso de
revisin.
Revisin entre pares (peer

Revisin de un producto de trabajo software por parte de compaeros de trabajo
review) del desarrollador del producto con el objeto de identificar defectos y mejoras.
Ejemplos de este tipo de revisin son la inspeccin, revisin tcnica y revisin
guiada.
Revisor
Persona involucrada en la revisin, responsable de la identificacin y descripcin
de anomalas en el producto o proyecto bajo revisin. Los revisores pueden ser
seleccionados para representar diferentes puntos de vista y roles dentro del
proceso de revisin.
Escriba
Persona que registra en un acta cada defecto mencionado y cualquier
sugerencia para la mejora de un proceso durante una reunin de revisin. El
escriba tiene que asegurarse que el acta sea legible y comprensible.
Revisin tcnica
Actividad de discusin de grupo de pares que se centra en alcanzar consenso
respecto del enfoque tcnico a adoptar.
Revisin guiada
Presentacin paso a paso de un documento por parte del autor con el fin de
recoger informacin y establecer un entendimiento comn de su contenido.
Antecedentes
Tipos de revisiones:
Informales (los revisores carecen de instrucciones escritas).
Sistemticas (incluyen la participacin del equipo, se documentan los resultados y
hay procedimientos documentados para realizarlas).
Grado de formalidad depende de: madurez del proceso de desarrollo, requisitos
legales/normativos, necesidad de rastro de auditora.
Posibles objetivos:
28
Encontrar defectos.
Formar probadores o nuevos desarrolladores.
Debatir y decidir por consenso.
3.2.1 Actividades de una revisin formal (K1)
1. Planificar:
Definir los criterios de revisin.
Seleccionar al personal.
Asignar funciones.
Definir los criterios de entrada y salida (en revisiones formales).
Seleccionar qu partes de los documentos deben revisarse.
2. Inicio:
Repartir los documentos.
Explicar los objetivos, procesos y documentos a los participantes.
3. Comprobar los criterios de entrada (en revisiones formales).
4. Preparacin individual.
Prepararse para la reunin de revisin repasando los documentos.
Prestar especial atencin a posibles defectos, preguntas y comentarios.
5. Examen/evaluacin/registro de los resultados (reunin de revisin):
Debatir o registrar, mediante resultados documentados o actas (en revisiones
formales).
Prestar especial atencin a los defectos, hacer recomendaciones sobre cmo
manejar los defectos, tomar decisiones al respecto.
Durante reuniones fsicas o de seguimiento de los grupos.
6. Corregir los defectos detectados (normalmente a cargo del autor).
Registrar el estado actualizado de los defectos (en revisiones formales).
7. Hacer un seguimiento.
Comprobar que los defectos han sido tratados.
Recopilar mtricas.
8. Comprobar los criterios de salida (en revisiones formales).
3.2.2 Funciones y responsabilidades (K1)
Funciones de una revisin formal:
1. Jefe:
Decide sobre la ejecucin de las revisiones.
Asigna el tiempo en los calendarios del proyecto.
Determina si se han logrado los objetivos de la revisin.
2. Moderador:
29
Lidera la revisin del documento o serie de documentos (incluyendo
planificacin de la revisin, celebracin de la reunin y seguimiento despus
de la reunin).
Media entre los distintos puntos de vista.
3. Autor:
Escritor o persona con mxima responsabilidad de los documentos a revisar.
4. Revisores (evaluadores/inspectores):
Personas con experiencia especfica en el mbito tcnico o comercial.
(Una vez preparados para ello) Identifican y describen las conclusiones (por
ejemplo, los defectos) sobre el producto objeto de la revisin.
5. Escriba (o registrador):
Documenta todos los problemas, asuntos, temas abiertos que se han
identificado durante la reunin.
til para mejora de efectividad/eficiencia revisiones: Utilizar listas de comprobacin basada

en distintas perspectivas (usuario, mantenedor, probador, operaciones) o que incluya los
problemas tpicos (por ejemplo, en la definicin de requisitos).
3.2.3 Tipos de revisiones (K2)

(Un nico producto de software o producto de trabajo asociado puede ser objeto de varias
revisiones).
(Las revisiones guiadas, las revisiones tcnicas y las inspecciones pueden llevarse a cabo
dentro de un mismo grupo de pares, es decir, entre colegas de un mismo nivel organizativo.
Este tipo de revisiones recibe el nombre de revisin entre pares).
A continuacin se listan las principales caractersticas de cada tipo de revisin:
Revisin informal
Ausencia de un proceso formal.
Puede adoptar la forma de programacin por pares o una revisin por parte de un
lder tcnico de los diseos y el cdigo.
Los resultados pueden estar o no documentados.
Su utilidad vara en funcin de los revisores.
Objetivo principal: Obtener beneficios de forma barata.
Revisin guiada
Presentacin paso a paso de un documento por parte del autor con el fin de recoger informacin y establecer un
entendimiento comn de su contenido. Vase tambin revisin entre pares.
Puede variar desde bastante informal hasta muy formal.

Reunin liderada por el autor.
Puede adoptar la forma de escenarios, simulacros o participacin de grupos de pares.
Sesiones abiertas:
Preparacin/Capacitacin opcional de revisores previa a la reunin.
Preparacin opcional de un informe de revisin en el que se incluya la lista de
conclusiones.
Escriba opcional (distinto del autor).
Objetivo principal: Aprender, encontrar defectos.
30
Revisin tcnica
Actividad de discusin de grupo de pares que se centra en alcanzar consenso respecto del enfoque tcnico a adoptar.
Puede variar desde bastante informal hasta muy formal.

Proceso documentado y definido para la deteccin de defectos que incluye la
participacin de pares y expertos tcnicos (opcionalmente tambin la direccin).
Idealmente dirigida por un moderador formado (distinto del autor).
Preparacin previa a la reunin por parte de los revisores.
Uso opcional de lista de comprobacin.
Elaboracin de un informe de revisin en el que se incluye:
Lista de conclusiones.
Veredicto de si el producto de software cumple los requisitos.
Recomendaciones.
Objetivos principales: debatir, tomar decisiones, evaluar alternativas, encontrar
defectos, resolver problemas tcnicos, comprobar la conformidad con las
especificaciones/planes/normativas/estndares.
Inspeccin
Tipo de revisin entre pares que se basa en el examen visual de documentos para detectar defectos, por ejemplo
violaciones de estndares de desarrollo y no conformidades a la documentacin de nivel superior. Es la tcnica de
revisin ms formal y, por lo tanto, siempre basada en un procedimiento documentado. Vase tambin revisin entre
pares.
Proceso formal. Funciones definidas.

Dirigida por un moderador formado (distinto del autor).
Generalmente celebrada como un examen entre pares.
Incluye una recopilacin de mtricas.
Se basa en normas y listas de comprobacin.
Criterios de entrada y salida especificados para la aceptacin del producto de
software.
Preparacin previa a la reunin.
Informe de inspeccin en el que se incluye una lista de las conclusiones
Proceso de seguimiento formal (con proceso de mejora de componentes opcional).
Lector opcional.
Objetivo principal: Identificar defectos.
3.2.4 Factores de xito de las revisiones (K2)

Todas las revisiones tienen objetivos claros y predefinidos.
Se cuenta con la participacin de las personas adecuadas.
Los probadores constituyen revisores valiosos que contribuyen a la revisin y
aprenden sobre el producto, lo que les permitir preparar pruebas en una fase
ms temprana.
Los defectos detectados son bienvenidos y se expresan de manera objetiva.
31
Se afrontan los problemas de personal y los aspectos psicolgicos (por ejemplo,
haciendo que sea una experiencia positiva para el autor).
La revisin se lleva a cabo en una atmsfera de confianza (el resultado no se utilizar
para evaluar a los participantes).
Se aplican las tcnicas de revisin adecuadas (para los objetivos, tipo/nivel de
productos de trabajo y los revisores).
Se utilizan listas de comprobacin o funciones si procede para aumentar la
efectividad del proceso de identificacin de defectos.
Se ofrece formacin sobre tcnicas de revisin, especialmente por lo que respecta a
las tcnicas ms formales como la inspeccin.
Existe respaldo (asignacin de recursos/tiempo en el cronograma dedicado) desde
Direccin.
Se hace hincapi en el aprendizaje y en la mejora del proceso.
Nota sobre IEEE 1028 Estndar que se aplica a las revisiones

Secciones:
1. Descripcin general.
2. Referencias.
3. Definiciones.
4. Revisiones de gestin (no entra en el nivel bsico de ISTQB).
5. Revisiones tcnicas.
6. Inspecciones.
7. Revisiones guiadas.
8. Auditoras (no entra en el nivel bsico de ISTQB).
3.3 Anlisis esttico con herramientas (K2)

Compilador
Herramienta software que traduce programas expresados en un lenguaje de alto
nivel a su lenguaje mquina equivalente.
Complejidad
Grado en el cual un componente o sistema tiene un diseo y/o estructura interna
que es difcil de comprender, mantener y verificar. Vase tambin complejidad
ciclomtica.
Complejidad ciclomtica
(Segn McCabe) Nmero de caminos independientes en un programa (=
nmero de pruebas bsicas requeridas para cubrir el grafo, en el caso de pruebas
de unidad para una funcin).
Se define la complejidad ciclomtica como: E - N + 2P, donde
E =nmero de aristas/enlaces en un grafo (secuencias de cero o ms

sentencias sin ramas).
N =nmero de nodos en un grafo (puntos de entrada, puntos de salida y

decisiones).
P =nmero de partes desconectadas del grafo (por ejemplo un grafo

invocado y una subrutina) Normalmente se iguala a 1.
Por tanto, C = E N + 2
Alternativa: C = R + 1 (siendo R el nmero de regiones cerradas en el grafo).
Otra alternativa: (Partiendo de 1) +1 por cada if, for, while, do while, bloque case de
switch (else de los if no cuenta, bloque default de switch no cuenta).
32
Cada funcin en un programa, incluyendo la funcin principal, comienza con un
contador de complejidad de 1. Contamos la complejidad funcin por funcin. Cada
vez que hay una rama o bucle en una funcin, el contador de complejidad aumenta
en uno.
Clculo de los caminos bsicos/independientes = se comienza con un camino

cualquiera a travs del diagrama. Luego adicionando otro camino que cubre el
mnimo nmero de aristas no cubiertas previamente, repitiendo este proceso hasta
que todas las aristas hayan sido cubiertas por lo menos una vez.
Las pruebas bsicas son las entradas y los resultados esperados asociados con
cada camino bsico.
Usualmente las pruebas bsicas coincidirn con las pruebas necesarias para
alcanzar cobertura de rama (decisin).
Cobertura de rama (decisin) corresponde a la cobertura de particiones de

equivalencia.
Flujo de control
Secuencia de eventos (caminos) en la ejecucin a travs de un componente o
sistema.
Grfico de flujo de control:
Representacin abstracta de todas las posibles secuencias de eventos (caminos) en

la ejecucin a travs de un componente o sistema.
Flujo de datos
Representacin abstracta de la secuencia y posibles cambios de estado de los
objetos de datos, donde el estado de un objeto puede ser cualquiera de los
siguientes: creacin, uso o destruccin.
Anlisis esttico
Anlisis de los artefactos software, por ejemplo requisitos o cdigo, llevado a cabo
sin la ejecucin de estos artefactos software.
Objetivo del anlisis esttico: Detectar defectos en el cdigo fuente del software y en
los modelos de software.
Se realiza sin ejecutar el software objeto de la revisin (al contrario que en las
pruebas dinmicas).
Las herramientas de anlisis esttico analizan el cdigo del programa (p.ej. el
flujo de control y flujo de datos) y las salidas generadas (p.ej. HTML o XML).
(Al igual que en las revisiones) Encuentra defectos en lugar de fallos.
El valor del anlisis esttico es:
La deteccin temprana de defectos antes de la ejecucin de las pruebas.
Prevencin de defectos, si se aprende la leccin en la fase de desarrollo.
Advertencia temprana sobre aspectos sospechosos del cdigo o del diseo
mediante clculo de mtricas (p.ej complejidad ciclomtica).
Identificacin de defectos que no se encuentran fcilmente mediante pruebas
dinmicas.
Detectar dependencias e inconsistencias en modelos de software (p.ej. Enlaces).
Mantenibilidad mejorada del cdigo y del diseo.
Defectos habitualmente detectados por las herramientas de anlisis esttico:
Referenciar una variable con un valor indefinido.
Interfaces inconsistentes entre mdulos.
Variables que no se utilizan o que se declaran de forma incorrecta.
Cdigo inaccesible (muerto).
33
Ausencia de lgica o lgica errnea (posibles bucles infinitos).
Construcciones demasiado complicadas.
Infracciones de los estndares de programacin.
Vulnerabilidades de seguridad.
Infracciones de sintaxis del cdigo y modelos de software.
Las herramientas de anlisis esttico generalmente las utilizan:
Los desarrolladores antes y durante las pruebas de componente e integracin, o
durante la comprobacin del cdigo.
Los diseadores durante la modelacin del software.
Las herramientas de anlisis esttico pueden producir un gran nmero de mensajes
de advertencia que deben ser gestionados para permitir el uso efectivo de la
herramienta.
34
4. Tcnicas de diseo de pruebas (K4)
4.1 El proceso de desarrollo de pruebas (k3)

Caso de prueba
Conjunto de valores de entrada, precondiciones de ejecucin, resultados
esperados y postcondiciones de ejecucin, desarrollado con un objetivo en
particular o condicin de prueba, tales como probar un determinado camino de
ejecucin o para verificar el cumplimiento de un requisito determinado.
Especificacin de casos de
Documento que especifica un conjunto de casos de prueba para un elemento de
prueba prueba.
Objetivo de prueba
Razn o propsito para el diseo y la ejecucin de una prueba.
Objeto de prueba
Componente o sistema a ser probado. Vase tambin elemento de prueba.
Elemento de prueba
Elemento individual a ser probado. Normalmente hay un objeto de prueba y
muchos elementos de prueba. Vase tambin objeto de prueba.
Condicin de prueba
Elemento o evento de un componente o sistema que debera ser verificado por
uno o ms casos de prueba, por ejemplo una funcin, transaccin, caracterstica,
atributo de calidad o elemento estructural.
(Especificacin de) Diseo

Documento que especifica las condiciones de prueba (elementos de cobertura)
de pruebas para el elemento de prueba, el enfoque de pruebas de forma detallada e identifica
los casos de prueba de alto nivel asociados.
Calendario de ejecucin de
Planificacin para la ejecucin de procedimientos de prueba. Los procedimientos
pruebas de prueba estn incluidos en el calendario de ejecucin de pruebas en su
contexto y en el orden en el cual deben ser ejecutados.
(Especificacin de)
Documento que especifica la secuencia de acciones para la ejecucin de una
procedimiento de pruebas prueba. Tambin conocido como script de prueba o script de prueba manual.
Guin(script) de prueba
Comnmente usado para referirse a una especificacin de procedimiento de
prueba, especialmente una automatizada.
Trazabilidad
Capacidad de identificar elementos relacionados en la documentacin y el
software, tales como requisitos con las pruebas asociadas. Vase tambin
trazabilidad horizontal y trazabilidad vertical.
Trazabilidad horizontal:
Trazas de requisitos para un nivel de pruebas a travs de las capas de la

documentacin de pruebas (por ejemplo, plan de pruebas, especificacin de
diseo de prueba, especificacin de caso de prueba y especificacin de
procedimiento de prueba o script de pruebas).
Trazabilidad vertical:
Trazado de requisitos a travs de las capas de la documentacin de desarrollo

hasta los componentes.
35
Puede variar: desde muy informal (con poca o ninguna documentacin) a muy formal
(que se trata en este captulo).
Nivel de formalidad depende de: madurez de pruebas y proceso de
desarrollo, limitaciones de tiempo, requisitos de seguridad/normativas,
personas implicadas.
Anlisis de pruebas:
Se analiza la documentacin bsica de las pruebas para determinar las
condiciones de prueba.
Condicin de prueba: Elemento o evento que debera ser verificado por uno o
ms casos de prueba (p.ej. Una funcin, transaccin, atributo de calidad o
elemento estructural).
Trazabilidad condiciones de prueba especificaciones/requisitos:
Permite obtener un anlisis de impacto efectivo cuando los requisitos
cambian.
Permite determinar la cobertura de requisitos para una serie de
pruebas.
El anlisis de pruebas permite seleccionar las tcnicas de diseo de pruebas a
utilizar en funcin (entre otros factores) de los riesgos identificados.
Diseo de pruebas:
Se crean los casos de prueba y los datos de prueba.
Caso de prueba.
Objeto: Cubrir uno o varios objetivos de prueba o poscondiciones de
prueba.
Consta de:
Valores de entrada.
Precondiciones de ejecucin.
Resultados esperados (valores de salida, modificaciones a los
datos, ...). Para no interpretar como correcto un resultado
plausible pero errneo.
Poscondiciones de ejecucin.
La Norma para la documentacin de pruebas de software (IEEE 829)
describe:
Contenido de las especificaciones de diseo de pruebas (incluyendo
condiciones de prueba).
Especificaciones de los casos de prueba.
Ejecucin de la prueba:
Se desarrollan, implementan, priorizan y organizan los casos de prueba para
especificar el procedimiento de prueba.
Procedimiento de prueba: Especifica la secuencia de acciones necesarias para
ejecutar una prueba (si se utiliza una herramienta de ejecucin de pruebas la
secuencia de acciones se especifica en un guin de prueba = procedimiento
de prueba automatizado).
Los distintos procedimientos de prueba (incluyendo automatizados)
conforman un calendario de ejecucin de pruebas que establece el orden en
el que deben ejecutarse los distintos procedimientos de prueba.
Este calendario de ejecucin de pruebas tendr en cuenta factores
como: pruebas de regresin, priorizacin y dependencias tcnicas y
lgicas.
36
IEEE 829 - Norma para la documentacin de prueba de software
Secciones plantilla de especificacin de diseo de pruebas:

Identificador de la especificacin del diseo de pruebas.
Caractersticas que deben ser probadas (mediante este juego de pruebas).
Refinamientos del mtodo (tcnicas especficas, herramientas, etc.).
Identificacin de las pruebas (trazabilidad de los casos de prueba en el juego
de pruebas).
Criterios de paso/falla de las caractersticas (p.ej, orculo de pruebas, base
de pruebas, sistemas heredados, etc.).
Secciones plantilla de especificacin de caso de prueba:
Identificador de la especificacin del caso de prueba.
tems/Elementos de pruebas (lo que tiene que ser entregado y probado).
Especificaciones de las entradas (entradas del usuario, archivos, etc.).
Especificaciones de las salidas (resultados esperados, incluyendo pantallas ,
archivos, tiempo, etc.).
Necesidades del entorno (hardware, software, personas, accesorios, ).
Requisitos especiales de procedimiento (intervencin del operador, permisos,
).
Dependencias entre casos (si es necesario para establecer condiciones
previas).
Secciones plantilla de especificacin de procedimiento de prueba:
Identificador de la especificacin del procedimiento de prueba.
Propsito.
Requisitos especiales (habilidades, permisos, entorno, etc.).
Pasos del procedimiento.
4.2 Categoras de tcnicas de diseo de pruebas (K2)

Tcnica de diseo de
Procedimiento utilizado para obtener y/o seleccionar casos de prueba.
pruebas
Tcnica de diseo de
Procedimiento para obtener y/o seleccionar casos de prueba basados en un
pruebas de caja
blanca anlisis de la estructura interna del componente o sistema.
Tcnica de diseo de
Procedimiento para obtener y/o seleccionar casos de prueba basados en el anlisis de la
pruebas de caja especificacin, tanto funcional como no funcional de un componente o sistema sin
negra referencia a su estructura interna.
Tcnica de diseo de
Procedimiento para derivar y/o seleccionar casos de prueba basados en la experiencia,
pruebas basadas en conocimiento e intuicin del probador.
la experiencia
Objetivo de una tcnica de diseo de pruebas: identificar condiciones de prueba, casos

de prueba y datos de prueba.
37
Clasificacin (tradicional):
Tcnicas de pruebas de caja negra (basadas en la especificacin):
Basadas en un anlisis de la documentacin bsica de la prueba (no utilizan
ninguna informacin sobre la estructura interna del componente o sistema a
probar).
Incluye: Pruebas funcionales y no funcionales.
Tcnicas de pruebas de caja blanca (basadas en la estructura o estructurales):
Se basan en el anlisis de la estructura del componente o sistema.
Tcnicas de pruebas basadas en la experiencia.
Las pruebas de caja negra/blanca tambin pueden basarse en la experiencia de
los desarrolladores, probadores y usuarios para determinar el objeto de las
pruebas.
Algunas tcnicas pertenecen claramente a una nica categora, otras tienen elementos de
varias categoras.
Caractersticas comunes de las tcnicas de diseo de pruebas de caja negra:
El problema a solucionar, el software o sus componentes se especifican a partir de
modelos, tanto formales como informales.
Los casos de prueba pueden obtenerse sistemticamente a partir de estos modelos.
Caractersticas comunes de las tcnicas de diseo de pruebas de caja blanca:
Informacin sobre cmo debe utilizarse el software construido para obtener los casos
de prueba (por ejemplo, cdigo e informacin de diseo detallada).
Puede medirse el alcance de la cobertura del software para los casos de prueba
existentes, y puede obtenerse otros casos de prueba de manera sistemtica para
aumentar la cobertura.
Caractersticas comunes de las tcnicas de diseo de pruebas basadas en la
experiencia:
Se emplea el conocimiento y la experiencia de las personas para obtener los casos de
prueba.
El conocimiento de los probadores, desarrolladores, usuarios y dems partes
interesadas sobre el software, su uso y su entorno constituye una fuente de
informacin.
El conocimiento sobre los defectos probables y su distribucin constituye otra fuente
de informacin.
4.3 Tcnicas basadas en la especificacin o tcnicas de

caja negra (K3)
4.3.1 Particin (Clase) de equivalencia (K3)
Porcin del dominio de una entrada o una salida para la cual se asume que el comportamiento de un componente o
sistema, basado en la especificacin, es el mismo.
Los valores de entrada del software o del sistema se dividen en grupos que se espera
demuestren un comportamiento similar, de manera que puedan ser procesados de la
misma forma.
Las particiones de equivalencia (o clases) son aplicables a datos vlidos e invlidos.
38
Las particiones tambin pueden aplicarse a los valores de salida, valores internos,
valores relativos al tiempo (por ejemplo, antes o despus de un evento) o a los
parmetros de interfaz (por ejemplo, prueba de integracin entre componentes).
La particin de equivalencia es aplicable a todos los niveles de pruebas.
La particin de equivalencia puede utilizarse para lograr objetivos de cobertura de
entrada y salida.
Manera de proceder:
1. Identificar entradas, salidas, comportamientos, entornos, configuraciones... a probar.
2. Separar los valores posibles de cada uno de ellos en clases de equivalencia (que
mostrarn un comportamiento similar).
3. Creacin de casos de prueba de opciones vlidas:
Seleccionar una combinacin de clases de equivalencia vlidas (seleccionando un
valor de cada una) y definir el resultado esperado en esa situacin.
Repetir el proceso hasta que haya seleccionado al menos un valor representativo
para cada particin de equivalencia vlida.
4. Creacin de casos de prueba de opciones invlidas:
Seleccionar un valor de una particin invlida de equivalencia. Para el resto de
las particiones de equivalencia seleccione un valor vlido. Defina el resultado
esperado en esa situacin.
Repetir el proceso hasta que haya seleccionado todas las particiones invlidas.
4.3.2 Anlisis de valores lmite (K3)
Tcnica de diseo de pruebas de caja negra en la cual los casos de prueba son diseados basndose en los valores
lmite. Vase tambin valor lmite.
Valor lmite:
Valor de entrada o de salida que se encuentra en la frontera de una particin de equivalencia o a la mnima distancia
incremental a cualquier lado de la frontera, por ejemplo el valor mnimo o mximo de un rango.
El comportamiento en el lmite de cada particin de equivalencia tiene ms

posibilidades de ser incorrecto que el comportamiento dentro de la particin (los
lmites constituyen un rea en el que las pruebas tendern a incluir defectos).
Los valores mximos y mnimos de una particin son sus valores lmite.
El valor lmite de una particin vlida constituye un valor lmite vlido, mientras que
los lmites de una particin no vlida constituyen valores lmite no vlidos.
Las pruebas pueden disearse para cubrir valores lmite tanto vlidos como no
vlidos.
Al disear casos de prueba, se selecciona una prueba por cada valor lmite.
El anlisis de valores lmite puede aplicarse a todos los niveles de prueba. Es
relativamente fcil de aplicar y su capacidad para detectar defectos es alta. Las
especificaciones detalladas son tiles a la hora de establecer los lmites interesantes.
Esta tcnica a menudo se considera como una extensin de la particin de
equivalencia u otras tcnicas de diseo de pruebas de caja negra. Puede utilizarse en
clases de equivalencia para los valores que los usuarios introducen en pantalla y, por
ejemplo, en rangos de tiempo (tales como tiempo agotado o requisitos de velocidad
de transacciones) o rangos de tabla (por ejemplo, el tamao de la tabla es
256*256).
39
Slo podemos utilizar el anlisis de valores lmite cuando los elementos de la
particin de equivalencia son ordenados. Tenemos que ser capaces de hablar de un
valor que es mayor que o menor que otro valor.
Los valores lmite y las particiones de equivalencia invlidas de los campos de
entrada deberan ser utilizados principalmente para probar la validacin de las
entradas.
4.3.3 Pruebas de tabla de decisin (K3)
Tcnica de diseo de casos de prueba de caja negra en la que los casos de prueba se disean para ejecutar las
combinaciones de entradas y/o estmulos (causas) representadas en una tabla de decisin. Vase tambin tabla de
decisin.
Tabla de decisin:
Tabla que muestra las combinaciones de entradas y/o estmulos (causas) con sus salidas y/o acciones asociadas
(efectos), que puede ser utilizada para disear casos de prueba.
Las tablas de decisin: reflejan los requisitos del sistema que contienen condiciones
lgicas.
Se analiza la especificacin y se identifican las condiciones y acciones del
sistema.
Por lo general, las condiciones y acciones de entrada se sentencian de manera
que deben ser verdaderas o falsas (booleano).
La tabla de decisin incluye las condiciones de activacin , a menudo
combinaciones de verdadero y falso para todas las condiciones de entrada, y las
acciones resultantes para cada combinacin de condiciones.
Cada columna de la tabla corresponde a una regla comercial que define una
combinacin nica de condiciones y que resulta en la ejecucin de aquellas
acciones asociadas a dicha regla.
Estndar de cobertura: Disponer al menos de una prueba por columna en
la tabla, lo que generalmente implica cubrir todas las combinaciones de
condiciones de activacin.
Mediante esta tcnica se prueba la lgica de negocio (sus reglas). Las
validaciones de entrada se deben haber probado antes.
4.3.4 Pruebas de transicin de estado (K3)
Tcnica de diseo de pruebas de caja negra en la cual los casos de prueba son diseados para ejecutar transiciones
de estado vlidas e invlidas. Vase tambin pruebas de conmutador de multiplicidad N.
Pruebas de conmutador de multiplicidad N:
Forma de pruebas de transicin de estado en la cual los casos de prueba estn diseados para ejecutar todas las
secuencias vlidas de N+1 transiciones.
Diagrama de transicin de estado: Muestra las respuestas diferentes de un sistema

en funcin de sus condiciones actuales o su historial previo (su estado).
El software se ve en trminos de sus estados, transiciones entre estados,
entradas o eventos que activan los cambios de estado (transiciones) y acciones
que pueden derivarse de dichas transiciones.
Los estados del sistema u objeto de la prueba son independientes, identificables
y finitos en nmero.
Sobre el diagrama de transicin de estados:
40
1. Primero identificar los estados del sistema (estado = situacin que persiste
hasta que algn evento ocurra para causar una transicin de estado).
2. Identifica el estado inicial y final.
3. Regla general: Los casos de prueba deberan comenzar con el sistema en el
estado inicial y deberan terminar en el estado final.
4. En cada estado un evento puede ocurrir que forzar una transicin de estado
(excepcin: en el estado final esto no ocurre). (Los eventos son
frecuentemente entrada de algn tipo de sistema o aplicacin).
5. Mientras la transicin de estado ocurre el sistema podra tomar alguna accin
(las acciones son usualmente salidas de algn tipo de sistema o aplicacin).
6. En algunos casos, dos o ms condiciones son aplicadas al evento, el cul
influye sobre cul transicin ocurre, y por tanto cul accin es tomada.
7. Despus de que la transicin de estado ha ocurrido, el sistema est en un
nuevo estado o se ha mantenido en el actual.
Puedes disearse pruebas para cubrir una secuencia tpica de estados, cubrir
todos los estados, ejercitar todas las transiciones, ejercitar secuencias especficas
de transiciones o probar transiciones invlidas.
Criterio mnimo de cobertura diagrama de transicin de estados: Visitar
cada estado y atravesar cada transicin.
Una tabla de transiciones de estado muestra la relacin entre los estados y las
entradas, y eventualmente puede poner de manifiesto posibles transiciones no
vlidas.
Cmo construirla:
1. Haga una lista de todos los estados en el diagrama.
2. Haga una lista de todos los pares evento/condicin en el diagrama.
3. Crear una tabla con cada combinacin posible del estado con el par
evento/condicin.
4. Para cada combinacin de estado-evento/condicin, si el diagrama especifica
la accin que debe ser tomada y el nuevo estado al que se debe ingresar,
ponga aquella informacin en la fila correspondiente en la tabla. Si no,
escriba indefinido en aquellos dos campos en esa fila.
Criterio de cobertura mnimo: Cada fila debera tener una prueba
asociada (siempre que sea posible).
Tcnica adecuada para: industria del software integrado (automatizacin tcnica en
general), modelar un objeto de negocio, probar los flujos pantalla-dilogo
(aplicaciones Web).
4.3.5 Pruebas de caso de uso (K2)
Tcnica de diseo de prueba de caja negra en la que los casos de prueba estn diseados para ejecutar escenarios
de usuario.
Pruebas derivadas de casos de uso.

Un caso de uso describe las interacciones entre los actores, incluyendo usuarios y el
sistema, para producir un resultado de valor para un usuario de sistema o para el
cliente.
Los casos de uso pueden describirse tanto a nivel abstracto (caso de uso comercial,
nivel de proceso empresarial) como a nivel de sistema (caso de uso de sistema a
nivel de funcionalidad del mismo) .
Cada caso de uso tiene precondiciones que deben cumplirse para que el caso de uso
funcione correctamente.
41
Cada caso de uso termina con poscondiciones, que son los resultados observables y
el estado final del sistema una vez finalizado el caso de uso.
Generalmente, un caso de uso tiene un escenario principal (o ms probable) y
caminos alternativos.
Los casos de uso describen los flujos de proceso mediante un sistema basado en su
uso probable real.
Los casos de prueba derivados de los casos de uso resultan muy tiles a la hora
de descubrir defectos en los flujos de proceso durante el uso real del sistema.
Los casos de uso son de gran utilidad para disear las pruebas de aceptacin con
la participacin del cliente/usuario.
Asimismo, ayudan a descubrir eventuales defectos de integracin , provocados
por la interaccin y la interferencia de distintos componentes, que las pruebas de
componente a nivel individual no pueden detectar.
El diseo de los casos de prueba a partir de casos de uso pueden combinarse con
otras tcnicas de pruebas basadas en la especificacin.
4.4 Tcnicas basadas en la estructura o tcnicas de caja

blanca (K4)
Cobertura de cdigo
Mtodo de anlisis que determina qu partes del software han sido ejecutadas
(cubiertas) por el juego de pruebas y qu partes no han sido ejecutadas, ejemplo
cobertura de sentencia, cobertura de decisin o cobertura de condicin.
Cobertura de sentencia
Porcentaje de sentencias ejecutables que han sido practicadas por un juego de
pruebas.
Cobertura de rama
Porcentaje de ramas que han sido practicadas por un juego de pruebas. 100% de
cobertura de rama implica 100% de cobertura de decisin y 100% de cobertura de
sentencia.
Rama:
Bloque bsico que puede ser seleccionado para su ejecucin en base a una
estructura propia de un programa en la cual estn disponibles uno de dos o ms
caminos alternativos, por ejemplo case, jump, go to, ifthen-else.
Cobertura de decisin
Porcentaje de resultados de decisin que han sido practicados por un juego de
pruebas. El 100% de cobertura de decisin implica tanto un 100% de cobertura de
rama como un 100% de cobertura de sentencia.
Decisin:
Punto de un programa en el cual el flujo de control tiene dos o ms rutas

alternativas. Un nodo con dos o ms enlaces para separar ramas.
Cobertura de condicin
Porcentaje de los posibles resultados de una condicin que han sido practicados
por un juego de pruebas. Una cobertura de condicin del 100% requiere que cada
condicin simple de toda sentencia de decisin haya sido probada como
Verdadera y Falsa.
Pruebas basadas en la
Pruebas basadas en un anlisis de la estructura interna del componente o sistema.
estructura (Pruebas de
caja blanca)
42
Antecedentes
Las pruebas basadas en la estructura o de caja blanca se basan es una estructura

identificada del software o del sistema. Por ejemplo:
Nivel de componente: la estructura de un componente de software (sentencias,
decisiones, ramas, caminos distintos, ).
Nivel de integracin: la estructura puede ser un rbol de llamadas (un diagrama en
el que los mdulos llaman a otros mdulos).
Nivel de sistema: La estructura puede ser una estructura de mens, procesos de
negocio o una estructura de pgina Web.
En este apartado se tratan tres tcnicas de diseo de pruebas estructurales relacionadas con
el cdigo para la cobertura de cdigo en base a sentencias, ramas y decisiones.
Para las pruebas de decisiones, puede utilizarse un diagrama de flujo para visualizar las
alternativas de cada decisin.
Para disear pruebas estructurales/de caja blanca:
1. Analizar los flujos de control en el cdigo.
2. Utilizar ese anlisis para medir la cobertura de las pruebas existentes.
3. Adicionar las pruebas adicionales para alcanzar un nivel deseado de cobertura.
4.4.1 Pruebas de sentencias y cobertura (K4)

Pruebas de sentencias: Tcnica de diseo de pruebas de caja blanca en la cual los casos de prueba se
disean para ejecutar sentencias.
Cobertura de sentencia: Porcentaje de sentencias ejecutables que han sido practicadas por un juego de
pruebas.
En las pruebas de componente, la cobertura de sentencia es la evaluacin del porcentaje de

sentencias ejecutables que han sido practicadas por un juego de caso de prueba.
La tcnica de pruebas de sentencia obtiene casos de prueba para ejecutar sentencias
especficas, normalmente con vistas a aumentar la cobertura de sentencias.
La cobertura de sentencia viene determinada por el nmero de sentencias ejecutables
cubiertas (diseadas o ejecutadas) por casos de prueba dividido entre el nmero de todas las
sentencias ejecutables en el cdigo objeto de la prueba.
4.4.2 Pruebas de decisin y cobertura (K4)

Pruebas de decisiones: Tcnica de diseo de casos de prueba de caja blanca en la cual los casos de prueba se
disean para practicar resultados de decisiones.
Cobertura de decisin: Porcentaje de resultados de decisin que han sido practicados por un juego de pruebas. El
100% de cobertura de decisin implica tanto un 100% de cobertura de rama como un 100% de cobertura de
sentencia.
La cobertura de decisin, asociada a las pruebas de rama, es la evaluacin del porcentaje de

los resultados de decisin (por ejemplo, las opciones verdadero y falso de una sentencia IF)
que han sido practicados por un juego de casos de prueba.
La tcnica de prueba de decisin obtiene los casos de prueba para ejecutar resultados de
decisiones especficos.
Las ramas forman puntos de decisin en el cdigo.
La cobertura de decisin viene determinada por el nmero total de resultados de decisin
cubiertos (diseados o ejecutados) por casos de prueba dividido entre el nmero total de
posibles resultados de decisin en el cdigo objeto de la prueba.
Las pruebas de decisin constituyen una forma de pruebas de flujo de control ya que siguen
un flujo especfico de control a travs de los puntos de decisin.
43
La cobertura de decisin es ms fuerte que la cobertura de sentencia. Un 100% de cobertura
de decisin garantiza un 100% de cobertura de sentencia, pero no al contrario (ya que hay
IF's que no tienen ELSE, o SWITCH sin opcin por defecto. En ese caso hay un valor de la
decisin que implica no ejecutar ninguna sentencia y que debe ser probado).
4.4.3 Otras tcnicas basadas en la estructura (K1)

Cobertura de
Porcentaje de los posibles resultados de una condicin que han sido practicados por un
condicin juego de pruebas. Una cobertura de condicin del 100% requiere que cada condicin
simple de toda sentencia de decisin haya sido probada como Verdadera y Falsa.
Cobertura de
Porcentaje de combinaciones de todos los resultados de condiciones simples dentro de una
condicin mltiple sentencia, que han sido practicadas por un juego de pruebas. El 100% de cobertura de
(o de condicin mltiple implica el 100% de cobertura de condicin.
multicondicin)
Cobertura de
Variante leve de la cobertura de condicin mltiple. Nos fijamos en el porcentaje de las
condicin y combinaciones de las condiciones que pueden influenciar la decisin que ha sido probada.
decisin
modificada Por ejemplo: (edad >= 0) && (edad < 18) Si el valor de la edad es menor que 0 no hay
necesidad de considerar el valor de la segunda condicin.
El 100% de la cobertura de condicin mltiple implica el 100% de la cobertura de condicin
y decisin modificada.
Existen niveles ms fuertes de cobertura estructural adems de la cobertura de decisin,

como por ejemplo la cobertura de condicin y la cobertura de condicin mltiple.
El concepto de cobertura tambin puede aplicarse a otros niveles de prueba. Por ejemplo:
En el nivel de integracin: el porcentaje de mdulos, componentes o clases
practicados por un juego de casos de prueba podra expresarse como cobertura de
mdulo, componente o clase.
El uso de herramientas constituye un soporte til para las pruebas estructurales del cdigo.
4.5 Tcnicas basadas en la experiencia

Pruebas exploratorias
Tcnica informal de diseo de pruebas donde quien prueba controla
activamente el diseo de las pruebas a medida que las pruebas son realizadas
y utiliza la informacin obtenida durante las pruebas para disear unas nuevas y
mejores.
Ataque (falta)
Las pruebas basadas en la experiencia son aquellas en las que las pruebas se derivan de la
habilidad e intuicin del probador y de su experiencia con aplicaciones y tecnologas
similares.
Si se utilizan para aumentar las tcnicas sistemticas, estas tcnicas pueden ser tiles a la
hora de identificar pruebas especiales que no pueden capturarse fcilmente mediante
tcnicas formales, especialmente si se aplican despus de adoptar enfoques ms formales.
No obstante, esta tcnica puede tener distintos grados de efectividad, en funcin de la
experiencia del probador.
Prediccin de error:
Tcnica basada en la experiencia muy usada.
Los probadores anticipan los defectos en base a su experiencia.
Un enfoque estructurado de la tcnica de prediccin de error consiste en enumerar
una lista de posibles defectos y disear pruebas para atacar dichos defectos.
Este enfoque sistemtico se denomina ataque de faltas.
44
Esta lista de defectos y fallos puede elaborarse en base a la experiencia, a
los datos disponibles sobre defectos y fallos y a partir del conocimiento
comn sobre por qu falla el software.
Pruebas exploratorias: Tcnica informal de diseo de pruebas donde quien prueba controla
activamente el diseo de las pruebas a medida que las pruebas son realizadas y utiliza la
informacin obtenida durante las pruebas para disear unas nuevas y mejores.
Las pruebas exploratorias coinciden con las fases de diseo de pruebas, ejecucin de
pruebas, registro de pruebas y aprendizaje, en base a un contrato (plan) de pruebas
que contempla los objetivos de las pruebas, y se llevan a cabo dentro de los periodos
de tiempo establecidos.
Se trata de un enfoque especialmente til en los casos en los que las especificaciones
son escasas o inadecuadas y existe una importante presin temporal, o para
aumentar o complementar otras pruebas ms formales.
Asimismo, puede servir como comprobacin del proceso de pruebas, para ayudar a
garantizar que los defectos ms graves han sido efectivamente detectados.
4.6 Seleccin de tcnica de prueba (K2)

Ningn trmino especfico.
La seleccin de la tcnica de pruebas a utilizar depende de una serie de factores entre los
que se incluyen:
El tipo de sistema.
Los estndares normativos.
Los requisitos contractuales o de cliente.
El nivel/tipo de riesgo.
El objetivo de prueba.
La documentacin disponible.
El conocimiento de los probadores.
El tiempo y presupuesto.
El ciclo de vida de desarrollo.
Los modelos de caso de uso.
La experiencia previa en los tipos de defectos detectados.
Algunas tcnicas resultan ms aplicables a ciertas situaciones y niveles de prueba, mientras
que otras son aplicables a todos los niveles de pruebas.
Para crear casos de prueba, los probadores generalmente aplican una combinacin de
tcnicas de pruebas, entre las que se incluyen tcnicas guiadas por procesos, reglas y datos,
con vistas a garantizar la correcta cobertura del objeto que se est probando.
45
5 Gestin de pruebas (K3)
5.1 Organizacin de pruebas (K2)
Probador
Profesional experto que esta involucrado en las pruebas de un componente o sistema.
Lder de pruebas
Vase jefe de pruebas.
Jefe de pruebas
Persona responsable de la gestin de proyecto de las actividades y recursos de
pruebas, y de la evaluacin de un objeto de prueba. Individuo que dirige, controla,
administra, planifica y regula la evaluacin de un objeto de prueba.
5.1.1 Organizacin de pruebas e independencia (K2)
La efectividad de la identificacin de defectos del proceso de pruebas y revisin puede

mejorarse si se utilizan probadores independientes.
Alternativas para obtener independencia en las pruebas:
Ausencia de probadores independientes: los desarrolladores son lo que prueban su
propio cdigo.
Probadores independientes dentro de los equipos de desarrollo.
Equipos de prueba independientes o grupos dentro de la organizacin (que reporten
a la direccin de proyectos o direccin ejecutiva).
Probadores independientes procedentes de la organizacin comercial o de la
comunidad de usuarios.
Especialistas en pruebas independientes para tipos de pruebas especficas
(probadores de usabilidad, probadores de seguridad, probadores de certificacin -que
certifican un producto de software en base a los estndares y la normativa).
Los probadores independientes subcontratados o externos a la organizacin.
Para proyectos grandes, complejos o crticos para la seguridad, normalmente lo mejor es
contar con varios niveles de pruebas y poner alguno o todos los niveles a cargo de
probadores independientes.
El personal de desarrollo puede participar en las pruebas, especialmente en los niveles ms
bajos, pero su falta de objetividad a menudo limita su efectividad.
Los probadores independientes pueden tener potestad para exigir y definir procesos y reglas
de pruebas.
No obstante, los probadores slo debern asumir dicha funcin en relacin con los
procesos previa orden de la Direccin en ese sentido.
Ventajas de la independencia de las pruebas:
Los probadores independientes ven ms y diferentes defectos y son objetivos.
Un probador independiente puede comprobar los supuestos planteados durante las
fases de especificacin e implementacin del sistema.
Inconvenientes de la independencia de las pruebas:
Aislamiento del equipo de desarrollo (si se trata como totalmente independiente).
46
Los desarrolladores pueden llegar a perder el sentido de responsabilidad frente a la
calidad.
Los probadores pueden verse como cuellos de botella o ser culpados de retrasos en
el lanzamiento.
Las tareas de prueba pueden realizarlas personas con una funcin de pruebas
especfica, o por otra persona con otro cargo como jefe de proyecto, jefe de calidad,
desarrollador, experto de negocio y dominio, operaciones de infraestructura o TI.
5.1.2 Tareas del Lder de Pruebas y del Probador (K1)

Este programa de estudio cubre dos cargos de prueba: el lder de pruebas y el probador. Sus
actividades y tareas dependen del proyecto, contexto del producto, organizacin,
Lder de prueba = Jefe de pruebas = Coordinador de pruebas
El cargo de lder de pruebas puede desempearse por un jefe de proyecto, un jefe de
desarrollo, un jefe de aseguramiento de la calidad o el jefe de un grupo de pruebas.
En proyectos grandes puede haber dos cargos: lder de pruebas y jefe de pruebas.
Normalmente, el lder de pruebas es el que planifica, monitoriza y controla las actividades y
tareas de prueba.
Las tareas tpicas del lder de pruebas incluyen, entre otras:
Coordinar la estrategia de pruebas y planificar con los jefes de proyecto y dems
responsables.
Redactar o revisar una estrategia de pruebas para el proyecto, y una poltica de
pruebas para la organizacin.
Contribuir a la perspectiva de pruebas de otras actividades de proyecto, tales como
la planificacin de la integracin.
Planificar las pruebas teniendo en cuenta el contexto y entendiendo los objetivos y
riesgos de las pruebas incluyendo seleccionar los enfoques de prueba, calcular el
tiempo, el esfuerzo y el coste de las pruebas, contratar recursos, definir niveles de
prueba, ciclos y planificar la gestin de incidencias.
Iniciar la especificacin, preparacin, implementacin y ejecucin de pruebas, hacer
un seguimiento de los resultados de pruebas y comprobar los criterios de salida.
Adaptar la planificacin en base a los resultados y progreso de las pruebas (a veces
documentados en informes de estado) y adoptar todas las acciones necesarias para
compensar los problemas.
Establecer una gestin de la configuracin adecuada de los productos de soporte de
pruebas a efectos de su trazabilidad.
Introducir mtricas adecuadas para medir el progreso de las pruebas y evaluar la
calidad de las pruebas y del producto.
Decidir qu debe automatizarse, hasta qu punto y cmo.
Seleccionar las herramientas de soporte de las pruebas y organizar cursos de
formacin sobre el uso de dichas herramientas para los probadores.
Decidir sobre la implementacin del entorno de pruebas.
Redactar informes resmenes de pruebas en base a la informacin recopilada
durante las pruebas.
Las tareas tpicas del probador incluyen, entre otras:
Revisar y contribuir a los planes de pruebas.
Analizar, revisar y evaluar los requisitos de usuario, las especificaciones y los
modelos para su testeabilidad.
Crear especificaciones de prueba.
Configurar el entorno de pruebas (a menudo en coordinacin con administracin del
sistema y gestin de redes).
47
Preparar y obtener datos de prueba.
Implementar pruebas en todos los niveles de prueba, ejecutar y registrar las
pruebas, evaluar los resultados y documentar las desviaciones de los resultados
esperados.
Utilizar herramientas de administracin o gestin y herramientas de seguimiento de
prueba segn proceda.
Automatizar pruebas (puede contar con el soporte de un desarrollador o un experto
en automatizacin de pruebas).
Medir el rendimiento de los componentes y sistemas (si procede).
Revisar las pruebas desarrolladas por terceros.
Las personas dedicadas al anlisis de pruebas, al diseo de pruebas, a tipos de pruebas
especficas o a la automatizacin de pruebas pueden ser especialistas en estas tareas.
En funcin del nivel de prueba y de los riesgos asociados al producto y al proyecto , hay
distintas personas que pueden asumir el papel de probador manteniendo cierto grado de
independencia.
En general, los probadores a nivel de componente e integracin son los desarrolladores, los
probadores a nivel de pruebas de aceptacin son los expertos de negocio y usuarios, y los
probadores de pruebas de aceptacin operativas son los operadores.
5.2 Planificacin y estimacin de pruebas (k3)

Enfoque (mtodo) de
Implementacin de la estrategia de pruebas definida para un proyecto especfico.
pruebas
Estrategia de pruebas
Descripcin de alto nivel de los niveles de prueba a ser llevados a cabo y las pruebas
dentro de estos niveles para una organizacin o programa (en uno o ms proyectos).
Pruebas exploratorias
Tcnica informal de diseo de pruebas donde quien prueba controla activamente el
diseo de las pruebas a medida que las pruebas son realizadas y utiliza la informacin
obtenida durante las pruebas para disear unas nuevas y mejores.
5.2.1 Planificacin de pruebas (k2)
La planificacin podr documentarse en un plan de pruebas maestro y en planes de prueba

separados para niveles de prueba.
El diseo de un documento para la planificacin de pruebas se aborda en la Norma para la
documentacin de prueba de software IEEE 829.
Secciones del plan de pruebas IEEE 829:
1. Identificador del plan de pruebas.
2. Introduccin.
3. tems (elementos de prueba).
4. Caractersticas a probar / que no deben ser probadas.
5. Mtodo/Enfoque de prueba (implementacin de la estrategia de prueba para el
proyecto).
6. Criterios paso/falla del tem.
7. Criterios de entrada, salida, suspensin, reanudacin.
8. Entregables de las pruebas.
48
9. Tareas/Hitos clave de las pruebas.
10. Cronograma.
11. Necesidades del entorno.
12. Responsabilidades.
13. Dotacin de personal y necesidades de capacitacin.
14. Riesgos (de calidad de producto y de proyecto).
15. Aprobaciones.
La planificacin se ve afectada por:

La poltica de pruebas de la organizacin.
El alcance de las pruebas.
Los objetivos.
Los riesgos.
Las limitaciones del proyecto (coste, tiempo, alcance)
La criticidad (del sistema)
La testeabilidad
La disponibilidad de recursos
A medida que la planificacin del proyecto y de las pruebas van avanzando habr ms
informacin disponible y el plan podr incluir ms detalles.
La planificacin de pruebas es una actividad continua que se lleva a cabo en todos los
procesos del ciclo de vida y actividades.
El feedback de las actividades de pruebas sirve para reconocer los riesgos
cambiantes con vistas a ajustar la planificacin.
5.2.2 Actividades de planificacin de pruebas (K3)

Las actividades de planificacin para un sistema completo o para parte de un sistema pueden
incluir:
Determinar el alcance y los riesgos e identificar los objetivos de las pruebas.
Definir el enfoque global de las pruebas, incluida la definicin de los niveles de
pruebas y los criterios de entrada y salida.
Integrar y coordinar las actividades de pruebas en las actividades de ciclo de vida del
software (adquisicin, suministro, desarrollo, operacin y mantenimiento).
Adoptar decisiones sobre qu probar, qu cargos llevarn a cabo las actividades de
pruebas, cmo deberan realizarse las actividades de pruebas y cmo se evaluarn
los resultados de las pruebas.
Programar las actividades de anlisis y diseo de las pruebas.
Programar la implementacin, ejecucin y evaluacin de las pruebas.
Asignar recursos para las distintas actividades definidas.
Definir la cantidad, el nivel de detalle, la estructura y las plantillas para la
documentacin de las pruebas.
Seleccionar mtricas para el seguimiento y el control de la preparacin y ejecucin
de las pruebas, la resolucin de defectos y los temas de riesgos.
Establecer el nivel de detalle de los procedimientos de prueba para facilitar
informacin suficiente para dar soporte a la preparacin y ejecucin reproducible de
pruebas.
49
5.2.3 Criterios de entrada (K2)
Los criterios de entrada establecen cundo iniciar las pruebas (por ejemplo, al inicio de un
nivel de prueba o cuando una serie de pruebas est lista para su ejecucin).
En general, los criterios de entrada pueden cubrir lo siguiente:
Disponibilidad y disposicin del entorno de pruebas.
Disposicin de las herramientas de prueba en el entorno de pruebas.
Disponibilidad de cdigo testeable.
Disponibilidad de datos de prueba.
5.2.4 Criterios de salida (K2)

Los criterios de salida establecen cundo detener las prueba (por ejemplo, al final de un nivel
de prueba o cuando una serie de pruebas haya logrado un objetivo especfico).
En general, los criterios de salida pueden cubrir lo siguiente:
Medidas de exhaustividad, tales como la cobertura de cdigo, la funcionalidad o el
riesgo.
Estimaciones de densidad de defectos o medidas de fiabilidad.
Coste.
Riesgos residuales, tales como defectos no corregidos o ausencia de Cobertura de
pruebas en determinadas reas.
Calendarios, como los basados en el plazo de comercializacin.
5.2.5 Estimacin de pruebas (K2)

Dos enfoques distintos para estimar el esfuerzo de pruebas son:
El enfoque basado en mtricas: estimar el esfuerzo de pruebas en base a mtricas
de proyectos anteriores o similares o en base a valores tpicos.
El enfoque basado en expertos: estimar las tareas en base a las estimaciones hechas
por el propietario de las tareas o por los expertos.
Una vez estimado el esfuerzo de la prueba, pueden identificarse los recursos y elaborarse un
calendario.
El esfuerzo de prueba puede depender de una serie de factores, entre los que se incluyen:
Las caractersticas del producto.
La calidad de la especificacin y dems informacin utilizada para modelos de
prueba (es decir, la base de la prueba).
El tamao del producto.
La complejidad del dominio del problema.
Los requisitos de fiabilidad y seguridad.
Los requisitos de documentacin.
Las caractersticas del proceso de desarrollo.
La estabilidad de la organizacin.
Las herramientas utilizadas.
El proceso de pruebas.
Las habilidades de las personas implicadas.
La presin temporal.
El resultado de las pruebas.
El nmero de defectos.
La cantidad de cambios necesarios.
50
5.2.6 Estrategia de pruebas, enfoque de pruebas (K2)
Enfoque de pruebas = Aplicacin de la estrategia de pruebas para un proyecto especfico.

El enfoque de pruebas se define y redefine en los planes y diseos de prueba.
Generalmente incluye las decisiones tomadas en base a:
El objetivo del proyecto de pruebas.
La evaluacin de los riesgos del proyecto de pruebas.
Constituye el punto de inicio para:
Planificar el proceso de pruebas.
Seleccionar las tcnicas de diseo de pruebas.
Seleccionar los tipos de pruebas a aplicar.
Definir los criterios de entrada y salida.
El enfoque seleccionado depender del contexto y puede tener en cuenta:
Los riesgos.
Los peligros y la seguridad.
Los recursos disponibles y habilidades.
La tecnologa.
La naturaleza del sistema (p.ej. Personalizado vs COTS).
Los objetivos de prueba.
La normativa.
Entre los enfoques tpicos se incluyen:
1. Enfoques analticos, como las pruebas basadas en riesgos en las que las
pruebas se concentran en las reas de mayor riesgo.
2. Enfoques basados en modelos, como las pruebas estocsticas que utilizan
informacin estadstica sobre frecuencias de fallos (tales como los modelos de
fiabilidad de crecimiento) o uso (tales como perfiles operativos).
3. Enfoques metdicos, como los basados en fallos (incluyendo la prediccin de
errores y los ataques de faltas), los basados en la experiencia, los basados en
listas de comprobacin y los basados en caractersticas de calidad.
4. Enfoques de proceso o enfoques ajustados a las normas, como los
especificados en las normas especficas del sector o en las distintas metodologas
giles.
5. Enfoques dinmicos y heursticos, como las pruebas exploratorias en las que
las pruebas son ms reactivas a eventos en lugar de estar planificadas con
antelacin, y en las que las tareas de ejecucin y evaluacin son simultneas.
6. Enfoques consultivos, como aquellos en los que la Cobertura de pruebas se
establece principalmente en base a las recomendaciones y orientaciones de los
expertos de tecnologa y/o negocio ms all del equipo de pruebas.
7. Enfoques anti-regresin, como los que incluyen la reutilizacin del material de
pruebas existente, la automatizacin extensiva de pruebas de regresin funcionales y
juegos de prueba estndar.
Pueden combinarse varios enfoques y adoptar, por ejemplo, un enfoque dinmico basado en
el riesgo.
51
5.3 Seguimiento y control del progreso de las pruebas
(K2)
Densidad de defectos
Nmero de defectos identificados en un componente o sistema dividido por el
tamao del mismo (expresado en trminos de medidas estndar, por ejemplo
lneas de cdigo, nmero de clases o puntos de funcin).
Frecuencia de fallos
Cociente del nmero de fallos de una categora dada por unidad de medida
especifica, por ejemplo fallos por unidad de tiempo, fallos por unidad de
transacciones, fallos por nmero de ejecuciones de programa.
Control de pruebas
Tarea de la gestin de pruebas que se encarga de desarrollar y aplicar un
conjunto de acciones correctivas para poner el proyecto de pruebas en la
direccin correcta cuando el seguimiento (monitorizacin) muestra una
desviacin con respecto a lo que se haba planificado. Vase tambin gestin
de pruebas.
Monitorizacin de pruebas
Tarea de gestin de pruebas que se ocupa de las actividades relacionadas
con la comprobacin peridica del estado de un proyecto de pruebas. Se
preparan informes que comparan el estado real con lo que fue planificado.
Seguimiento de pruebas
(Vase control y monitorizacin de pruebas)
Informe resumen de pruebas

Documento que resume las actividades y resultados de las pruebas. Tambin
contiene una evaluacin de los correspondientes elementos de prueba
respecto de los criterios de salida.
5.3.1 Seguimiento del progreso de las pruebas (K1)
El objetivo del seguimiento de las pruebas es facilitar feedback y visibilidad sobre las
actividades de pruebas.
La informacin a controlar puede recopilarse de forma manual o automtica y puede
utilizarse para medir los criterios de salida, tales como la cobertura.
Las mtricas tambin pueden utilizarse para evaluar el progreso contra el programa y el
presupuesto previstos.
Entre las mtricas de prueba ms comunes se incluyen:
Porcentaje de trabajo realizado en la preparacin de los casos de prueba (o
porcentaje de casos de prueba planificados preparados).
Porcentaje de trabajo realizado en la preparacin del entorno de pruebas.
Cmputo y porcentajes de ejecucin de los casos de prueba (por ejemplo, nmero de
casos de prueba ejecutados/no ejecutados, y casos de prueba superados/fallidos).
Informacin sobre defectos (por ejemplo, densidad de los defectos, defectos
detectados y corregidos, frecuencia de fallos y resultados de la repeticin de
pruebas).
Cobertura de pruebas de los requisitos, riesgos o cdigo.
Confianza subjetiva de los probadores en el producto.
Fechas de hitos de las pruebas.
Coste de las pruebas, incluyendo el coste comparado con el beneficio de detectar el
siguiente defecto o de ejecutar la siguiente prueba.
52
5.3.2 Informes de pruebas (K2)
Los informes de pruebas tienen por objeto describir los resultados de un nivel dado o fase de
pruebas, teniendo en cuenta:
Qu ha pasado durante un periodo de prueba (eventos clave), o la medicin del
cumplimiento de los criterios de salida para una reunin propuesta acerca de la
salida de las pruebas.
Anlisis de informacin y mtricas para respaldar las recomendaciones y decisiones
sobre acciones futuras, tales como una evaluacin de los defectos restantes, el
beneficio econmico de las pruebas continuadas, los riesgos pendientes y el nivel
subjetivo de confianza en el software probado.
El diseo de un informe resumen de pruebas se aborda en la Norma para la documentacin
de pruebas de software IEEE 829.
Secciones informe de resumen de pruebas segn IEEE 829
1. Identificador del informe.
2. Resumen (lo que fue probado, ...).
3. Varianzas/Desviaciones (del plan, de los casos...).
4. Evaluacin comprensiva.
5. Resumen de resultados (mtricas finales, cmputos,...).
6. Evaluacin (de cada tem de prueba con relacin a los criterios de
paso/falla).
7. Resumen de las actividades (utilizacin de los recursos, eficiencia, ...).
8. Aprobacin.
Las mtricas deben recopilarse durante y al final de cada nivel de prueba con vistas a
evaluar:
La idoneidad de los objetivos de la prueba para dicho nivel de prueba.
La idoneidad de los enfoques de prueba adoptados.
La efectividad de las pruebas por lo que respecta a los objetivos.
Registro de pruebas: Registro cronolgico de los detalles relevantes respecto a la

ejecucin de pruebas.
Secciones registro de pruebas segn IEEE 829
1. Identificador del registro de pruebas.
2. La descripcin de las pruebas (tems sometidos a prueba versionados, entornos
de prueba utilizados, ).
3. Datos de actividades y eventos (descritos prueba tras prueba y evento tras
evento).
5.3.3 Control de pruebas (K2)

El control de pruebas describe cualquier accin orientativa o correctiva adoptada como
resultado de la informacin y las mtricas recopiladas e incluidas en un informe.
Las acciones pueden referirse a cualquier actividad de prueba y pueden afectar a cualquier
actividad o tarea del ciclo de vida del software.
Algunos ejemplos de acciones de control de pruebas incluyen:
Tomar decisiones en base a informacin obtenida del seguimiento de las pruebas.
Restablecer la prioridad de las pruebas si sucede un riesgo identificado (por ejemplo,
demora en la entrega del software).
53
Cambiar el calendario de pruebas por motivos de disponibilidad o no disponibilidad
de un entorno de pruebas.
Establecer un criterio de entrada que requiera la repeticin de las pruebas de las
correcciones (pruebas de confirmacin) por parte de un desarrollador antes de
aceptarlas en una construccin.
5.4 Gestin de la configuracin (K2)

Gestin de la configuracin
Disciplina que aplica direccin y supervisin tcnica y administrativa a: identificar
y documentar las caractersticas funcionales y fsicas de un elemento de la
configuracin, controlar cambios de esas caractersticas, registrar e informar
sobre el estado de la implementacin y proceso de cambio, y verificar la
conformidad con los requisitos especificados.
Control de versin / Control

Elemento de la gestin de la configuracin consistente en la evaluacin,
de la configuracin coordinacin, aprobacin o desaprobacin e implementacin de los cambios en
los elementos de la configuracin tras el establecimiento formal de la
identificacin de la configuracin.
El objetivo de la gestin de la configuracin es establecer y mantener la integridad de los

productos (componentes, datos y documentacin) del software o sistema a travs del ciclo
de vida del proyecto o del producto.
En el caso de las pruebas, la gestin de la configuracin puede implicar garantizar lo

siguiente:
Todos los elementos de soporte de prueba han sido identificados, se ha llevado a
cabo un control de versin, se han localizado los cambios, tanto entre s como en
relacin con los elementos de desarrollo (objetos de prueba) de manera que puede
mantenerse la trazabilidad a lo largo de todo el proceso de pruebas.
Todos los documentos y elementos de software identificados estn referenciados de
manera clara en la documentacin de prueba.
Para el probador, la gestin de la configuracin le ayuda a identificar (y reproducir) de
manera unvoca el elemento probado, los documentos de prueba, las pruebas y los arneses
de pruebas.
Durante la planificacin de las pruebas, deben seleccionarse, documentarse e implementarse
los procedimientos de gestin de la configuracin y las herramientas de infraestructura.

versiones): describe los tems que deben ser entregados para las pruebas.
Secciones del informe de transmisin de los tems de pruebas segn IEEE 829:
2. Los tems transmitidos (incluyendo nombres de los tems y nmeros de revisin).
3. El lugar (ubicacin) del objeto o tem de pruebas.
4. El estado del objeto o tem de pruebas (incluyendo los defectos corregidos y
cambios introducidos).
5. Quin aprob ese objeto o tem para la versin que debe ser probada.
54
5.5 Riesgos y pruebas
Riesgo
Factor que puede resultar en futuras consecuencias negativas, expresada
normalmente como impacto y probabilidad.
Riesgo de producto
Riesgo directamente relacionado con el objeto de prueba.
Riesgo de proyecto
Riesgo relativo a la gestin y control de un proyecto ( de pruebas), por ejemplo,
falta de personal, plazos estrictos, requisitos cambiantes, etc..
Pruebas basadas en
Enfoque de pruebas para reducir el nivel de riesgos de producto e informar a los
riesgos afectados de su estado, comenzando desde las fases iniciales de un proyecto.
Implica la identificacin de riesgos de producto y su uso para dirigir el proceso de
pruebas.
Antecedentes
Riesgo = Oportunidad de un evento, peligro, amenaza o situacin que sucede y tiene como
resultados consecuencias no deseadas o un problema potencial.
Nivel de riesgo = Probabilidad (de que ocurra un evento adverso) x Impacto (dao resultante
de dicho evento)
5.5.1 Riesgos de proyecto (K2)

Los riesgos de proyecto son los riesgos relativos a la capacidad del proyecto de lograr sus
objetivos.
Ejemplos de riesgos de proyecto:
Factores de organizacin:
Aptitudes, formacin y falta de personal.
Aspectos polticos, tales como:
Problemas con la forma en la que los probadores comunican sus necesidades
y resultados de las pruebas.
Incapacidad del equipo de hacer un seguimiento de la informacin
encontrada durante las pruebas y revisiones (por ejemplo, no se mejora el
desarrollo y las prcticas de pruebas).
Actitud indebida o falsas expectativas ante las pruebas (por ejemplo, no valorar
el valor de detectar defectos durante las pruebas).
Aspectos tcnicos:
Problemas para definir los requisitos adecuados.
La medida en que no pueden cumplirse los requisitos dadas las limitaciones
existentes.
El entorno de pruebas no est listo a tiempo.
Demora en la conversin de datos, planificacin y desarrollo de migracin y
conversin de datos de prueba/herramientas de migracin.
Baja calidad del diseo, cdigo, datos de configuracin, datos de prueba y
pruebas.
Aspectos de proveedores:
Fallos de terceros.
55
Aspectos contractuales.
A la hora de analizar, gestionar y mitigar estos riesgos, el jefe de pruebas debe seguir
principios de gestin de proyectos bien establecidos.
La Norma de Documentacin de pruebas de software IEEE 829 esboza los planes
de prueba y exige que se indiquen los riesgos y contingencias.
5.5.2 Riesgos de producto (K2)

Las posibles rea de fallo (eventos futuros adversos o peligros) en el software o sistema se
conocen como riesgos de producto, ya que suponen un riesgo para la calidad del producto.
Ejemplos de riesgos de producto:
El software entregado es proclive a los fallos.
La posibilidad de que el software/hardware pueda daar a un individuo o a una
empresa.
Malas caractersticas del software (por ejemplo, carencias en la funcionalidad,
fiabilidad, usabilidad o rendimiento).
Mala integridad y calidad de los datos (por ejemplo, problemas de migracin de
datos, problemas de conversin de datos, problemas de transporte de datos,
violacin de estndares de datos).
El software no realiza las funciones previstas.
Utilidad de los riesgos de producto: Sirven para decidir por dnde empezar las pruebas y
dnde probar ms.
A su vez, las pruebas sirven para reducir el riesgo de que suceda un efecto adverso
(probabilidad), o para reducir el impacto del mismo.
Los riesgos de producto constituyen un tipo especial de riesgo para el xito de un proyecto.
El hecho de realizar pruebas a modo de actividad de control del riesgo proporciona feedback
sobre el riesgo residual midiendo la efectividad de la eliminacin de los defectos crticos y los
planes de contingencia.
El enfoque basado en el riesgo en las pruebas ofrece oportunidades proactivas de reducir los
niveles de riesgo de producto, empezando en las etapas iniciales de un proyecto.
Este enfoque implica la identificacin de riesgos de producto y su uso en la
planificacin de las pruebas y especificacin de control, preparacin y ejecucin de
las pruebas.
En un enfoque basado en el riesgo, los riesgos identificados pueden utilizarse para:
Establecer las tcnicas de pruebas a emplear.
Establecer el alcance de las pruebas a ejecutar.
Priorizar las pruebas en un intento por identificar los defectos crticos lo antes
posible.
Establecer si podra utilizarse alguna actividad no de prueba para reducir el
riesgo (por ejemplo, impartir formacin a diseadores sin experiencia).
Las pruebas basadas en riesgos se basan en el conocimiento colectivo y en la
comprensin de las partes interesadas del proyecto para establecer los riesgos y los
niveles de pruebas necesarios para abordar dichos riesgos.
Con vistas a garantizar que la posibilidad de fallo de un producto es mnima, las actividades
de gestin del riesgo establecen un enfoque disciplinado para:
Evaluar (y re-evaluar de manera regular) qu puede fallar (riesgos).
Establecer qu riesgos son importante tratar.
Implementar acciones para abordar dichos riesgos.
Adems, las pruebas pueden contribuir a identificar nuevos riesgos, pueden ayudar a
establecer qu riesgos deben reducirse y pueden reducir la incertidumbre sobre los riesgos.
56
5.6 Gestin de incidencias (K3)
Incidencia
Cualquier ocurrencia de un suceso que requiere investigacin.
Registro de / Registrar
Accin de consignar los detalles de cualquier incidencia ocurrida, por ejemplo
incidencias durante las pruebas.
Gestin de incidencias
Proceso de reconocimiento, investigacin, toma de medidas y eliminacin de
incidencias. Comprende registrar incidencias, clasificarlas e identificar el impacto.
Informe de incidencias
Documento que informa de la ocurrencia de cualquier suceso, por ejemplo durante
las pruebas, que requiere investigacin.
Dado que uno de los objetivos de las pruebas es la deteccin de defectos, las discrepancias
entre los resultados reales y los resultados esperados deben registrarse como incidencias.
Todas las incidencias deben ser investigadas, ya que algunas pueden constituir defectos.
Las incidencias y los defectos se rastrean desde su identificacin y clasificacin hasta la
correccin y confirmacin de su solucin.
Con vistas a gestionar todas las incidencias hasta su complecin, la organizacin debe
establecer un proceso de gestin de incidencias y normas para su clasificacin.
Las incidencias pueden surgir durante el desarrollo, la revisin, las pruebas o el uso de un
producto de software.
Asimismo, pueden surgir por problemas en el cdigo o en el sistema de
funcionamiento, o en cualquier tipo de documentacin (requisitos, documentos de
desarrollo, documentos de prueba e informacin de usuario -como guas de ayuda o
instalacin-).
Objetivos de los informes de incidencias:
Facilitar feedback sobre el problema a los desarrolladores y dems partes implicadas
permitiendo su identificacin, aislamiento y correccin.
Proporcionar a los lderes de prueba un medio de seguimiento de la calidad del
sistema probado y del progreso de las pruebas.
Aportar ideas para la mejora del proceso de pruebas.
El informe de incidencias puede incluir los siguientes detalles:
a) Fecha de expedicin (creacin), organizacin emisora y autor
(creador/informante).
b) Resultados esperados y resultados reales.
c) Identificacin del elemento de prueba (elemento de configuracin) y entorno.
d) Proceso del ciclo de vida del software o del sistema en el que se ha observado la
incidencia.
e) Descripcin de la incidencia para permitir su reproduccin y resolucin,
incluyendo registros, volcados de bases de datos o pantallazos.
f) Alcance o grado de impacto en los intereses de las partes interesadas.
g) Gravedad del impacto en el sistema.
h) Urgencia/prioridad de su correccin.
i) Estado de la incidencia (por ejemplo, abierta, diferida, duplicada, esperando
correccin, corregida esperando la repeticin de las pruebas, cerrada).
j) Conclusiones, recomendaciones y autorizaciones.
57
k) Aspectos globales, como otras reas que pueden verse afectadas por un cambio
derivado de la incidencia.
l) Historial del cambio, como la secuencia de acciones adoptadas por los miembros
del equipo de proyecto por lo que respecta a la incidencia para aislarla, repararla y
confirmarla como corregida.
m) Referencias, incluyendo la identidad de la especificacin de caso de prueba que
puso de manifiesto el problema.
La estructura de los informes de incidencias se aborda en la Norma para la documentacin
de pruebas de software IEEE 829.
Secciones de un informe de incidencias segn IEEE 829:
2. Resumen (describe especialmente el impacto acerca de los interesados de negocio).
3. Descripcin de la incidencia.
Entradas (posibles anomalas observadas en las mismas).
Resultados esperados vs Resultados reales.
Fecha/Hora cuando se observaron las anomalas.
Entorno de pruebas en el cul las anomalas fueron observadas.
Identificador del caso de prueba o procedimiento que detect la anomala.
La reproducibilidad del fallo.
El informador de la incidencia.

58
6 Herramientas de soporte de pruebas (K2)
Falta comparar trminos del tema 6 con glosario 2011.
6.1 Tipos de herramientas de pruebas (K2)

Orculo de prueba
Fuente para determinar resultados esperados para compararlos con los
resultados reales del software en pruebas. Un orculo puede ser un sistema
existente (para una evaluacin comparativa), un manual de usuario o el
conocimiento especializado de un individuo, pero no debera ser el cdigo.
Herramienta de gestin de
la configuracin
Herramienta de cobertura
Herramienta de depuracin
Herramienta de anlisis
dinmico
incidencias
Herramienta de pruebas de
carga
Herramienta de modelado
Herramienta de
monitorizacin
rendimiento
Efecto sonda
Efecto producido por el instrumento de medida sobre el sistema o componente
que est siendo medido, por ejemplo mediante una herramienta de pruebas de
rendimiento o un monitor. Por ejemplo el rendimiento puede ser ligeramente peor
cuando las herramientas de prueba de rendimiento estn siendo usadas.
requisitos
Herramienta de revisin
Herramienta de seguridad
Herramienta de anlisis
esttico
estrs
Comparador de pruebas
Herramienta de pruebas para realizar comparaciones automticas de pruebas
entre los resultados obtenidos y los resultados esperados.
Comparacin de pruebas:
Proceso de identificacin de las diferencias entre los resultados reales

producidos por el componente o sistema en pruebas y los resultados esperados
para la prueba. La comparacin de pruebas puede ser llevada a cabo durante la
ejecucin de la prueba (comparacin dinmica) o con posterioridad a la
ejecucin de la prueba.
Herramienta de
preparacin de datos de
59
prueba
Herramienta de diseo de
pruebas
Arns de prueba
Herramienta de ejecucin
de pruebas
pruebas
Herramienta de marco de
trabajo de pruebas
unitarias
6.1.1 Significado y objetivo de las herramientas de soporte de pruebas (K2)

Las herramientas de pruebas pueden utilizarse en una o ms actividades de soporte de
pruebas.
Ejemplos de herramientas de pruebas:
Las herramientas que se utilizan directamente en las pruebas:
Herramientas de ejecucin de pruebas.
Herramientas de generacin de datos de prueba.
Herramientas de comparacin de resultados.
...
Las herramientas que ayudan a gestionar el proceso de pruebas:
Herramientas de gestin de pruebas, resultados de pruebas, datos, requisitos,
incidencias, defectos,
Herramientas para elaborar informes y monitorizar la ejecucin de pruebas.

Las herramientas usadas para el reconocimiento o exploracin:
Herramientas que monitorizan la actividad de ficheros de una aplicacin.
Cualquier herramienta que contribuye al proceso de pruebas (desde las ms
sofisticadas a una simple hoja de clculo).
Las herramientas de soporte de pruebas pueden tener uno o ms de los siguientes objetivos
en funcin del contexto:
1) Mejorar la eficiencia de las tareas de pruebas automatizando tareas repetitivas o
dando soporte a las actividades de pruebas manuales (como la planificacin, el
diseo, la elaboracin de informes y la monitorizacin de pruebas).
2) Automatizar aquellas actividades que requieren muchos recursos si se hacen de
manera manual (como por ejemplo, las pruebas estticas).
3) Automatizar aquellas actividades que no pueden ejecutarse de forma manual (por
ejemplo, pruebas de rendimiento).
4) Aumentar la fiabilidad de las pruebas (por ejemplo, automatizando las
comparaciones de grandes ficheros de datos y simulando comportamientos).
El trmino marcos de trabajo de pruebas (test framework) se utiliza a menudo en el sector
y puede tener, como mnimo, cualquiera de los tres siguientes significados (aunque en el
caso del presente programa de estudio solo se contemplan los dos primeros):
Libreras de pruebas reutilizables y ampliables que pueden utilizarse para crear
herramientas de pruebas (tambin conocido como arns de pruebas).
Un tipo de diseo de automatizacin de pruebas (por ejemplo, guiada por datos o
guiadas por palabras clave).
60
Proceso general de ejecucin de las pruebas.
6.1.2 Clasificacin de herramientas de prueba (K2)
En este programa de estudio las herramientas se clasifican en funcin de las actividades de

pruebas a las que dan soporte.
Algunas herramientas dan soporte a una actividad de manera clara, mientras que otras
pueden dar soporte a ms de una actividad, pero se clasifican dentro de la actividad a la que
estn ms estrechamente vinculadas.
Algunos tipos de herramientas de prueba puede ser intrusivos, es decir, pueden afectar al
resultado real de la prueba.
Por ejemplo, los tiempo reales pueden diferir debido a las instrucciones adicionales
que la herramienta ejecuta, o incluso puede obtenerse una medida distinta de
cobertura de cdigo.
La consecuencia del uso de herramientas intrusivas se denomina efecto sonda.
Algunas herramientas ofrecen un soporte ms adecuado para los desarrolladores (como por
ejemplo, las herramientas que se utilizan durante las pruebas de componente y de
integracin de componentes). Estas herramientas aparecen marcadas con el smbolo (D)
en la lista a continuacin.
6.1.3 Herramientas de soporte para la gestin de pruebas (K1)

Las herramientas de gestin son aplicables a todas las actividades de pruebas durante todo
el ciclo de vida del software.
Herramientas de gestin de pruebas.
Ofrecen interfaces para ejecutar pruebas, localizar defectos y gestionar
requisitos.
Dan soporte al anlisis cuantitativo y a la elaboracin de informes sobre los
objetos de prueba.
Ayudan a localizar los objetos de prueba conforme a las especificaciones de
requisitos y pueden tener una capacidad de control de versin independiente o
una interfaz conforme a una externa.
Herramientas de gestin de requisitos.
Almacenan sentencias de requisitos.
Almacenan los atributos de los requisitos (incluida la prioridad).
Proporcionan identificadores nicos.
Facilitan la localizacin de los requisitos para pruebas individuales.
Ayudan a identificar la ausencia o la inconsistencia de requisitos.
Herramientas de gestin de incidencias (Herramientas de seguimiento de
defectos).
Almacenan y gestionan informes de incidencias, es decir, defectos, fallos, cambio
de peticiones o problemas y anomalas percibidas.
Ayudan a gestionar el ciclo de vida de las incidencias.
Opcionalmente, Proporcionan soporte al anlisis estadstico.
Herramientas de gestin de la configuracin.
Son necesarias para el almacenamiento y la gestin de versiones de productos
de soporte de prueba (testware) y software asociado.
Especialmente a la hora de configurar ms de un entorno de hardware/software
en trminos de versiones del sistema operativo, compiladores, navegadores, etc.
61
6.1.4 Herramientas de soporte para las pruebas estticas (K1)
Las herramientas de prueba esttica proporcionan una manera efectiva de localizar ms
defectos en una etapa ms temprana del proceso de desarrollo.
Herramientas de revisin.
tiles en los procesos de revisin, listas de comprobacin y directrices de
revisin.
Se utilizan para almacenar y comunicar comentarios de revisin, informes sobre
defectos y esfuerzos.
Pueden servir de ayuda para las revisiones en lnea de equipos grandes o
geogrficamente dispersos.
Herramientas de anlisis esttico (D).
Ayudan a los desarrolladores y probadores a localizar defectos antes de realizar
pruebas dinmicas proporcionndoles soporte para aplicar las normas de
codificacin (incluyendo codificacin segura), el anlisis de las estructuras y las
dependencias.
Pueden ser tiles para planificar o analizar los riesgos facilitando mtricas para el
cdigo (por ejemplo, complejidad ciclomtica).
Herramientas de modelado (D).
Se utilizan para validar modelos de software (tales como modelos de datos fsicos
-Physical Data Model / PDM- de una base de datos relacional) enumerando
inconsistencias y localizando defectos.
A menudo sirven para generar algunos casos de prueba basados en un modelo.
6.1.5 Herramientas de soporte para la especificacin de prueba (K1)

Herramientas de diseo de pruebas.
Sirven para generar entradas de prueba o pruebas ejecutables y/o orculos de
prueba a partir de requisitos, interfaces grficas de usuario, modelos de diseo
(estado, dato u objeto) o cdigo.
Herramientas de preparacin de datos de prueba.
Manejan bases de datos, archivos o transmisiones de datos para configurar los
datos de prueba que se utilizan durante la ejecucin de pruebas con vistas a
garantizar la seguridad a travs del anonimato de los datos.
6.1.6 Herramientas de soporte para la ejecucin y el registro de pruebas (K1)

Herramientas de ejecucin de pruebas.
Permiten ejecutar pruebas de manera automtica, o semiautomtica, utilizando
entradas almacenadas y resultados esperados, a travs del uso de un lenguaje
de creacin de scripts.
Generalmente ofrecen un registro de prueba para cada ejecucin de una prueba.
Pueden servir para registrar pruebas.
Normalmente soportan lenguaje de creacin de scripts o una configuracin
basada en GUI para la parametrizacin de datos y dems personalizacin durante
las pruebas.
Arns de pruebas/Herramientas de marco de trabajo de pruebas unitarias .
Unit Test Framework Tools (D).
Facilitan el proceso de pruebas en componentes o partes de un sistema
simulando el entorno en el que se ejecutar dicho objeto de prueba, a travs de
la creacin de objetos de imitacin -mock objects- como stubs o controladores.
Comparadores de pruebas.
Establecen las diferencias entre archivos, bases de datos o resultados de
pruebas.
62
Las herramientas de ejecucin de pruebas normalmente incluyen comparadores
dinmicos, pero la comparacin posterior a la ejecucin a menudo debe hacerse
con una herramienta de comparacin separada.
Los comparadores de pruebas pueden utilizar orculos de pruebas,
especialmente si estn automatizados.
Herramientas de medicin de la cobertura (D).
A travs de medios intrusivos o no intrusivos, miden el porcentaje de tipos
especficos de estructuras de cdigo que han sido practicados (por ejemplo,
sentencias, ramas o decisiones y llamadas a mdulos o funciones) por parte de
un conjunto de pruebas.
Herramientas de pruebas de seguridad.
Sirven para evaluar las caractersticas de seguridad del software (como la
capacidad de proteger la confidencialidad, integridad, autenticacin, autorizacin,
disponibilidad o no repudio de los datos.
Se centran principalmente en una tecnologa, plataforma y alcance especficos.
6.1.7 Herramientas de soporte para el rendimiento y la monitorizacin (K1)

Herramientas de anlisis dinmico (D)
Localizan defectos que pasan a ser evidentes slo una vez que el software est
ejecutndose (tales como las dependencias de tiempo o las prdidas de
memoria).
Normalmente se utilizan en las pruebas de componente e integracin de
componentes y en las pruebas de middleware.
Herramientas de pruebas de rendimiento/pruebas carga/pruebas de estrs.
Monitorizan y reportan sobre el comportamiento de un sistema en una serie de
condiciones de uso simuladas en trminos de usuarios simultneos, modelo de
lanzamiento (ramp-up), frecuencia y porcentaje asociado de transacciones.
La simulacin de carga se logra creando usuarios virtuales que llevan a cabo una
serie seleccionada de transacciones, esparcidos en distintas mquinas de prueba
conocidos comnmente como generadores de carga.
Herramientas de monitorizacin.
Analizan, comprueban y reportan continuamente el uso de recursos especficos
del sistema y lanzan avisos sobre posibles problemas de servicio.
6.1.8 Herramientas de soporte para necesidades de pruebas especficas (K1)

Evaluacin de la calidad de los datos.
Los datos son la pieza clave de muchos proyectos, como los proyectos de
conversin/migracin, y las aplicaciones (tales como los data warehouses) y sus
atributos pueden variar en cuanto a criticidad y volumen.
En estos contextos, las herramientas deben emplearse para evaluar la calidad
con vistas a revisar y comprobar las reglas de conversin y migracin de datos
para garantizar que los datos procesados son correctos, completos y se ajustan a
una norma predefinida especfica del contexto.
Otras herramientas, como las utilizadas para pruebas de usabilidad, etc.
63
6.2 Uso efectivo de las herramientas: Ventajas
potenciales y riesgos (K2)
Pruebas guiadas por

Tcnica de creacin de scripts que almacena la entrada de la prueba y los resultados
datos esperados en una tabla o una hoja de clculo, de tal manera que un solo script pueda
ejecutar todas las pruebas de la tabla. Las pruebas guiadas por datos a menudo se
utilizan para dar soporte en el uso de herramientas de ejecucin de pruebas, tales
como herramientas de captura/reproduccin..
Pruebas guiadas por

Tcnica de creacin de scripts que utiliza archivos de datos para contener no
palabra clave solamente datos de prueba y resultados esperados, sino tambin palabras claves que
estn relacionadas con la aplicacin que esta siendo probada. Las palabras claves
son interpretadas por scripts especiales de soporte que son invocados por el script de
control para la prueba.
Lenguaje de creacin
Lenguaje de programacin en el cual se escriben scripts de prueba ejecutables para
de scripts ser utilizados por una herramienta de ejecucin de pruebas (por ejemplo una
herramienta de captura/reproduccin).
6.2.1 Ventajas potenciales y riesgos de las herramientas de soporte de pruebas

(para todas las herramientas) (K2)
Ventajas potenciales
Reduccin del trabajo repetitivo (por ejemplo, en la ejecucin de pruebas de
regresin, la reintroduccin de los mismos datos de prueba y la comprobacin contra
estndares de codificacin).
Mayor consistencia y repetibilidad (por ejemplo, las pruebas ejecutadas por una
herramienta en el mismo orden y con la misma frecuencia, y pruebas derivadas de
los requisitos).
Evaluacin de los objetivos (por ejemplo, medidas estticas, cobertura).
Facilidad de acceso a la informacin sobre las pruebas (por ejemplo, estadsticas y
grficos sobre el avance de las pruebas, la frecuencia de incidencias y el
rendimiento).
Riesgos
Expectativas poco realistas de la herramienta (incluyendo funcionalidad y facilidad de
uso).
Subestimacin de la cantidad de tiempo, coste y esfuerzo necesario para la
introduccin inicial de una herramienta (incluyendo formacin y experiencia externa).
Subestimacin del tiempo y el esfuerzo necesarios para conseguir ventajas
significativas y constantes de la herramienta (incluyendo la necesidad de cambios en
el proceso de pruebas y la mejora continua de la forma en la que se utiliza la
herramienta).
Subestimacin del esfuerzo necesario para mantener los activos de prueba
generados por la herramienta.
Exceso de confianza en la herramienta (sustitucin para diseo de pruebas o uso de
pruebas automatizadas cuando sera mejor llevar a cabo pruebas manuales).
No consideracin del control de versin de los activos de prueba en la herramienta.
No consideracin de problemas de relaciones e interoperabilidad entre herramientas
crticas, tales como las herramientas de gestin de requisitos, herramientas de
64
control de versiones, herramientas de gestin de incidencias, herramientas de
seguimiento de defectos y herramientas procedentes de varios fabricantes.
Riesgo de que el fabricante de la herramienta cierre, retire la herramienta o venda la
herramienta a otro proveedor.
Mala respuesta del fabricante para soporte, actualizaciones y correccin de defectos.
Riesgo de suspensin del proyecto de cdigo abierto.
Imprevistos, tales como la incapacidad de soportar una nueva plataforma.
6.2.2 Consideraciones especiales para algunos tipos de herramientas (K1)
Herramientas de ejecucin de pruebas
Las herramientas de ejecucin de pruebas ejecutan objetos de prueba sirvindose de guiones

de prueba automatizados.
Este tipo de herramienta a menudo requiere un esfuerzo importante para lograr ventajas
significativas.
Este enfoque no es escalable a grandes cantidades de guiones de prueba
automatizados.
Un guin capturado es una representacin lineal que incluye datos y acciones
especficos como parte de cada guin. Este tipo de guin puede resultar inestable si
se producen eventos imprevistos.
Un enfoque de pruebas guiadas por datos separa las entradas de las pruebas (los
datos), normalmente en una hoja de datos, y se sirve de un script de prueba ms genrico
que pueda leer los datos de entrada y ejecutar el mismo script de prueba con distintos datos.
Los probadores que no estn familiarizados con el lenguaje de creacin de scripts de
este modo pueden crear los datos de prueba para estos scripts predefinidos.
Asimismo, en las tcnicas guiadas por datos se utilizan otras tcnicas en las que, en lugar de
colocar en una hoja de datos combinaciones de datos codificadas, los datos se generan
utilizando algoritmos en base a parmetros configurables en el momento de la ejecucin y
facilitados a la aplicacin.
As, por ejemplo, una herramienta puede utilizar un algoritmo que genere una
identificacin de usuario aleatoria, y a efectos de repetibilidad del modelo, se utiliza
una semilla para controlar la aleatoriedad.
En un enfoque de pruebas guiado por palabras clave, la hoja de datos contiene las
palabras clave que describen las acciones a adoptar (tambin conocidas como palabras de
accin) y datos de prueba.
Los probadores (a pesar de no estar familiarizados con el lenguaje de creacin de
scripts) pueden entonces definir pruebas utilizando las palabras clave, las cuales
pueden ajustarse a la aplicacin en pruebas.
Para todos los enfoques es necesario contar con experiencia tcnica en el mbito del
lenguaje de creacin de scripts (tanto por parte de los probadores como por parte de los
especialistas en la automatizacin de pruebas).
Independientemente de la tcnica de scripting utilizada, los resultados esperados para cada
prueba deben almacenarse para su posterior comparacin.
Herramientas de anlisis esttico

Las herramientas de anlisis esttico aplicadas al cdigo fuente pueden aplicar estndares de
codificacin, pero si se aplican a un cdigo existente, pueden generar una gran cantidad de
mensajes.
65
Los mensajes de advertencia no impiden que el cdigo se traduzca en un programa
ejecutable, pero idealmente deberan tratarse de manera que faciliten el mantenimiento del
cdigo en el futuro.
La implementacin gradual de la herramienta de anlisis con filtros iniciales para excluir
ciertos mensajes constituye un enfoque efectivo.
Herramientas de gestin de pruebas

Las herramientas de gestin de pruebas tienen que interactuar con otras herramientas u
hojas de datos para producir informacin til en un formato que se ajuste a las necesidades
de la organizacin.
6.3 Introduccin de una herramienta en una organizacin

(K1)
Ningn trmino especfico.
Consideraciones a tener en cuenta a la hora de seleccionar una herramienta para una

organizacin:
Anlisis de la madurez organizativa, fortalezas y debilidades e identificacin de las
oportunidades para un proceso de pruebas mejorado soportado por herramientas.
Evaluacin frente a requisitos claros y criterios objetivos.
Una prueba de concepto, utilizando una herramienta de prueba durante la fase de
evaluacin para establecer si rinde de manera eficiente con el software objeto de la
prueba y dentro de la actual infraestructura o para identificar los cambios necesarios
en dicha infraestructura para utilizar la herramienta de manera efectiva.
Evaluacin del fabricante (incluyendo formacin, soporte y aspectos comerciales) o
soporte de servicio a proveedores en caso de herramientas no comerciales.
Identificacin de requisitos internos para impartir coaching y formacin sobre el
uso de la herramienta.
Evaluacin de las necesidades de formacin habida cuenta de las habilidades de
automatizacin de pruebas del equipo de pruebas.
Clculo de un ratio coste-beneficio en base a un caso de negocio concreto.
Para introducir la herramienta seleccionada en una organizacin debe lanzarse un proyecto
piloto, cuyos objetivos son los siguientes:
Aprender ms detalles sobre la herramienta.
Evaluar la forma en la que la herramienta se ajusta a los procesos y prcticas
existentes, y determinar qu debe cambiar.
Decidir las formas estndar en las que se debe utilizar, gestionar, almacenar y
mantener la herramienta y los activos de prueba (por ejemplo, decidir sobre la
designacin de archivos y pruebas, la creacin de bibliotecas y definir la modularidad
de los juegos de pruebas).
Valorar si se lograrn los beneficios a un coste razonable.
Los factores de xito para el despliegue de la herramienta dentro de una organizacin
incluyen:
Hacer extensiva la herramienta al resto de la organizacin de una manera
incremental.
Adaptar y mejorar los procesos para adaptarlos al uso de la herramienta.
Impartir formacin y coaching/tutoras a los nuevos usuarios.
Definir las directrices de uso.
66
Aplicar una forma de recopilar informacin sobre el uso de la herramienta a partir de
su uso real.
Hacer un seguimiento del uso y de los beneficios de la herramienta.
Proporcionar soporte al equipo de pruebas para una herramienta dada.
Recopilar las lecciones aprendidas de todos los equipos.
67
ANEXO IEEE 829 NORMA PARA LA DOCUMENTACIN
DE PRUEBAS SOFTWARE
Secciones plantilla de especificacin de diseo de pruebas
Identificador de la especificacin del diseo de pruebas.

Caractersticas que deben ser probadas (mediante este juego de pruebas).
Criterios de paso/falla de las caractersticas (p.ej, orculo de pruebas, base
de pruebas, sistemas heredados, etc.).
Refinamientos del mtodo (tcnicas especficas, herramientas, etc.).
Identificacin de las pruebas (trazabilidad de los casos de prueba en el juego
de pruebas).
Secciones plantilla de especificacin de caso de prueba
Identificador de la especificacin del caso de prueba.

tems/Elementos de pruebas (lo que tiene que ser entregado y probado).
Especificaciones de las entradas (entradas del usuario, archivos, etc.).
Especificaciones de las salidas (resultados esperados, incluyendo pantallas ,
archivos, tiempo, etc.).
Necesidades del entorno (hardware, software, personas, accesorios, ).
Requisitos especiales de procedimiento (intervencin del operador, permisos,
).
Dependencias entre casos (si es necesario para establecer condiciones
previas).
Secciones plantilla de especificacin de procedimiento de prueba
Identificador de la especificacin del procedimiento de prueba.

Propsito.
Requisitos especiales (habilidades, permisos, entorno, etc.).
Pasos del procedimiento.
Secciones del plan de pruebas
1. Identificador del plan de pruebas.

2. Introduccin.
3. tems (elementos de prueba).
4. Caractersticas a probar / que no deben ser probadas.
5. Mtodo/Enfoque de prueba (implementacin de la estrategia de prueba para el
proyecto).
6. Criterios paso/falla del tem.
7. Criterios de entrada, salida, suspensin, reanudacin.
8. Entregables de las pruebas.
68
9. Tareas/Hitos clave de las pruebas.
10. Cronograma.
11. Necesidades del entorno.
12. Responsabilidades.
13. Dotacin de personal y necesidades de capacitacin.
14. Riesgos (de calidad de producto y de proyecto).
15. Aprobaciones.
Secciones informe de resumen de pruebas

2. Resumen (lo que fue probado, ...).
3. Varianzas/Desviaciones (del plan, de los casos...).
4. Evaluacin comprensiva.
5. Resumen de resultados (mtricas finales, cmputos,...).
6. Evaluacin (de cada tem de prueba con relacin a los criterios de
paso/falla).
7. Resumen de las actividades (utilizacin de los recursos, eficiencia, ...).
8. Aprobacin.
Secciones registro de pruebas
1. Identificador del registro de pruebas.

2. La descripcin de las pruebas (tems sometidos a prueba versionados, entornos
de prueba utilizados, ).
3. Datos de actividades y eventos (descritos prueba tras prueba y evento tras
evento).

versiones)
describe los tems que deben ser entregados para las pruebas.
Secciones del informe de transmisin de los tems de pruebas segn IEEE 829:
2. Los tems transmitidos (incluyendo nombres de los tems y nmeros de revisin).
3. El lugar (ubicacin) del objeto o tem de pruebas.
4. El estado del objeto o tem de pruebas (incluyendo los defectos corregidos y
cambios introducidos).
5. Quin aprob ese objeto o tem para la versin que debe ser probada.
Informe de incidencias
a) Fecha de expedicin (creacin), organizacin emisora y autor

(creador/informante).
b) Resultados esperados y resultados reales.
69
c) Identificacin del elemento de prueba (elemento de configuracin) y entorno.
d) Proceso del ciclo de vida del software o del sistema en el que se ha observado la
incidencia.
e) Descripcin de la incidencia para permitir su reproduccin y resolucin,
incluyendo registros, volcados de bases de datos o pantallazos.
f) Alcance o grado de impacto en los intereses de las partes interesadas.
g) Gravedad del impacto en el sistema.
h) Urgencia/prioridad de su correccin.
i) Estado de la incidencia (por ejemplo, abierta, diferida, duplicada, esperando
correccin, corregida esperando la repeticin de las pruebas, cerrada).
j) Conclusiones, recomendaciones y autorizaciones.
k) Aspectos globales, como otras reas que pueden verse afectadas por un cambio
derivado de la incidencia.
l) Historial del cambio, como la secuencia de acciones adoptadas por los miembros
del equipo de proyecto por lo que respecta a la incidencia para aislarla, repararla y
confirmarla como corregida.
m) Referencias, incluyendo la identidad de la especificacin de caso de prueba que
puso de manifiesto el problema.
Secciones de un informe de incidencias segn IEEE 829:

2. Resumen (describe especialmente el impacto acerca de los interesados de negocio).
3. Descripcin de la incidencia.
Entradas (posibles anomalas observadas en las mismas).
Resultados esperados vs Resultados reales.
Fecha/Hora cuando se observaron las anomalas.
Entorno de pruebas en el cul las anomalas fueron observadas.
Identificador del caso de prueba o procedimiento que detect la anomala.
La reproducibilidad del fallo.
El informador de la incidencia.

70

Apuntes ISTQB Foundation Formandobits

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Apuntes ISTQB Foundation Formandobits

Hochgeladen von

Copyright:

Verfügbare Formate

APUNTES ISTQB CTFL

(Certified Tester Foundation

v. 2014-09 Adaptacin realizada por Formandobits.com

5.2 Planificacin y estimacin de pruebas (k3)...........................................................48

1.1 Por qu es necesario el proceso de pruebas?

1.1.1 Contexto de los sistemas software (K1)

Software que no funciona correctamente Prdida de dinero, tiempo, renombre

1.1.2 Causas de los defectos de software (K2)

Persona --- puede cometer un error/equivocacin --- puede producir un

1.1.3 Funcin del proceso de pruebas en el desarrollo, mantenimiento y

1.1.4 Proceso de pruebas y calidad (K2)

1.1.5 Con cuntas pruebas es suficiente? (K2)

1.2 En qu consiste el proceso de pruebas? (K2)

1.3 Siete principios para las pruebas (K2)

1. Las pruebas demuestran la presencia de defectos.

1.4 Proceso bsico de pruebas (K1)

Actividades principales (pueden solaparse):

1.4.1 Planificacin y control de pruebas (K1)

Planificacin de pruebas: Actividad de definir los objetivos de las pruebas y la

1.4.2 Anlisis y diseo de pruebas (K1)

1.4.4 Evaluacin de los criterios de salida e informes (K1)

1.4.5 Actividades de cierre de pruebas (K1)

Principio de segregacin de tareas / Independencia de las pruebas: quien prueba o

1.6 Cdigo deontolgico (K2)

PBLICO: Los probadores de software certificados actuarn en coherencia con el

2.1 Modelos de desarrollo de software (K2)

Verificacin Verificacin: Confirmacin por examen y a travs de la

Buscar defectos en el sistema, basndose en los

Validacin Validacin: Confirmacin por examen y a travs de la

Buscar defectos en el sistema, basndose en los

Se basa en cuatro niveles de pruebas correspondientes a los cuatro niveles de

2.1.2 Modelo de desarrollo iterativo-incremental (K2)

Desarrollo iterativo-incremental: proceso de establecer requisitos, disear,

2.1.3 Pruebas en un Modelo de Ciclo de Vida (K2)

2.2 Niveles de prueba (K2)

Grado en el cual un componente o sistema puede funcionar correctamente en

Capacidad de un sistema o componente para continuar su operacin normal a pesar de

Capacidad del producto software para mantener un nivel especificado de rendimiento

Desarrollo guiado por

Caractersticas de un nivel de pruebas:

2.2.1 Pruebas de componente/unitarias (K2)

Objetivos generales: Localizar defectos y comprobar el funcionamiento de mdulos

2.2.2 Pruebas de integracin (K2)

Objetivos generales: Se ocupan de probar las interfaces entre los componentes,

Objetivos generales: Probar el comportamiento global de un sistema/producto a

o Pruebas basadas en:

2.2.4 Pruebas de aceptacin (K2)

Objetivos generales: Crear confianza en el sistema, partes del sistema o

Enfoques especficos y responsabilidades:

Vase tambin pruebas de funcionalidad.

Facilidad con la que un producto software puede ser transferido de un entorno

Habilidad de un producto software para llevar a cabo aquellas funciones requeridas

Atributos de productos software que se refieren a su capacidad para prevenir

Capacidad del software para ser comprendido, aprendido, utilizado y atractivo al

Pruebas de caja blanca /

Un tipo de prueba se centra en un objetivo de prueba:

2.3.1 Pruebas de funciones (Pruebas funcionales) (K2)

Funciones = Lo que hace el sistema.

2.3.2 Pruebas de caractersticas no funcionales del software (Pruebas no

Incluyen (entre otras):

2.3.3 Pruebas de estructura/arquitectura de software (Pruebas estructurales) (K2)

2.3.4 Pruebas asociadas a cambios: Repeticin de pruebas y pruebas de regresin

Pruebas de confirmacin: Una vez detectado y corregido un defecto, el software debe