Capítulo No.5 Istqb Gestión de Pruebas

Probador Certificado – Nivel Básico
V. Gestión de pruebas
Contenido
Capítulo V – Gestión de pruebas

- V/01 Organización de prueba
- V/02 Planificación y estimación del proceso de prueba
- V/03 Seguimiento y control del estado de las pruebas
- V/04 Gestión de la configuración
- V/05 Riesgo y proceso de prueba
- V/06 Gestión de incidencias
01. Organización de prueba
La gestión de pruebas como parte del proceso de prueba

- La gestión de pruebas es la gestión de proyecto de los proyectos de prueba
- El proceso de prueba es una actividad que cubre por completo el proceso de desarrollo
software
- Las actividades propias de la gestión de pruebas son necesarias a lo largo de todo el
proceso de prueba
Actividad Producto resultado del trabajo

Concepción de pruebas Plan de pruebas (estático)
Planificación de pruebas Plan de pruebas (dinámico)
Control de pruebas Informe de estado, acción de control
Pruebas de aceptación Entrega (“release”) del producto software

Los equipos de prueba deberían ser independientes

- Ventajas
- Imparcialidad, no hay vinculación personal con el objeto de prueba.
- Se pueden cuestionar hechos respecto de la base de prueba (“test basis”) y verificar las
suposiciones hechas durante al diseño de las pruebas
- Desventajas
- Aumenta el esfuerzo dedicado a la comunicación, presentación de conflictos del tipo “tener la
última palabra” en…
- Los desarrolladores pierden el sentido de la responsabilidad
Otras formas de conformar equipos de prueba

- Los probadores prueban sus propios programas
- Los probadores también son miembros del equipo de desarrollo
- Los probadores también son miembros del equipo del proyecto o estructura de la
organización
- Especialistas para tareas específicas
- Equipos de prueba externos
El orden de enumeración refleja el grado de independencia

Perfiles del personal de pruebas

- El proceso de prueba requiere personas con una amplia variedad de competencias y
cualificaciones
- Se explicarán en detalle los siguientes roles asociados al proceso de prueba:
- Jefe de prueba o director de prueba (“test manager”)
- Diseñador de prueba (“test designer”)
- Ingeniero de automatización de pruebas (“test automation engineer”)
- Administrador de prueba (“test administrator”) / Administrador del sistema de prueba (“test
system administrator”)
- Probador (“tester”)
- Experto técnico (“technical expert”)
Nota:
- Se pueden especificar roles adicionales, por ejemplo administrador de base de datos,
probador de carga
Jefe de prueba (“test leader”) {también gestor de prueba (“test manager”) o

coordinador de prueba (“test coordinator”)}
- Planifica, realiza el seguimiento y control del proyecto de prueba
- Competencias especiales necesarias:
- Gestión de pruebas y calidad software
- Planificación y control de pruebas
- Experiencia como jefe de proyecto
- Habilidades de gestor
Diseñador de prueba (“test designer”)

- Diseña los casos de prueba necesarios y establece el orden en el cual tendrá lugar la
ejecución de los casos de prueba
- Competencias especiales necesarias en el área de:
- Conocimiento de desarrollo y pruebas
- Conocimiento de ingeniería de software
- Conocimiento respecto de especificaciones técnicas (métodos)
- Conocimiento de requisitos funcionales
Ingeniero de automatización de prueba (“test automation engineer”)

- Evalúa las posibilidades de la automatización de las pruebas y las implementa
- Experiencia como probador (“tester”)
- Conocimiento técnico (“know-how ”) en el ámbito de diseño y automatización de pruebas
- Conocimientos de programación
- Amplios conocimientos en el uso de las herramientas utilizadas
Administrador del sistema de prueba (“test system administrator”)

- Prepara y opera el entorno de pruebas
- Es responsable de cumplir los requisitos del sistema de prueba
- Administración de sistemas (o acceso al administrador del sistema)
- Conocimiento de herramientas de desarrollo y pruebas
- Sistemas de base de datos, si aplica
- Redes, si aplica
- Instalación y operación de software del sistema (por ejemplo sistemas operativos)
Probador software (“software tester”)

- Ejecuta las pruebas de acuerdo con la especificación de casos de prueba
- Conocimiento básico del software
- Conocimiento básico de pruebas
- Operación y uso de herramientas de prueba
- Experiencia en la ejecución de pruebas
- Conocimiento respecto de los objetos de prueba
Experto técnico (“technical expert”)

- Asiste al equipo de prueba cuando es necesario
- Administración de bases de datos o diseño de bases de datos
- Experto en interfaces de usuario
- Experto en redes
- Dependiendo del tipo de problema o del entorno de prueba puede ser necesario que
expertos adicionales en pruebas formen parte del equipo de prueba
- En algunas ocasiones son necesarias competencias especiales que no se encuentren
directamente relacionadas con las pruebas, por ejemplo expertos en usabilidad, expertos en
seguridad, etc.
Competencias no técnicas (“soft skills”)

- Con carácter complementario a las competencias técnicas, los miembros del equipo de
prueba requieren de la siguientes competencias y experiencia:
- Miembros del equipo: instinto (político y) diplomático
- Disposición a preguntar sobre hechos aparentemente obvios
- Persistencia, fuerte personalidad
- Meticulosidad y creatividad
- Capacidad para tratar situaciones complejas
- Capacidad de aprender rápidamente
Organización de equipos de pruebas

- Utilizar una organización adecuada a cada proyecto específico
Dirección equipos Qué
de pruebas
Quien
Jefe de prueba
Especificación de
Planificación Ejecución Evaluación y control
casos de prueba
Actividades de Diseño de casos Evaluación de

Ejecución de pruebas
Infraestructura de pruebas de prueba pruebas
Equipo de Equipo de
Equipo de prueba Equipo de prueba
pruebas funcionales pruebas funcionales
- No es necesario que cada rol sea asumido por personas distintas. En grupos pequeños
una persona puede asumir múltiples roles
Tareas del líder de prueba – Sumario

- Organización del equipo de prueba
- Planificación de pruebas (de acuerdo con el plan de calidad corporativo)
- Planificación de los ciclos de prueba
- Estrategia de prueba, incluida la decisión de automatización de las pruebas
- Medición y control de las pruebas
- Introducción de un sistema de gestión de incidencias adecuado
- Introducción de un sistema de gestión de la configuración*
- Generación de informes de resultado y progreso para la dirección de la
organización/compañía
* Esta no es una tarea propia del jefe de pruebas, la gestión de la configuración es necesaria en todas las fases del
desarrollo de un producto
Tareas del líder de pruebas: Gestión de pruebas

- Redacción del plan de pruebas
- Genera un documento que soporta métodos, recursos y plazos/calendario para las actividades
del proceso de prueba
Tareas del líder de prueba: planificación de prueba (“test planning”)/Planificación

del ciclo de prueba (“test cycle planning”)
- Enfoque de pruebas: implementación de Planificación de prueba
una estrategia de prueba para un

proyecto específico Análisis de pruebas
y Diseño de pruebas
Control de pruebas
- Ciclo de prueba: ciclo a través del proceso
de prueba para un objeto de prueba Implementación de pruebas
y Ejecución de pruebas
específico
Evaluación del criterio de salida
- Actividades del proceso de y Generación de informes
prueba (recordatorio):
Actividades de cierre
- Planificación y control de pruebas de pruebas
(“test planning and control”)

- Especificación de prueba (“test specification”)
- Ejecución de pruebas (“test execution”)
- Evaluación y generación de informes de prueba (“test evaluation and reporting”)
- Cierre de prueba (“test closure”)
Tareas del líder de pruebas: planificación de pruebas (“test

planning”)/Planificación del ciclo de pruebas (“test cycle planning”)
- Planificación de pruebas Planificación de pruebas
- Planificación del proceso de prueba:

debe ser desarrollada en una fase temprana Análisis de pruebas
del proyecto. El resultado debe estar reflejado
Control de pruebas
en un documento Implementación de pruebas
(plan maestro de prueba – “master test plan”)
- Planificación del ciclo de prueba Evaluación del criterio de salida
y Generación de informes
- Planificación detallada de un ciclo de prueba:
El plan maestro de prueba (estático) será Actividades de cierre
de pruebas
detallado para describir un ciclo de prueba
específico. Los detalles dependen de la situación particular del proyecto
(por ejemplo progreso del desarrollo, resultados de las pruebas, disponibilidad
de recursos)
- Tareas del jefe de prueba: Iniciación, control y supervisión de pruebas y ciclos de pruebas

- La planificación de las pruebas comienza Planificación de pruebas
al inicio del proyecto

- Hitos, presupuesto y prioridades de las Análisis de pruebas
diversas actividades del proceso de prueba
Control de pruebas
requieren ser abordados, los riesgos deben Implementación de pruebas
ser comprendidos
- El desarrollo del proyecto debe ser tenido y Generación de informes
en cuenta
- A lo largo del proyecto pueden ocurrir retrasos de pruebas
y la planificación de las pruebas debe ser adaptada

- Selección de herramientas y decisión respecto de la automatización de pruebas
- Diferentes herramientas y grados de automatización para los distintos niveles de pruebas

Planificación de pruebas
- Los recursos deben ser planificados
- Éstos son escasos y, con frecuencia, deben Análisis de pruebas
ser asignados de forma individual y Diseño de pruebas
Control de pruebas
- Durante los ciclos de prueba, pueden Implementación de pruebas
ocurrir retrasos de tal forma que la y Ejecución de pruebas
planificación de los recursos de prueba

debe ser revisada y Generación de informes
- El desarrollo del proyecto debe ser tenido Actividades de cierre

en cuenta de pruebas
- A lo largo del proyecto pueden ocurrir retrasos de tal forma que puedan poner en peligro a la
planificación (plazos)
- En este caso, los casos de prueba planificados tienen que ser “filtrados” (“scraped”) con el objeto
de cumplir con los hitos. Esta es, con mucha frecuencia, la primera medida tomada cuando los
plazos se reducen
Tareas del líder de pruebas: planificación de prueba (“test

planning”)/Planificación del ciclo de prueba (“test cycle planning”)
- Se debe tener en cuenta la evaluación Planificación de pruebas
de pruebas anteriores
Análisis de pruebas
- Los resultados (de las pruebas en curso) y Diseño de pruebas
de las actividades de prueba pueden
Control de pruebas
influir en la planificación de otras Implementación de pruebas
actividades de prueba, por ejemplo,
dependiendo del número de errores Evaluación del criterio de salida
detectados en el primer ciclo de prueba,
el segundo ciclo de prueba puede variar Actividades de cierre
su extensión (más largo o más corto) de pruebas
- El control de las actividades de prueba en curso se realiza utilizando métricas

especificadas y acordadas en el plan de prueba
Tareas del líder de pruebas: especificación de pruebas (“test specification”)

- El objetivo principal del proceso de prueba
es detectar la mayor cantidad de defectos Planificación de pruebas
relevantes con el menor esfuerzo posible!
- Todas las pruebas documentadas en el plan Análisis de pruebas
de prueba son especificadas, es decir, se
Control de pruebas
establece cómo se estructura/presenta cada Implementación de pruebas
caso de prueba y cómo debe ser ejecutado.

Este proceso es iniciado por el jefe de prueba y Generación de informes
- Los casos de prueba están constituidos por Actividades de cierre

pasos unitarios de pruebas
- ¡Los casos de prueba deberían ser obtenidos con la colaboración de personal que cuente con
conocimiento de los requisitos funcionales del software!
- Los casos de prueba deberían ser diseñados teniendo en mente su carácter repetitivo
Tareas del líder de pruebas: ejecución y control (“test execution and test
control”) (1)
- Comparación de resultados esperados y Planificación de pruebas
obtenidos en el proyecto
- Cada ciclo de prueba requiere ser ajustado/ Análisis de pruebas
adaptado al plan de prueba
Control de pruebas
- ¿Han ocurrido retrasos o cambios? Implementación de pruebas
- ¿Los resultados obtenidos se encuentran dentro y Ejecución de pruebas
del rango esperado? – Número de defectos

detectados, tiempo utilizado en correcciones, y Generación de informes
repetición de pruebas, etc.

de pruebas
Tareas del líder de pruebas: ejecución y control

(“test execution and test control”) (2)
- Todas las desviaciones deben ser informadas
y tenidas en cuenta Planificación de pruebas
- Normalmente las medidas correctivas deben ser
tomadas de acuerdo con el plan de prueba y las Análisis de pruebas
actividades de prueba en curso, por ejemplo: y Diseño de pruebas
Control de pruebas
- Ajuste de fechas para las pruebas planificadas
Implementación de pruebas
- Ajuste de recursos para la ejecución de pruebas y Ejecución de pruebas
- Ejecutar ciclos de pruebas adicionales / omitir ciclos

de pruebas y Generación de informes
- Modificar la prioridad de ciclos de las pruebas

de pruebas
Tareas del líder de pruebas: evaluación (“evaluation”)

- La gestión de pruebas aporta transparencia
a la evolución del proceso de prueba y Plan de pruebas
proporciona indicadores a la dirección
del proyecto Análisis de pruebas
- Los informes generados durante la ejecución
Control de pruebas
de pruebas (por ejemplo informe de errores, Implementación de pruebas
sumario por clase de errores, estadísticas),

el seguimiento de errores e informes al cliente y Generación de informes
son una importante fuente de información

para el jefe de proyecto y la dirección de la de pruebas
compañía (por ejemplo como base para la

planificación de recursos y plazos)
- El uso de herramientas y plantillas aumentarán la calidad y pueden reducir la carga de
trabajo
Tareas del líder de pruebas: evaluación (“evaluation”)

- La gestión de pruebas incluye la aceptación
de resultados del proyecto, significa: Planificación de pruebas
el producto debe cumplir los requisitos y
la especificación definidos Análisis de pruebas
- El jefe de proyecto, de acuerdo con
Control de pruebas
el jefe de prueba, decide respecto Implementación de pruebas
de la aceptación de los objetos de

prueba (por ejemplo pasar a un siguiente y Generación de informes
nivel de prueba)
- Los informes resumen de pruebas de pruebas
("test summary report") aseguran la ejecución

completa de las actividades de prueba
Tareas del probador* (“tester”) – Sumario

- Asiste en la implementación de la planificación de las actividades de prueba
- Desarrolla los diseños de casos de prueba y ejecución de pruebas
- Revisa los casos de prueba diseñados por otros probadores
- Asiste en la generación de informes de prueba
- Asiste en la implementación de la automatización de pruebas
* Nota: El término probador de utiliza de forma genérica y puede incluir varios roles aparte del de jefe o líder de
proyecto
Tareas del probador (“tester”) (1)

- Asiste en la implementación de la planificación de las actividades de prueba
- Revisa y comprueba planes de prueba Planificación de pruebas
- Analiza y evalúa bases de prueba

(documentos, especificaciones) Análisis de pruebas
Control de pruebas
- Desarrolla especificaciones de pruebas
- Formula y selecciona casos de prueba y y Ejecución de pruebas
combinaciones de datos de prueba

- Formula resultados esperados
- Prepara, configura y administra el entorno de Actividades de cierre
de pruebas
prueba (conjuntamente con los administradores de la red y sistema)

- Ejecución de pruebas (pruebas manuales)
- Implementación de las pruebas a todos Planificación de pruebas
los niveles
- Ejecuta pruebas y registra resultados en Análisis de pruebas
un protocolo de prueba
Control de pruebas
- Evalúa los resultados de las pruebas y Ejecución de pruebas

de pruebas

- Asiste en la implementación de la automatización de pruebas*
- Creación de scripts (guiones) de prueba Planificación de pruebas
- Creación/operación de herramientas de prueba

en el área de automatización de pruebas Análisis de pruebas
- Ejecución de actividades de automatización de
Control de pruebas
pruebas, control de ejecuciones de Implementación de pruebas
captura-repetición (“capture-replay-runs”) y Ejecución de pruebas
- Análisis y evaluación de resultados Evaluación del criterio de salida

- Tratamiento después de pruebas
(“test post processing”) Actividades de cierre
de pruebas
- Creación de protocolo de pruebas
- Trazado de notas relativas a desviaciones
- Ejecución de la repetición de pruebas
- Preparación de documentación de aceptación
* Nota: Los probadores podrán ser asistidos por desarrolladores o por un experto en automatización de pruebas
Resumen (1)
- La efectividad en la detección de defectos se incrementa con la independencia del
equipo de prueba. La independencia se presenta en distintos grados
- El jefe de prueba establece el equipo de prueba en una fase temprana y:
- Planifica todas las pruebas
- Establece/crea un enfoque de prueba
- Organiza la gestión de desviaciones
- Organiza la gestión de la configuración de los productos de soporte de pruebas (“testware”)
- Controla la ejecución de pruebas
- Evalúa los resultados de las pruebas
Resumen (2)
- El jefe de prueba informa a la dirección de la compañía y al jefe de proyecto
- El probador apoya las actividades de preparación de pruebas, ejecuta pruebas, crea la
documentación relativa a mensajes de desviación y resultados de prueba. También
asiste en la implementación de la automatización de pruebas
Contenido

02. Planificación y estimación del proceso de prueba
Actividades de planificación de pruebas

- La planificación de pruebas es planificación de proyectos
- Todas las tareas y actividades deben ser Planificación de pruebas
planificadas con antelación
- Para las distintas tareas definidas se deben asignar Análisis de pruebas
recursos (personal, presupuesto, herramientas, y Diseño de pruebas
Control de pruebas
entornos de prueba, etc.) Implementación de pruebas
- Concretar las actividades de prueba en un plan maestro de prueba
y Ejecución de pruebas y
coordinarlas con el plan

de proyecto y Generación de informes
- Definir el nivel de calidad (por ejemplo

profundidad de las pruebas) para los distintos Actividades de cierre
de pruebas
niveles de prueba
- La planificación de pruebas es una actividad continua, debe ser controlada de forma constante
- La información proveniente de las actividades de prueba podrían imponer ajustes en el plan
maestro de prueba con el objeto de afrontar riesgos sujetos a cambios
La planificación de pruebas es parte de la planificación de la calidad en su

conjunto
- La planificación de pruebas es una parte importante del aseguramiento de la calidad,
pero no es la única parte
- Se puede encontrar la estructura y contenidos de un plan de calidad en el estándar IEEE
730 (con información adicional en el estándar IEEE 983)
- Elementos de un plan de aseguramiento de la calidad de acuerdo con el estándar IEEE
730: planificación y descripción de
- Organización del proyecto
- Documentos que cubren el ciclo de vida de desarrollo
- Estándares, métodos y convenciones de la misma manera que un mecanismo que asegure que
aquellos son seguidos (cumplidos)
- Revisiones y auditorias durante el ciclo de vida de desarrollo
- Proceso de prueba
- Documentación de errores, acciones correctivas
Plan maestro de prueba (estático) (“master test plan”)

- Tras definir el rol del proceso de prueba en el marco de las actividades de
aseguramiento de la calidad (QA), el proceso de prueba comienza con su fase de
planificación
- El primer paso de la planificación es la creación de un plan de prueba estático
- El plan maestro de prueba cubre todas las fases del proceso de prueba
- Las reglas se fijan de acuerdo los objetivos de las pruebas, recursos, actividades de pruebas,
hitos, etc.
- El plan maestro de prueba es, posteriormente, ampliado con el objeto de cubrir los
resultados a partir de la fase de planificación de detalle
- Dado que durante la planificación del proyecto se genera más información, la planificación se
puede hacer con mayor detalle
- El plan maestro de prueba cuenta con una extensión dinámica, que será ajustada durante el ciclo
de vida del proyecto, si eso fuera necesario
- El estándar IEEE 829 aporta una estructura de plan maestro de prueba acreditada
Plan de prueba de acuerdo al estándar IEEE 829

1. Introducción 9. Entregables de pruebas
2. Suposiciones 10. Tareas de pruebas
3. Elementos de prueba 11. Necesidades relativas al entorno

4. Características/prestaciones sujetas a
12. Responsabilidades
pruebas
5. Características/prestaciones no sujetas
13. Dotación de personal y formación
a pruebas
6. Enfoque 14. Calendario
7. Criterios de paso/fallo 15. Riesgos y contingencias
8. Criterios de suspensión/reanudación. 16. Aprobación

Actividades a realizar
- La planificación de pruebas comienza al inicio de un proyecto de desarrollo y se ajusta a
lo largo del ciclo de vida del proyecto
- La planificación de pruebas también cubre la creación y actualización del plan de
prueba. Las siguientes actividades se explican con mayor detalle:
- Estrategia de prueba (“test strategy”)
- Planificación de recursos (“resource planning”)
- Prioridad de las pruebas (“priority of tests”)
- Soporte de herramientas (“tool support”)
Actividades a realizar – estrategia de prueba (“test strategy”)

- La estrategia describe los niveles de prueba a desarrollar y la intensidad de las pruebas
en aquellos niveles
- La estrategia de prueba también establece los criterios de entrada y salida para cada
nivel, incluyendo las métricas para evaluar estos criterios
- Es necesaria una estrategia de prueba dado que no es viable probar un sistema de
forma completa. Probar con todas las combinaciones de datos de prueba, estados
internos y restricciones temporales es prácticamente imposible
- La evaluación de riesgo ayuda a centrar la atención en aquellas áreas en que las
actividades de prueba presentan un riesgo de fallo más alto
Actividades a realizar – Planificación de recursos (“resource planning”)

- El objetivo principal de la planificación de recursos es estimar el esfuerzo de los
miembros del equipo, incluyendo sus necesidades en términos de tiempo,
herramientas, actividades de apoyo, etc. Estas estimaciones se convierten en parte del
plan de prueba (dinámico)
- Este plan maestro de prueba cuenta con un calendario (“time table”)detallado,
incluyendo hitos, asignación de personal a actividades. Este plan es un instrumento para
gestionar la tarea global de la ejecución de pruebas con todas sus actividades
Actividades a realizar – planificación de pruebas (“test planning”)

- Gestionar el tiempo: Muchos proyectos experimentan intensos problemas de tiempo
en torno a las fases finales. Esto puede conducir a decisiones sobre la reducción de
actividades de prueba o la omisión de pruebas de forma completa
- Priorizar pruebas: Dado que la distribución de software sin haber sido probado
suficientemente conlleva un alto riesgo, es necesario asignar prioridades a las
actividades de prueba. Esto debe ser realizado de tal forma que los casos de prueba más
importantes sean ejecutados de forma temprana. De esta forma, las partes críticas de
los programas son probadas, incluso en el caso en el que actividades de prueba sean
abortadas de forma prematura
- Selección de herramientas: Decidir respecto de qué herramientas deben ser utilizadas
para probar, si las herramientas disponibles son suficientes o si hay necesidad de
herramientas adicionales
- Documentar: Definir el nivel de detalle, estructura y plantillas para la documentación de
pruebas
Criterios de entrada
- Los criterios de entrada (“entry criteria”) definen cuando comenzar a probar, como al
inicio de un nivel de prueba o cuando un conjunto de prueba está listo para su ejecución
- Pueden ser criterios de entrada frecuentes:

- Entorno de prueba disponible y grado de preparación
- Estado de preparación de herramientas de prueba en el entorno de prueba
- Disponibilidad de código (testable)
- Disponibilidad de datos de prueba
- Disponibilidad de recursos humanos
- Probadores preparados y en disposición
Criterios de salida de prueba (“test exit criteria”) (1)

- Los criterios de salida, que indican la finalización de una fase de prueba, deben ser
establecidos para cada nivel de prueba. Son necesarias métricas para controlar estos
criterios de salida. Ejemplos:
- Cobertura de código (“code coverage”).
- x% de código (de un programa) que ha sido ejecutado
- x% de todas las funciones/todas las opciones de menú que han sido cubiertas
- Cobertura de riesgo (“risk coverage”).
- Casos de prueba de una clase de riesgo predefinido (por ejemplo el nivel de riesgo más alto) han
sido ejecutados con éxito en su totalidad
Criterios de salida de prueba (“test exit criteria”) (2)

Aborto de pruebas debido a razones de tiempo, costos o calidad.
- Las actividades de prueba son paralizadas/suspendidas cuando se alcanza la fecha de entrega o el
presupuesto se agota. Es muy frecuente que ésta sea la realidad en proyectos, sin embargo, en
muchas ocasiones, posteriormente se constata que esta circunstancia tiene un alto coste en tiempo
y dinero
- Si no ha sido alcanzado un mínimo de calidad, las pruebas pueden ser suspendidas o incluso no ser
iniciadas (muchos defectos críticos)
Tasa de detección de errores (“error finding rate”)
- El número de nuevos errores detectados cae por debajo de un valor predeterminado, por ejemplo
las pruebas han sido suspendidas si se han detectado menos de un error por hora
- Las economías del proceso de prueba deben ser tenidas en cuenta. Más allá de una cierta tasa de
detección de errores puede resultar una mejor opción entregar/distribuir la aplicación software al
entorno de producción y concentrarse solamente en la corrección de fallos informados por el
cliente
Criterios de salida de pruebas (“test exit criteria”)

-Economía del proceso de prueba.
- Un grado creciente de la calidad representa un
coste más bajo del error, pero costes más altos
Coste
en prevención de errores mínimo
- Inicialmente, el coste de la revisión se incrementa, de la
calidad
a continuación se reduce (se hacen menos
revisiones en fases finales del proyecto)
- Inicialmente, el coste total de la calidad se
Costes
reduce, a continuación se incrementa –
los costes de la calidad son los más bajos
donde la curva presenta su mínimo
- Frecuentemente es necesario aportar un mínimo
de calidad con el objeto de poder mantenerse
en el negocio, esto significa: Grado de calidad
- Las pruebas deben continuar a pesar de que el Fuente: Datos cualitativos de unos 20
Proyectos de Díaz & Hilterscheid
aumento del coste de la prevención de errores se
incrementa más que el decremento de costo del error
Enfoques de prueba ("test approach")/

estrategia de prueba (“test strategy”) (1)
El enfoque de prueba es la implementación de la estrategia de prueba para un proyecto
específico. El enfoque de prueba es definido y redefinido en los planes de prueba y
diseños de prueba. Normalmente incluye las decisiones tomadas en función de los
objetivos del proyecto y gestión de riesgo.
Hay una variedad de diferentes enfoques de prueba
Los enfoques/estrategias se pueden combinar
- Enfoque preventivo (“preventive approach”)

- Las pruebas son diseñadas tan pronto como sea posible
- Enfoque reactivo (“reactive approach”)
- Primero el software/sistema, luego el diseño de pruebas

estrategia de prueba (“test strategy”) (2)
- Enfoque analítico (“analytical approach”)
- Se realiza un análisis previo a las pruebas, por ejemplo, pruebas basadas en riesgos (“risk-based
testing”)
- Enfoque heurístico (“heuristic approach”)
- Las pruebas son más reactivas, por ejemplo pruebas exploratorias

estrategias de prueba (“test strategy”) (3)
Otros enfoques/estrategias:
- Enfoque de reutilización (“reuse approach”): uso de juegos de prueba y pruebas de
proyectos previos con el objeto de lograr un avance rápido
- Enfoque centrado en fallo (“failure focused approach”): predicción de errores (“error
guessing”), ataques de faltas (“fault attacks”)
- Enfoque basado en listas de comprobación (“check list based approach”): uso de listas
de comprobación de proyectos previos o de la planificación de pruebas
- Enfoque basada en consultoría (“consultative based approach”): expertos y tecnología
externos guían al proceso de prueba

estrategias de prueba (“test strategy”) (4)
Otros enfoques/estrategias:
- Enfoque conforme a proceso o estándar (“process-or standard-compliant approach”):
estrategia regida por estándares de desarrollo software, por ejemplo métodos ágiles,
estándares industriales
- Enfoque basado en modelo (“model based approach”): pruebas estocásticas basadas
en información estadística de tasas de fallos, etc.
Se pueden definir más enfoques. En la práctica se combinan varios enfoques
Estimación de pruebas – factores (síntesis)

- Características del producto (por ejemplo complejidad)
- Calidad de la base de las pruebas
- Requisitos de fiabilidad y seguridad (efectos adversos) (“safety) del producto
- Complejidad del proceso de desarrollo
- Estabilidad de la organización, madurez del proceso utilizado
- Personal involucrado, restricciones temporales
- Métodos para estimar el esfuerzo en el proceso de prueba
- Estimación experta (también enfoque basada en tareas)
- Estimación basada en analogías
- Estimación basada en porcentajes
Estimación experta (1)

- Método
- Identificar todas las tareas a ejecutar (normalmente utilizando un enfoque descendente (“top
down”))
- Obtener estimaciones para cada tarea de los responsables (de su ejecución) o por expertos
- Sumar todos los valores de las tareas. Incluir los factores de corrección (si hay experiencias
respecto de la exactitud de ciertos estimadores)
- Incluir elementos amortiguadores (buffers)/elementos adicionales con el objeto de cubrir
tareas omitidas o subestimadas

- Ventajas
- Las actividades de estimación pueden estar estrechamente vinculadas a la planificación del
proyecto
- La estimación da origen a una información detallada que puede ser controlada y ajustada a lo
largo del ciclo de vida del proyecto
- Las tareas pueden ser asignadas a grupos (por ejemplo pequeño, mediano, grande) y los
esfuerzos sólo son estimados para unos pocos representantes del grupo

- Desventajas
- Este método es extensivo y caro
- Este método requiere un idea clara respecto de la estrategia de prueba y actividades de prueba
en una fase temprana del proyecto
- La experiencia demuestra que las estimaciones son, en la mayoría de los casos, a la baja. Esto
podría deberse a la omisión o subestimación grosera de ciertas tareas
- Los elementos amortiguadores incorporados son recortados durante la planificación del
proyecto
- Los errores relativos a la planificación de proyecto son heredados
Estimación basada en analogías (1)

- Método
- Clasificar las tareas de prueba requeridas
- Buscar un proyecto que se haya desarrollado en el pasado que contenga una tarea similar a una
específica
- Utilizar el esfuerzo real de esta tarea como base para la estimación
- A través del uso de métricas (líneas de código, número de módulos, número de casos de prueba,
etc.) como base, calcular el valor de la estimación total
- Considerar factores de corrección
Estimación basada en analogías (2)

- Ventajas
- El método es simple y efectivo
- Se pueden lograr valores muy precisos para la estimación si se cuenta con suficiente experiencia
- Desventajas
- Se requiere personal con experiencia (estimadores) y/o base de datos detallada respecto del
proyecto actual para las tareas a estimar
- Los criterios para la clasificación de proyectos pueden no cubrir todos los aspectos de un
proyecto
- Frecuentemente conduce a debates con la dirección respecto de la validez de la estimación
Estimación basada en porcentajes (1)

- Método
- El esfuerzo para las actividades de prueba se estiman sobre la base de la totalidad de las
actividades del proyecto
- El valor del porcentaje (fracción) requiere ser determinado basándose en la experiencia
- Ejemplo: Spillner/Linz habla de un porcentaje del 50% de actividades de pruebas respecto de la
totalidad de las actividades del proyecto (véase también “Basiswissen Softwaretest“,
dpunkt.Verlag, 3. Auflage, S. 181)
- Este método también puede ser utilizado para parte del trabajo (por ejemplo estimación para
los costes de gestión de proyecto, estimación del esfuerzo de pruebas para las pruebas de
sistema)
- La estimación basada en porcentajes no tiene en cuenta el esfuerzo de la pruebas de regresión,
que pueden ser una parte sustancial de la pruebas de mantenimiento y asociadas al cambio
Estimación basada en porcentajes (2)

- Ventajas
- Técnica de estimación muy simple y potente que no requiere excesiva información de entrada
- Desventajas
- No muy precisa, dado que no tiene en cuenta las hechos particulares del proyecto
- Es necesaria mucha experiencia e intuición por parte de quien realiza la estimación (estimador) con el
objeto de obtener estimaciones válidas
- La decisión respecto del valor del porcentaje puede conducir a debates difíciles
- Tiene en cuenta actividades que ya forman parte de las estimaciones de la planificación del proyecto
(por ejemplo ¿El esfuerzo de prueba del desarrollador forma parte de la estimación correspondiente
al desarrollo o debe formar parte de las estimaciones del proceso de prueba?)
- Los porcentajes varían ampliamente entre proyectos de nuevo desarrollo y proyectos de
mantenimiento
Resumen
- La planificación de pruebas forma parte del plan de calidad corporativo
- El plan maestro de prueba es el elemento básico de toda la planificación de las
actividades de prueba. Debe ser desarrollado de forma temprana en el proyecto
- Plantilla de plan de prueba: IEEE 829
- La estimación de las pruebas puede ser realizada utilizando varios métodos. Tres
métodos habituales son:
- Estimación experta
- Estimación basada en analogías
- Estimación basada en porcentajes
Contenido

03. Seguimiento y control del estado de las pruebas
Seguimiento de pruebas y control de pruebas

- Planificación de pruebas (“test planning”):
Las pruebas deben ser iniciadas Planificación de pruebas
- Seguimiento de pruebas (“test monitoring”):

Control de las actividades de prueba con Análisis de pruebas
el objeto de detectar desviaciones
Control de pruebas
respecto del plan Implementación de pruebas
- Control de pruebas: Corrección del rumbo Evaluación del criterio de salida

de las actividades de pruebas cuando y Generación de informes
sea necesario Actividades de cierre

de pruebas
Planificación de pruebas, seguimiento de pruebas y control de pruebas

- El seguimiento debe ser realizado en base consideraciones medibles
- Métricas en base a errores (utilizando información procedente del sistema de gestión de
incidentes), por ejemplo tasa de detección de errores, defectos detectados/corregidos,
resultados de repetición de pruebas
- Métricas en base a casos de prueba (utilizando información procedente del sistema de gestión de
pruebas), por ejemplo cobertura de casos de prueba, cobertura de requisitos, tasa bien/mal
(“good/bad”) de casos de prueba, cobertura de código, cobertura de riesgo
- Métricas en base a costes (utilizando información procedente del sistema de control del
proyecto), por ejemplo coste de detección de errores, coste de prueba de regresión, coste de
recursos externos
- Los resultados obtenidos de la medición deben ser informados de forma regular
Información de prueba (“test reporting”) (1)

- La información respecto de las actividades de prueba se consolida a los efectos de la
información de prueba (“test reporting”)
- Ejemplo del contenido de un informe de estado de pruebas (según IEEE 829)
- Objeto u objetos de prueba
- Nivel de prueba, ciclo de prueba, período del informe
- Avance de las pruebas (utilizando métricas, por ejemplo número de defectos documentados,
número de casos de prueba ejecutados)
- Recursos utilizados/presupuesto consumido
- Hitos alcanzados (por ejemplo aceptación de objetos de prueba en niveles de prueba específicos)
- Informe de defectos (números de defectos descubiertos, número de defectos corregidos)
- Evaluación del riesgo (nuevos riesgos/riesgos modificados respecto de informes previos)
- Pronóstico: Actividades planificadas para el próximo período de informe
- Evaluación general/estado (semáforo)
Información de prueba (“test reporting”) (2)

- Frecuencia de los informes
- Al inicio del proyecto/en la fase de preparación los ciclos de los informes son más largos
(quincenal o mensual)
- Las fases “críticas” de la ejecución de pruebas requieren ciclos cortos (semanales, o incluso
diario)
- El informe de cierre de pruebas al final del proyecto
- Evaluación de los informes de pruebas

- ¿La evolución es apropiada?
- ¿La ejecución de las pruebas es eficaz y eficiente?
- ¿Las actividades están alineadas con los objetivos de las pruebas? ¿Están siendo alcanzados
objetivos de prueba?
- ¿Cuál es el grado de confianza respecto en el producto software basado en el estado actual de
progreso/evolución/desarrollo?
- Control de pruebas
- El control de pruebas es una tarea de gestión
- El jefe de prueba pertenece a los cuadros directivos del proyecto
- Medidas correctivas como respuesta a desviaciones respecto del plan
- El control de pruebas incorpora a todas las medidas emprendidas durante el proceso de prueba
- Ajuste de las actividades planificadas y, cuando sea necesario, iniciar un nuevo ciclo de
planificación en el plan de proyecto
- Evaluación del cierre de pruebas
- Los criterios de salida de pruebas también son registrados con las métricas de progreso/avance
de pruebas
- Los criterios de salida de prueba que hubieran sido alcanzados son documentados en el informe
de prueba para su aprobación
Medidas de control de pruebas

- Provisión de recursos adicionales
- Más recursos humanos
- Más presupuesto
- Despliegue de herramientas para la automatización de tareas
- Reducción del esfuerzo aplicado al trabajo
- Exclusión de variaciones de casos de prueba
- Simplificación de objetos de prueba complejos/omisión de objetos específicos
- Reducción de la cantidad de datos de prueba
- Omisión de casos de prueba/juegos de prueba
Las medidas de control de pruebas son documentados con el objeto de informar a la

dirección del proyecto/cliente respecto de cambios en riesgos en el despliegue del
producto
Resumen
- El seguimiento/monitorización del estado de las pruebas se basa en criterios medibles y
aporta la información necesaria para gestionar el proceso de prueba
- Las desviaciones respecto del plan requieren acciones correctivas
- La presentación regular/periódica de informes aporta información al proyecto y a la
dirección de la compañía respecto del progreso de las pruebas
http://desmotivaciones.es
Contenido

4. Gestión de la configuración
Objetivo
- Durante el desarrollo software se genera una gran cantidad de
datos/información/resultados {artefactos – (“artifacts”)}:
- Documentos de requisitos/especificaciones/diseño del sistema
- Componentes individuales, módulos integrados, sistemas completos
- Un gran número de participantes con roles diferentes en los distintos componentes del
sistema
- La gestión de la configuración es responsable de la asignación explícita de una
denominación para todos los artefactos y su administración
- Asignación de números de versión sucesivos
- Es registrada la autorización (“clearance”) para desarrollos posteriores
- Versiones antiguas son guardadas para un futuro control
- Es registrado el acceso a los artefactos
Observaciones generales
- La gestión de la configuración tiene un rol de apoyo dentro de un proyecto - todos los
cambios deben ser registrados en un lugar común y comunicados haciendo uso de
procesos definidos
- Las expectativas respecto de la gestión de la configuración pueden variar de forma
considerable dependiendo del tipo y alcance de proyecto - se debe desarrollar un plan
de gestión de la configuración específico
- El IEEE 828 aporta un estándar para la gestión de la configuración y el plan de gestión de
la configuración
- La gestión de la configuración no es una actividad particular del proceso de prueba, es
necesaria durante todas las fases de un proyecto
- La gestión de la configuración sin una herramienta apropiada sólo es posible en
proyectos muy pequeños
Definiciones
Gestión de la configuración GC [“configuration management (CM)”] se refiere a un
conjunto de medidas que complementan al desarrollo software:
- Gestión del cambio (“change management”) sigue todas las actividades, por ejemplo cambios en
el código fuente para cada solicitud de cambio
- Gestión de la construcción (“build management”) describe todos los pasos para crear una
versión de un producto software con el objeto de ser suministrado como un todo o subsistemas
individuales
- Gestión de entregas (“release management“) permite la definición de versiones aisladas para
cada artefacto componente de una versión completa de un producto a ser probado, entregado,
etc.
- Gestión de versiones (“versions management”) (como parte de GC) registra toda la información
de acceso para cada artefacto: versión actual (número), último cambio, último usuario, etc.
Problemas abordados por la gestión de la configuración

- ¿Cuál es la versión actual? La ambigüedad con respecto a qué versiones se
corresponden puede resultar en actividades de desarrollo basadas en versiones antiguas
(obsoletas) de la especificación
- ¿Qué ha sido modificado, cuando y quien lo modificó? Son posibles cambios
concurrentes de un fichero: ¿qué cambios pueden ser sobrescritos?
- ¿Qué versión del fichero ha sido probada? Es difícil probar y extraer una conclusión de
unas pruebas cuando no se tiene conocimiento concreto de la versión de la que se trata
- ¿Qué artefactos se corresponden? ¿Qué versiones han sido agrupadas para crear las
distintas entregas (“release”)?
Los requisitos sobre GC conforman el punto de vista del proceso de prueba

- Control de versiones (“version control”)
- Clasificar, guardar y recuperar diferentes versiones de un objeto (V1.0, V1.1, etc.)
- Gestión de la configuración (gestión de entregas – (“release management”))
- Determinar y administrar toda la información en las versiones correspondientes que conforman
un subsistema
- Protocolos, comentarios y razones para los cambios realizados
- Mantener un registro del estado
- Trazar defectos y cambios, registrar informes de problemas y aportar vuelta atrás de actividades
(“backtracking of activities”)
Auditoria de la configuración (“configuration audit”)

- Se introduce una auditoria de la configuración con el objeto de comprobar la efectividad
de las actividades de la gestión de la configuración
- La auditoria de la configuración comprobará:
- Si todos los componentes individuales de un sistema están incluidos en la gestión de la
configuración
- Si las configuraciones individuales pueden ser identificadas correctamente
Resumen
- La gestión de la configuración es necesaria para administrar los cambios sobre los
objetos de prueba y sus respectivas versiones
- Información de la construcción (“build”) y la entrega (“release”) es conservada con el
objeto de poder reconstruir versiones antiguas
- La gestión de la configuración se aplica al proceso de desarrollo software completo, no
solamente al proceso de prueba
- La gestión de la configuración es apenas posible sin la herramientas apropiadas
Contenido

05. Riesgo y proceso de prueba
Riesgo
- Riesgo (from: Deutsche Wikipedia)
- “A risk is a calculated prediction of a possible damage respectively loss in case of a negative
outcome (danger) or a possible advantage respectively gain in case of a positive outcome
(chance). “
- El riesgo es la probabilidad de un resultado negativo (matemático), o la probabilidad de la
ocurrencia de un suceso negativo multiplicada por el monto del daño económico (económico)
- Riesgo (“Waltzing with bears“, Tom DeMarco/Timothy Lister)
- “A possible future event that will lead to an undesired outcome (cause) respectively this
undesired outcome itself (effect).”
El riesgo asociado al proyecto y al producto deben ser tenidos en cuenta durante la

planificación y el diseño de casos de prueba, cuando se prioricen casos de prueba, cuando
se seleccionen métodos y durante la ejecución de pruebas
Riesgos de proyecto (1)

- Riesgos asociados a la organización (“organizational risks”)
- Capacitación, formación y disponibilidad del personal
- Problemas personales entre equipos/miembros del equipo
- Cooperación insuficiente entre departamentos/conflictos de intereses
- Estimaciones no realistas de plazos del proyecto
- Riesgos tecnológicos
- Requisitos defectuosos, incompletos o no realistas
- Tecnologías, métodos, herramientas, etc. nuevas o que presentan incertidumbres para el
desarrollo software
- Déficit de calidad en productos
- Disponibilidad de un entorno de prueba complejo

- Riesgos ambientales (“environmental risks”)
- Deficiencias por parte de organizaciones externas en la provisión de componentes (plazos,
calidad, coste)
- Problemas de aceptación y otros inconvenientes contractuales con proveedores
- Acceso concurrente a recursos externos
- Cambios en requisitos legales
- Los riesgos asociados al proyecto afectan al éxito del proyecto y deben ser gestionados
- Estimación de la probabilidad y daño potencial

- Implementar medidas apropiadas para tratar los riesgos identificados:
- Mitigación del riesgo (preparación activa de medidas para reducir la probabilidad y/o el daño
potencial)
- Control del riesgo (preparar las medidas necesarias en el caso en el cual el riesgo se convierte en
un problema, contar con tiempo y fondos disponibles)
- Ignorancia del riesgo (esperar que el riesgo no se convierta en un problema, rezar, cruzar los
dedos, etc.)
- Transferencia del riesgo (traspaso del riesgo a otra área/organización)
- Eludir el riesgo (evitar situaciones de riesgo)
Cuando se analizan, gestionan y mitigan los riesgos, el jefe de proyecto sigue unos
principios bien establecidos de gestión de proyecto. El esquema de la norma IEEE Std 829
para planes de prueba requiere que se establezcan las gestiones de riesgo y contingencia
Riesgos de producto
- Los riesgos asociados al producto son el resultado de problemas relacionados con el
producto suministrado
- Funcionalidad insuficiente del producto suministrado
- Atributos no funcionales insuficientes
- El producto no es idóneo para su uso previsto, por lo tanto no puede ser puesto en operación
(producción)
- El producto provoca daños a la propiedad
- El producto provoca lesión o muerte accidentales
- Las pruebas se ejecutan para reducir o evitar los riesgos asociados al producto
- Riesgo = probabilidad de ocurrencia x daño potencial
- Las pruebas reducen la probabilidad de ocurrencia de un riesgo
- Son necesarias pruebas más intensivas en caso de daño potencial alto
Gestión de riesgos de producto (1)

- Gestión de riesgos de producto utilizando pruebas basadas en el riesgo
- Identificar, analizar y priorizar riesgos
- Influencia del riesgo tenido en cuenta durante la planificación de pruebas
- Seleccionar los métodos de prueba para mitigar riesgos
- Asignar alcance de las pruebas (profundidad) de acuerdo al nivel de riesgo
- Adaptar el orden de ejecución de casos de prueba (¡los casos de prueba importantes en
primer lugar con el objeto de detectar defectos críticos de forma temprana!)
- Actualizar la lista de evaluación de riesgos (“risk assessment worksheet”) de forma regular
- Los riesgos pueden desaparecer (el proveedor ha entregado en plazo)
- Pueden aparecer nuevos riesgos (el cliente solicita funciones adicionales)
- Los riesgos pueden cambiar (epidemia de gripe)
Gestión de riesgos de producto (2)

- Beneficios de las pruebas basadas en el riesgo:
- Los métodos de prueba son seleccionados de forma particular con el objeto de mitigar los
riesgos identificados
- El alcance de las pruebas se ocupa de los riesgos identificados
- El alcance del proceso de prueba tiene en cuenta los riesgos identificados. De esta forma, el
esfuerzo en el proceso de prueba se centra en abordar la reducción del riesgo potencial
- Los riesgos de fallo son detectados de forma temprana, por lo tanto se hace más económica su
corrección
- Incluso, en el caso de un aborto de pruebas, se asegura que los casos de prueba más
importantes han sido ejecutados (asignación de prioridades a pruebas basada en el riesgo)
Resumen
- Los riesgos asociados al proyecto y al producto ponen en peligro el éxito del proyecto,
los riesgos deben ser gestionados
- Los riesgos pueden ser tecnológicos, del entorno o estar asociados a la organización
- Riesgo (valor) = probabilidad de ocurrencia por daño potencial.
- “La gestión del riesgo es gestión de proyecto para adultos”.*
* “Waltzing with bears“, Tom De Marco/Timothy Lister

Contenido

06. Gestión de incidencias
Detección de errores* durantes las pruebas

- El probador ejecuta los casos de prueba y registra los resultados
- Posteriormente se analizan las desviaciones entre los resultados esperados y los
obtenidos:
- Se identifican los fallos (los fallos pueden ocurrir en todo lugar: en documentos, en el código, en
los datos de salida de un objeto de prueba, en un texto de ayuda)
- En este punto (temporal), las tareas del probador han finalizado por el momento
- El probador espera la versión corregida del programa para ejecutar la repetición de pruebas
(“retest”)
- Posteriormente, el seguimiento (“tracking”) de errores se realiza utilizando un sistema
de gestión de incidencias (sistema gestión de defectos)
* Nota: En el presente capítulo, defecto e incidencia se utilizan como sinónimos

¿Quien hace qué actividad? (1)

- Ejecuta los casos de prueba con el objeto de detectar errores
- Registra los resultados en un protocolo de pruebas
- Introduce los defectos (incidentes) en un repositorio (informe de problemas)
- Jefe de prueba (“test manager”)

- Evalúa el informe de problemas
- Asigna prioridades a los defectos (de acuerdo con la dirección del proyecto, cliente, etc.)
- Redacta el informe de avance en función del estado actual de las labores de corrección
Quien hace qué actividad? (2)

- Consejo de Control del Cambio (CCC) (“Change Control Board (CCB)”)
- Decide respecto de los cambios de requisitos y sus prioridades
- Desarrollador
- Analiza los fallos, localiza la causa de los defectos
- Corrige la causa de error de acuerdo con la prioridad asignada
- Ejecuta todos los cambios aprobados
- Nota: todas estas tareas son ejecutadas de forma iterativa:

- Jefe de pruebas (“test manager”)
- Consejo de Control de Cambio (CCC) (“Change Control Board (CCB)”)
- Desarrollador (“developer”)
- Probador (“tester”) …
Estructura de un informe de incidencia (informe de error)

- ¡El informe de incidencias describe un fallo, no su causa!
- La plantilla/estructura de un informe de incidencia puede ser encontrada en el
estándar IEEE 829 (Anomaly Report)
- Detalles que puede incluir un informe de incidencia:

- Datos de la incidencia
- Número único del defecto (normalmente generado de forma automática)
- Objeto de prueba (denominación, versión), paso de prueba
- Entorno de prueba
- Nombre del autor del informe de incidencia
- Fecha de la primera ocurrencia
- Clasificación de errores
- Clase de defecto (“defect class”) (también severidad del defecto)
- Estado del defecto (“defect state”) (error nuevo, repetición de prueba, etc.)
- Prioridad (“priority”) (asignación de la urgencia)
Estructura de un informe de incidencias

- Elementos que puede incluir un informe de incidencias:
- Descripción
- Caso de prueba (aporta todos los detalles respecto de las precondiciones)
- Resultado del defecto/modo de fallo (usando una descripción del resultado obtenido y el
resultado esperado)
- Descripción de la desviación para facilitar su resolución (incluyendo informes, capturas de
pantalla, mensajes de error de la aplicación, etc.)
- Referencias cruzadas a informes relacionados
- Comentarios
- Acciones correctivas tomadas
- Registro histórico (“history log”)
- Hora y usuario que ha realizado cambios
- Muchos sistemas hacen un seguimiento automático de cambios en el ciclo de vida del
incidente/error
Clase de defecto y prioridad del defecto

La severidad de un fallo se expresa por la asignación de una clase de defecto {sinónimo:
clase de fallo(“failure class”)}
- Las clases de defectos a utilizar pueden ser: defecto crítico, defecto mayor, defecto medio,
defecto menor. Son frecuentes tres o cuatro clases de defectos
- El criterio para la clasificación puede ser la influencia en la usablidad del producto
La prioridad tiene en cuenta el efecto del fallo:
- Impacto sobre la funcionalidad del programa
- Impacto sobre el proyecto, sobre el cliente
- Posibilidad de aportar una solución (corrección) inmediata al problema o en la siguiente entrega
La prioridad rige la urgencia de la corrección
Estado de un defecto
- El estado de un defecto aporta información relativa al progreso/evolución del trabajo que ha
sido desarrollado para este defecto
- Los posibles estados de un defecto son, pero no están limitados a, los siguientes:
- Nuevo (“new”) – El probador ha introducido un defecto en el sistema
- Abierto (“open”) – Informe de problema confirmado (por el jefe de prueba o desarrollador)
- Rechazado (“rejected”) – Rechazado el informe de problema (por el jefe de pruebas o desarrollador)
- Inspección (“inspection”) – El desarrollador intenta identificar el defecto
- En observación (“surveillance”) – El defecto no puede ser reproducido, se encuentra bajo vigilancia
- Trabajo en progresión (“WorkInProgress”) – El defecto es localizado y preparado/desbloqueado para su
corrección
- Repetición de pruebas (“retest”) – El desarrollador ha corregido la causa del error
- Finalizado (“finalized”) – El probador ha verificado la corrección a través de la repetición de la/s prueba/s
- No resuelto (“NotSolved”) – El probador no ha podido verificar la corrección, el defecto aún se encuentra ahí
- Estados y transiciones para el flujo de trabajo de la gestión de incidencias
Nuevo Rechazado
Abierto En observación
Inspección Observación:
⁻ El número de estados
soportados por
Trabajo en herramientas es variable
progresión (pueden ser tres, pueden
ser veinte).
Repetición de
No resuelto Finalizado
prueba
- ¡Sólo un probador puede poner un defecto en estado Finalizado!
- Normalmente el jefe de prueba decide si un defecto debe ser corregido o rechazado - de
forma alternativa el consejo de control del cambio puede decidir sobre la corrección de
un defecto teniendo en cuenta el coste de reparación
- Todos los cambios (incluidos los comentarios) deben ser registrados en el sistema de
gestión de incidencias
- Se asegura el control continuo sobre el estado de corrección de un defecto
- Pueden ser planificadas las actividades de pruebas futuras
- En ocasiones, deben ser generados casos de prueba adicionales con el objeto de localizar la causa
de un fallo
Análisis de informes de defecto

- Todos los informes de defecto son analizados de forma sistemática con el objeto de
evaluar el estado de desarrollo de las actividades de corrección de defectos,
conformidad con el plan de proyecto y la calidad software
Elementos de atención característicos:
- ¿Es perceptible una reducción en el número de detecciones de nuevos defectos? ¿O se está
incrementando el número a lo largo del ciclo de vida del proyecto?
- ¿Hay objetos de prueba particulares que presenten un alto número de defectos? ¿Hay algún objeto
de prueba que presente un número de defectos más bajo que el número medio de defectos?
- ¿Cuántos defectos de severidad alta/prioridad alta aún siguen abiertos?
- ¿Cuánto tiempo requiere la corrección de un defecto? ¿Cuál es el tiempo medio para la corrección
de defectos?
Las herramientas de gestión de incidencias ofrecen una amplia variedad de informes de

estadísticas de defectos
Resumen
- La gestión de incidencias es la gestión de las desviaciones/defectos detectados durante
las pruebas
- La gestión de incidencias es un proceso en sí mismo con un flujo de trabajo
(“workflow”) específico
- Están disponibles potentes herramientas para dar soporte a la gestión de incidencias,
que cubren también las tareas de la gestión del cambio
- Las expresiones gestión de las desviaciones (“deviation management”) es utilizado con
frecuencia como sinónimos de la gestión de incidencias

Capítulo No.5 Istqb Gestión de Pruebas

Cargado por

Copyright:

Formatos disponibles

Capítulo No.5 Istqb Gestión de Pruebas

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Capítulo No.5 Istqb Gestión de Pruebas

Cargado por

Copyright:

Formatos disponibles

Probador Certificado – Nivel Básico

Capítulo V – Gestión de pruebas

La gestión de pruebas como parte del proceso de prueba

Actividad Producto resultado del trabajo

Pruebas de aceptación Entrega (“release”) del producto software

Los equipos de prueba deberían ser independientes

Otras formas de conformar equipos de prueba

El orden de enumeración refleja el grado de independencia

Perfiles del personal de pruebas

Jefe de prueba (“test leader”) {también gestor de prueba (“test manager”) o

Diseñador de prueba (“test designer”)

Ingeniero de automatización de prueba (“test automation engineer”)

Administrador del sistema de prueba (“test system administrator”)

Probador software (“software tester”)

Experto técnico (“technical expert”)

Competencias no técnicas (“soft skills”)

Organización de equipos de pruebas

Actividades de Diseño de casos Evaluación de

Tareas del líder de prueba – Sumario

Tareas del líder de pruebas: Gestión de pruebas

Tareas del líder de prueba: planificación de prueba (“test planning”)/Planificación

una estrategia de prueba para un

(“test planning and control”)

Tareas del líder de pruebas: planificación de pruebas (“test

- Planificación del proceso de prueba:

Tareas del líder de pruebas: planificación de pruebas (“test

al inicio del proyecto

diversas actividades del proceso de prueba

y la planificación de las pruebas debe ser adaptada

Tareas del líder de pruebas: planificación de pruebas (“test

planificación de los recursos de prueba

- El desarrollo del proyecto debe ser tenido Actividades de cierre

Tareas del líder de pruebas: planificación de prueba (“test

- El control de las actividades de prueba en curso se realiza utilizando métricas

Tareas del líder de pruebas: especificación de pruebas (“test specification”)

de prueba son especificadas, es decir, se

caso de prueba y cómo debe ser ejecutado.

- Los casos de prueba están constituidos por Actividades de cierre

del rango esperado? – Número de defectos

repetición de pruebas, etc.

Tareas del líder de pruebas: ejecución y control

- Ejecutar ciclos de pruebas adicionales / omitir ciclos

- Modificar la prioridad de ciclos de las pruebas

Tareas del líder de pruebas: evaluación (“evaluation”)

- Los informes generados durante la ejecución

sumario por clase de errores, estadísticas),

son una importante fuente de información

compañía (por ejemplo como base para la

Tareas del líder de pruebas: evaluación (“evaluation”)

- El jefe de proyecto, de acuerdo con

de la aceptación de los objetos de

("test summary report") aseguran la ejecución

Tareas del probador* (“tester”) – Sumario

Tareas del probador (“tester”) (1)

- Analiza y evalúa bases de prueba

combinaciones de datos de prueba

Tareas del probador (“tester”) (2)

Evaluación del criterio de salida

Tareas del probador (“tester”) (3)