Capitulo 5

CAPÍTULO 5.
GESTIÓN DE PRUEBAS
Capítulo 5. Gestión de Pruebas
5.1 Organización de Prueba
5.1.1 (K2) Pruebas independientes
5.1.2 (K1) Tareas del líder de pruebas y del tester
5.2 Planeación y estimación de pruebas
5.2.1 (K2) Propósito y contenido del plan de pruebas
5.2.2 (K2) Estrategia y enfoques de pruebas
5.2.3 (K2) Criterios de entrada y salida (Definición de ready y done)
5.2.4 (K3) Calendarización de la ejecución de pruebas
5.2.5 (K1) Factores que influyen en el esfuerzo de prueba
5.2.6 (K2) Técnicas de estimación de pruebas
5.3 Control y monitoreo de las pruebas
5.3.1 (K1) Métricas usadas en pruebas
5.3.2 (K2) Propósitos, contenidos y audiencias para informes de prueba
5.4 Gestión de la configuración
5.5 Riesgos y pruebas
5.5.1 (K1) Definición de riesgo
5.1.2 (K2) Riesgos de producto y proyecto
5.5.3 (K2) Pruebas basadas en riesgos y calidad del producto
5.6 Gestión de defectos
5.1 Organización de Pruebas
Pruebas Independientes
Las tareas de prueba pueden ser realizadas por personas en un rol de prueba
específico o por personas en otro rol (por ejemplo, el usuario).
Que la pruebas sean independientes hace que el tester sea más eficaz para
detectar defectos, debido a diferencias entre la manera de pensar del autor y del
tester.
La independencia no es un reemplazo de la familiaridad, y en ocasiones los

desarrolladores pueden encontrar defectos en su propio código de manera
eficiente.
+ INDEPENDENCIA 5. Equipo independiente especializado en pruebas

de sw subcontratado o externo a la organización.
¿Quién Hace 4. Equipo independiente especializado en pruebas
las pruebas? de sw, tales como: usabilidad, rendimiento,
seguridad, entre otros.
3. Equipo independiente que se puede formar con

el equipo de pruebas, área comercial o de negocio
(usuarios), reportando a la gerencia del proyecto o
gerencia ejecutiva.
2. La prueba la realiza alguien diferente a quien

escribió el código, un desarrollador probando el
código de su colega.
1. No hay testers independientes, son los

desarrolladores quienes prueban su propio código.
- INDEPENDENCIA
La forma en la que se implementa independencia de las pruebas variará

según el modelo de ciclo de vida del desarrollo de software por ejemplo:
En el desarrollo ágil, los

testers pueden formar parte
Los product owners pueden realizar
de un equipo de desarrollo.
pruebas de aceptación para validar
las historias de usuario al final de
cada iteración.
En algunas organizaciones que usan métodos ágiles, los

testers también pueden considerarse parte de un equipo
de pruebas independiente más grande.
Beneficios potenciales de la independencia de las pruebas:
Los testers independientes pueden reconocer diferentes tipos de fallas

en comparación con los desarrolladores debido a sus diferentes
antecedentes, perspectivas técnicas y sesgos.
Un tester independiente puede verificar, desafiar o refutar los

supuestos realizados por las partes interesadas durante la
especificación e implementación del sistema.
Inconvenientes de la independencia de las pruebas:

• El equipo de desarrollo se puede aislar del resto del equipo y dejar de
compartir la visión de calidad en conjunto, por ejemplo no aceptando
la priorización de los defectos por parte del negocio.
• Podrían percibir al equipo de pruebas como un cuello de botella

culpado por retrasos en la liberación.
• Los desarrolladores pueden perder su sentido de responsabilidad por

la calidad.
• Los testers independientes pueden carecer de información importante

(por ejemplo, sobre el objeto de prueba).
“Las organizaciones pueden lograr con éxito la independencia de

las pruebas trabajando en evitar los inconvenientes”
Tareas del Líder de pruebas y del Tester

Las actividades y tareas realizadas por estos dos roles dependen del
contexto del proyecto y del producto, así como de las habilidades de las
personas en los roles y la organización.
Líder de Pruebas
Este rol tiene la responsabilidad general del

proceso de prueba y del liderazgo exitoso de las
actividades de prueba.
• Esta función puede ser realizada por un

gerente de pruebas, un gerente de proyectos,
un gerente de desarrollo o un gerente de
control de calidad.
• En proyectos u organizaciones grandes, varios

equipos de pruebas pueden informar a un
gerente de pruebas, coach de pruebas o
coordinador de pruebas, y cada equipo está
encabezado por un líder de pruebas.
Tareas típicas del líder de pruebas [Test Lead]: 1/3
• Desarrolla o revisa la política de prueba de la organización.

• Planifica las actividades de pruebas considerando el contexto, los objetivos y
riesgos de la prueba. Esto incluye la selección de enfoques de prueba, la
estimación del tiempo, esfuerzo y costo de la prueba, así como la adquisición
de recursos, la definición de los niveles y ciclos de prueb y la planificación de
la gestión de defectos.
• Escribe y actualiza el plan de pruebas.
• Coordina el plan de pruebas con el gerente del proyecto, dueños del
producto y otros interesados (por ejemplo el equipo de desarrollo).
• Comparte la perspectiva de las pruebas con otras actividades del proyecto,
como la planificación de la integración.
• Inicia el análisis, diseño, implementación y ejecución de pruebas, monitorea
el progreso de la prueba, los resultados, y verifica el estado de los criterios de
salida.
• Prepara y entrega informes del progreso de las pruebas basados en la

información recopilada.
• Adapta el plan en función de los resultados y el progreso de las pruebas y
toma las medidas de control necesarias.
• Da el soporte para configurar el sistema de gestión de defectos.
• Define métricas adecuadas para medir el progreso de las pruebas, evaluar la
calidad de las pruebas y el producto.
• Apoya en la selección e implementación de herramientas para soportar el
proceso de prueba, incluyendo la recomendación del presupuesto necesario
para la selección de la herramienta, la compra y/o el soporte de la misma, la
asignación de tiempo y esfuerzo para los proyectos piloto y el apoyo
continuo en el uso de la herramienta.
• Decide a cerca de la implementación del entorno o ambiente de prueba.

• Promueve y defiende a los testers, al equipo de pruebas y a la profesión de
prueba dentro de la organización.
• Desarrolla las habilidades y planes de carrera de los testers (Por ejemplo,
promoviendo entrenamiento, evaluaciones de desempeño, brinda coaching,
etc.)
“El uso de herramientas y plantillas

aumentará la calidad y puede reducir la
carga de trabajo de las actividades del líder”
La forma en que se lleva a cabo la función de líder de pruebas varía según el

ciclo de vida del desarrollo del software. Por ejemplo:
En el desarrollo ágil, algunas de las tareas del líder son realizadas

por el equipo ágil, especialmente aquellas tareas relacionadas con
las pruebas que hace un tester dentro del equipo.
Las tareas que incluyen a varios equipos, o que tienen que ver con
la administración del personal, pueden ser realizadas por gerentes
de prueba fuera del equipo de desarrollo, que a veces se
denominan entrenadores (coachs) de prueba.
Tareas típicas del tester [Test Lead]: 1/2
• Revisa y contribuye con el plan de pruebas.

• Analiza, revisa y evalúa los requisitos, las
historias de usuario, criterios de aceptación,
especificaciones, es decir, las bases de la
prueba.
• Identifica y documenta las condiciones de
prueba.
• Registra la trazabilidad entre los casos,
condiciones y las bases de prueba.
• Diseña, configura y verifica el ambiente de
prueba, en coordinación con el administrador
del sistema y de la red.
• Diseña e implementa los casos de prueba y
procedimientos de prueba.
Tareas típicas del tester [Test Lead]: 1/2
• Prepara y adquiere los datos de prueba.

• Crea el detalle del plan de ejecución de prueba.
• Ejecuta pruebas, evalúa los resultados esperados y documentan los
problemas encontrados.
• Utiliza herramientas adecuadas para facilitar el proceso de prueba.
• Automatiza las pruebas si es necesario [esta tarea también puede ser
realizada por un desarrollador o automatizador].
• Evalúa las características no funcionales como performance,
eficiencia, confiabilidad, usabilidad, seguridad, compatibilidad y
portabilidad.
• Revisa las pruebas desarrolladas por otros testers.
Se pueden manejar roles especializados en ciertas funciones como por

ejemplo, personas que trabajan específicamente en análisis y diseño de
pruebas o que ejecutan tipos de pruebas específicos como
performance, o los que automatizan pruebas.
Cada proyecto tendrá diferentes niveles de prueba y diferentes personas pueden

asumir el rol del tester, esto dependerá de los riesgos relacionados con el
producto, el proyecto y el modelo de ciclo de vida de desarrollo. Por ejemplo:
Analistas de negocios, expertos en Aceptación

la materia y usuarios, serán los
encargados de este nivel.
Áreas operativas y/o el personal que
Aceptación
administra el sistema, serán los
Operacional
responsables de este nivel.
Un equipo de prueba
independiente, es responsable Sistema e integración de
de estos niveles. sistemas
4
Los desarrolladores son
idealmente los
Componente e integración de encargados de estos
componentes niveles bajos.
5.2 Planeación y Estimación
Propósito y contenido del Plan de prueba

Planeación de La planeación de las pruebas y el plan de pruebas son
Pruebas un medio para comunicarse con otros miembros del
equipo del proyecto, testers, gerentes e implicados.
Control y Seguimiento de las pruebas
Análisis de Pruebas
Durante esta etapa se define:
• El alcance de la prueba, objetivos y riesgos.
Diseño de Pruebas • Enfoque de pruebas.
• Integrar y coordinar actividades de pruebas en el
Implementación de ciclo de vida del software.
la Prueba • Seleccionar métricas para control y monitoreo de
las pruebas.
Ejecución de • Presupuesto para las actividades de pruebas.
Pruebas • Determinar el nivel de detalle y la estructura de la
documentación.
Finalización de la El estándar para la documentación
Prueba de planes de prueba se describe en
la norma de la ISO/IEC/IEEE 29119.
• La planeación esta influenciada por la política y estrategia de pruebas

de la organización, el ciclo de vida y métodos de desarrollo, el
alcance de las pruebas, objetivos, riesgos restricciones, criticidad,
capacidad de prueba y recursos disponibles.
• Un plan de prueba describe las actividades de prueba para proyectos

de desarrollo y mantenimiento.
• La planificación de pruebas es una actividad continua y se realiza a lo

largo del ciclo de vida del producto.
• Conforme avanza el proyecto, el plan se actualiza ya que se cuenta

con mayor información y se pueden especificar detalles con mayor
precisión.
“La retroalimentación de las actividades de prueba se deben utilizar para
identificar riesgos, cambios y así ajustar la planeación”
Política de A nivel de la organización.

Prueba Independiente del proyecto
[Test Policy]
La planeación se puede
documentar en un plan
de prueba maestro y el
detalle de los niveles se Estrategia de Puede ser de toda la
pueden documentar en el Pruebas organización.
Independiente del proyecto.
plan de prueba de nivel. [Test Strategy]
Describe y coordina las Plan de Resume todas las pruebas

pruebas para un proyecto Pruebas del proyecto. Debe
especifico. Implementa la Maestro comunicarse a todos los
estrategia. [Master Test Plan] implicados.
Detalles específicos para Plan de

cada Nivel de Pruebas. No Plan de Nivel Pruebas de Resume las pruebas para un
siempre escrito para niveles de Pruebas Performance tipo de prueba específico.
informales. [Level test Plan] [Performance test
Plan]
Actividades de la planeación de pruebas 1/2
• Determina el alcance, objetivos y riesgos de las pruebas.

• Establece el enfoque general de las pruebas.
• Integra y coordina las actividades de prueba en las actividades
del ciclo de vida del software.
• Define qué tipo de pruebas que se realizarán
• Selecciona las personas que participarán y otros recursos
necesarios para realizar las diferentes actividades de prueba.
• Define cómo se llevarán a cabo las actividades de prueba.
Actividades de la planeación de pruebas 2/2
• Crea un calendario de actividades para el análisis de prueba,

diseño, implementación y ejecución.
• Seleccina métricas para el monitoreo y control de las pruebas.
• Define el presupuesto para las actividades de prueba.
• Define del nivel de detalle, estructura y cantidad de plantillas
a utilizar para documentar las pruebas.
”Los puntos anteriores deben de estar documentados en

el plan de pruebas maestro”
Estrategía de pruebas
La Estrategia de pruebas proporciona una

descripción general del proceso de prueba,
generalmente a nivel de producto u
organización.
Los tipos más comunes de estrategías incluyen:

Analítica (analytical):
Se basa en el análisis de algún factor (por ejemplo, requisito o riesgo).
Las pruebas basadas en riesgo son un ejemplo de un enfoque
analítico, en el que las pruebas se diseñan y priorizan según su nivel de
riesgo.
Basada en modelos (model-based):

Las pruebas se diseñan en función de algún modelo de un aspecto
requerido del producto, como una función, un proceso de negocios,
una estructura interna o una característica no funcional (p. ej.,
confiabilidad). Los ejemplos de dichos modelos incluyen modelos de
procesos de negocio, modelos de estado y modelos de crecimiento de
confiabilidad.
Método (methodical) :
Se basa en hacer uso sistemático de un conjunto predefinido de
pruebas, como una taxonimía de tipos comunes o probables fallas, una
lista de características de calidad importantes, o estándares de
usabilidad de la compañía para aplicaciones móviles o páginas web.
Cumplimiento de procesos (cumplimiento de estandares)

(standard-compliant) :
Implica analizar, diseñar e implementar pruebas basadas en normas y
estándares externos, como los definidos por estándares específicos de
la industria, por la documentación del proceso, por la identificación
rigurosa y el uso de la base de prueba, o por cualquier proceso o
estándar impuesto por o por la organización.
Dirigido (o consultivo) (Consultative or directed):

Donde la cobertura de las pruebas se establece por el asesoramiento de
expertos en tecnología y/o en el área de negocio, que pueden estar
dentro o fuera de la organización.
Contrario a la regresion (Regression-averse):

Esta motivada por el deseo de evitar la regresión de las capacidades
existentes. Incluyen la reutilización de las pruebas existentes, la
automatización extensiva de las pruebas de regresión y los sets de
pruebas. Esta estrategia permite detectar defectos de la regresión.
Reactivo (Reactive):
En este tipo de estrategia, la prueba no se planifica como en las
estrategias anteriores, en este caso la prueba es reactiva al
componente o sistema que se está probando y los eventos que ocurren
durante la ejecución de la prueba. Las pruebas se diseñan e
implementan, y pueden ejecutarse inmediatamente en respuesta al
conocimiento obtenido de resultados de pruebas anteriores. La prueba
exploratoria es una técnica común empleada en estrategias reactivas.
Para lograr pruebas más efectivas se recomienda combinar los diferentes

tipos de estrategias.
Enfoques de pruebas
Si bien la estrategia de prueba proporciona una descripción general del proceso de
prueba, el enfoque de prueba adapta la estrategia de prueba para un proyecto o
lanzamiento en particular. Los enfoques de pruebas:
Son el punto de partida para seleccionar las técnicas, niveles y los tipos de prueba,
y para definir los criterios de entrada y los criterios de salida.
Adaptan la estrategia con base en la complejidad y objetivos del proyecto, el tipo

de producto y el análisis del riesgo del producto.
La selección del enfoque depende del contexto del proyecto y puede considerar
factores como riesgos, seguridad, recursos y habilidades disponibles, tecnología,
naturaleza del sistema, objetivos de prueba y regulaciones.
Criterios de entrada y salida [definición de ready y done]

Con el propósito de tener un control efectivo sobre la calidad del software y de las
pruebas, es recomendable que definas criterios de entrada y criterios de salida,
que te ayudarán a determinar cuando se debe iniciar una determinada actividad y cuando
se puede dar por completada.
Debes definir criterios de entrada y salida para cada nivel de prueba y tipo de prueba, y
diferirán según los objetivos de la prueba.
ready To do In progress done

Criterio de entrada
Comúnmente llamados definición de ready (listo) en el desarrollo ágil,
ready establecen condiciones previas para llevar a cabo una actividad de
prueba determinada. Si no se cumplen los criterios de entrada, es
probable que la actividad resulte más difícil, más lenta, más costosa,
más riesgosa o definitivamente no pueda iniciarse.
Ejemplos:
• Disponibilidad de requisitos testeables, historias de usuario o modelos.
• Disponibilidad de elementos de prueba que han cumplido con los criterios
de salida de cualquier nivel de prueba anterior.
• Disponibilidad de entorno o ambiente de pruebas.
• Disponibilidad de herramientas necesarias.
• Disponibilidad de datos de pruebas y otros recursos necesarios.
Criterio de salida
Comúnmente llamados definición de done (terminado) en el desarrollo
done ágil, definen qué condiciones deben lograrse para declarar un nivel de
prueba o un conjunto de pruebas completadas.
Ejemplos:
• Las pruebas planeadas han sido ejecutadas.
• Se ha alcanzado el nivel definido de cobertura (p. Ej., Requisitos, historias
de usuario, criterios de aceptación o código).
• El número de defectos no resueltos o abiertos está dentro de un límite
acordado.
• El número de defectos restantes es aceptablemente bajo.
• Los niveles evaluados de fiabilidad, eficiencia, rendimiento, facilidad de
uso, seguridad y otras características de calidad relevantes son aceptables.
¿Qué pasa si los criterios de salida no se

cumplen?
Es común que las actividades de prueba se reduzcan
debido al presupuesto que se esta gastando, el
tiempo programado que se completa y la presión
para llevar el producto al mercado.
Puede ser aceptable finalizar las pruebas en tales

circunstancias, si las partes interesadas del proyecto
y los propietarios del negocio han revisado y
aceptado el riesgo de la puesta en marcha sin la
realización de más pruebas.
Calendario de la ejecución de pruebas

Una vez que los casos de prueba y los procedimientos de prueba se producen y
se integran en suites de prueba, las suites de prueba se pueden organizar en un
cronograma de ejecución de prueba que define el orden en el que se
ejecutarán.
Factores que debe tener en cuenta el cronograma de ejecución:
• La priorización.
• Las dependencias.
• Las pruebas de confirmación.
• Las pruebas de regresión.
• La secuencia más eficiente para ejecutar las pruebas.
Lo ideal es que los casos de prueba se ordenen y ejecuten en función de sus

niveles de prioridad, por lo general, ejecutando los casos de prueba con la
prioridad más alta primero, pero considerando sus dependencias.
Las pruebas de confirmación y regresión también deben ser priorizadas, según

su importancia con una retroalimentación rápida sobre los cambios y
considerando sus dependencias.
La calendarización de pruebas debe considerar organizar una

prueba eficiente cumpliendo la priorización y dependencias.
Ejemplo:
ID Caso de Prioridad CP
Dependencias
Prueba 1 = Alta, 2= Media, 3= Baja Regresión
No se puede ejecutar si
1 1 no se ejecuta el 3
2 2 Ninguna
3 2 Ninguna
4 3 Ninguna Si
5 3 Ninguna
El orden de ejecución será: 2, 3, 1, 5, 4

Factores que influyen en el esfuerzo de la prueba

La estimación del esfuerzo de prueba implica predecir la cantidad de trabajo
que se necesitará para cumplir los objetivos de la prueba para un proyecto,
lanzamiento o iteración en particular.
Los factores que influyen en el esfuerzo de la prueba pueden incluir:
Las características del Las características de las

producto personas
Los resultados de la Las características del

prueba proceso de desarrollo
Características del producto:

• Los riesgos asociados al producto.
• La calidad de las bases de prueba.
• El tamaño del producto.
• La complejidad del dominio del producto.
• Los requisitos para las características de calidad (por ejemplo,
seguridad, confiabilidad) .
• El nivel de detalle requerido para la documentación de la prueba
Requisitos para el cumplimiento legal y regulatorio.
Resultados de la prueba:
• El número y la severidad de los defectos encontrados.
• La cantidad de trabajo requerido.
Características del proceso de desarrollo:

• La estabilidad y la madurez de la organización.
• El modelo de desarrollo en uso.
• El enfoque de prueba.
• Las herramientas utilizadas.
• El proceso de prueba.
Características de las personas:

• Las habilidades y la experiencia de las personas involucradas,
especialmente con proyectos y productos similares (por ejemplo,
conocimiento del dominio).
• Cohesión del equipo y liderazgo.
Técnicas de estimación de pruebas

Estimación es un pronóstico o predicción de:
• Una aproximación de lo que costará

• Una idea aproximada de cuánto tardaría una tarea en completarse.
“Es el esfuerzo requerido en términos de tiempo y costo”
Las estimaciones se pueden basar en:
• Experiencia / datos históricos

• Conocimiento de los documentos disponibles
• Suposiciones
• Riesgos calculados
• Recursos materiales y humanos
Existen diferentes técnicas de estimación para establecer el tiempo requerido

para realizar las pruebas adecuadas, dos de las mas utilizadas son las siguientes:
Basada en métricas
Se basa en analizar información de datos y métricas de proyectos
anteriores o datos de la industria.
Basada en expertos
Consiste en consultar a las personas que harán el trabajo y personas
con experiencia en las tareas que se van a realizar, es un enfoque un
poco subjetivo.
Una vez que tenemos la estimación, se pueden

identificar los recursos necesarios y crear el plan
de trabajo o calendario.
Estimación basada en métricas

Utiliza datos históricos de proyectos anteriores o similares como:
• Número de condiciones de prueba.
• Número de casos de prueba diseñados y ejecutados.
• Número de defectos encontrados.
• Interrupciones por ambientes y el tiempo de duración.
Con este enfoque es posible estimar con bastante exactitud cuál sería el costo
y el tiempo requeridos para un proyecto similar.
Método
• Clasificar las tareas de prueba requeridas.
• Buscar un proyecto similar que se haya desarrollado previamente.
• Utilizar el esfuerzo real de ese proyecto como base para la estimación.
• Uso de métricas para calcular el valor de la estimación total.
• Considerar factores de corrección.
Estimación basada en expertos

En este enfoque es necesaria la participación de las personas con más experiencia que
van a ejecutar las tareas, la información proporcionada se usa para obtener la estimación.
En este contexto, los "expertos" podrían ser:
• Expertos en negocios.
• Testers, Analistas y diseñadores, desarrolladores y arquitectos.
• Cualquier persona con conocimiento de la aplicación o objeto de pruebas.
Método
• Identificar todas las tareas a ejecutar.
• Obtener estimaciones para cada tarea de los responsables (de su ejecución) o por
expertos.
• Sumar todos los valores de las tareas.
• Incluir elementos amortiguadores (buffers)/elementos adicionales con el objeto de
cubrir tareas no consideradas o subestimadas.
• Describir cuando deben iniciar y terminar las actividades.
• Incluir dependencias.
En modelos ágiles… En modelos sencuenciales…
Burndown charts, a medida que Los modelos de eliminación de

se captura y se informa el esfuerzo, defectos donde se capturan e
y luego se utiliza para alimentar la informan los volúmenes de defectos
Basado en
velocidad del equipo para y el tiempo para eliminarlos, que
métricas determinar la cantidad de trabajo luego proporciona una base para
que el equipo puede hacer en el estimar proyectos futuros de
siguiente iteración. naturaleza similar.
Wideband Delphi en este enfoque,

Planning poker, los miembros del
grupos de expertos proporcionan
equipo estiman el esfuerzo
Basado en basadas en su experiencia.
estimaciones basadas en su
expertos experiencia.
5.3 Control y Monitoreo de las Pruebas
El seguimiento o monitoreo de pruebas…
El propósito es recopilar información y brindar retroalimentación y

visibilidad sobre las actividades de prueba.
La información que se debe monitorear se puede

recopilar de forma manual o automática y se debe usar
para evaluar el progreso de la prueba y para medir si se
cumplen los criterios de salida o las tareas asociadas
con la definición de done así como, cumplir los
objetivos de cobertura de riesgos del producto,
requisitos, o criterios de aceptación.
El control de pruebas…
Es necesario cuando después del monitoreo nos damos cuenta que las
actividades de pruebas planeadas están retrasadas. Las acciones
tomadas podrían afectar cualquiera de las actividades de prueba y
también pueden afectar otras actividades del ciclo de vida del software.
Se trata de establecer acciones correctivas para

tratar de lograr el mejor resultado posible para
el proyecto.
Ejemplos de acciones correctivas son:
• Ajustes en el alcance de las pruebas, reduciendo los casos de

prueba a ejecutar, reduciendo la cantidad de datos para probar,
cambiar a un enfoque de prueba basada en riesgo.
• Provisión de recursos adicionales, pueden ser materiales o
humanos.
• Aumento en el esfuerzo diario de pruebas. Trabajar tiempo extra.
• Cambiar la priorización de las pruebas cuando ocurre un riesgo
de proyecto identificado (por ejemplo, retrasos en la entrega del
software).
• Cambios en el calendario de pruebas debido a la falta de
disponibilidad del ambiente de pruebas, negociar nuevas fechas.
¿Qué son las métricas de pruebas de software?
“Medida cuantitativa del grado en que un sistema, componente, o

proceso, posee un determinado atributo. Este grado es calculado o
compuesto, basado en dos o más medidas”.
“No puedes mejorar lo que no

puedes medir”
Las métricas deben ser colectadas a lo largo del ciclo de vida

del proyecto, desde que inicia hasta que finaliza la prueba, con
el fin de evaluar:
• El progreso en relación con el cronograma y presupuesto
planificados.
• Calidad actual del objeto de prueba.
• Adecuación del enfoque de prueba.
• Efectividad de las actividades de prueba con respecto a los
objetivos.
Las métricas más comunes incluyen (1/2):
• Porcentaje del trabajo planificado realizado en la preparación del

caso de prueba (o porcentaje de casos de prueba planificados
implementados).
• Porcentaje del trabajo planificado realizado en la preparación del
entorno de prueba.
• Ejecución del caso de prueba (por ejemplo, número de casos de
prueba ejecutados/no ejecutados, casos de prueba aprobados/
fallidos, y/o condiciones de prueba aprobadas/fallidas).
• Información de defectos (por ejemplo, densidad de defectos,
defectos encontrados y corregidos, tasa de fallo y resultados de
pruebas de confirmación).
Las métricas más comunes incluyen (2/2):
• Cobertura de prueba de requisitos, historias de usuario, criterios de

aceptación, riesgos o código.
• Finalización de la tarea, asignación y uso de recursos, y esfuerzo.
• Costo de la prueba, incluido el costo en comparación con el
beneficio de encontrar el próximo defecto o el costo en
comparación con el beneficio de ejecutar la siguiente prueba.
Propósitos, contenidos y audiencias para informes de prueba
El propósito de los informes de prueba es resumir y comunicar la

información de la actividad de prueba, tanto durante como al final de
una actividad de prueba (por ejemplo, en un nivel de prueba).
• El informe de progreso de la prueba (test

progress report), es preparado durante una
actividad de prueba.
• El informe de resumen de la prueba (test

summary report), es preparado al final de una
actividad de prueba.
Durante el monitoreo y control de pruebas, el líder de pruebas

genera regularmente informes de progreso de prueba para las
partes interesadas.
Además del contenido común para los informes de progreso de

prueba y los informes de resumen de prueba, los informes
pueden incluir:
• El estado de las actividades de prueba y el progreso en

comparación con lo planeado.
• Factores que afectan o impiden el progreso.
• Pruebas planificadas para el próximo período de informe.
• La calidad del objeto de prueba.
Cuando se cumplen los criterios de salida, el líder de pruebas emite el

informe de resumen de la prueba. Este informe proporciona un
resumen de las pruebas realizadas, según el último estado de
progreso de las pruebas y cualquier otra información relevante.
Elementos que pueden incluir el informe de resumen de la

prueba o progreso de pruebas (1/2):
• Resumen de la prueba realizada.

• Información sobre lo que ocurrió durante un período de
prueba
• Desviaciones del plan, incluidas las desviaciones en el
cronograma, la duración o el esfuerzo de las actividades de la
prueba.
Elementos que pueden incluir el informe de resumen de la

prueba o progreso de pruebas (2/2):
• Estado de la prueba y calidad del producto respecto a los criterios

de salida o la definición del done.
• Factores que han bloqueado o continúan bloqueando el progreso.
• Métricas de defectos, casos de prueba, cobertura de prueba.
progreso de la actividad y consumo de recursos.
• Riesgos residuales.
• Productos de trabajo de prueba reutilizables producidos.
El contenido de un informe de prueba variará según el proyecto,

los requisitos de la organización y el ciclo de vida del desarrollo
del software.
El contenido de un informe de prueba variará

según contexto del proyecto, los requisitos de la
organización y el ciclo de vida del desarrollo del
software que se este utilizando y la audiencia a
quien va dirigido.
La norma ISO/IEC/IEEE 29119-3 se refiere a

dos tipos de informes de prueba y
contiene estructuras y ejemplos para cada
tipo de informe.
Ejemplos del contenido del informe de pruebas:
• Un proyecto complejo con muchas partes interesadas o un proyecto

regulatorio puede requerir informes más detallados y rigurosos que una
actualización rápida de software.
• En el desarrollo ágil, el informe del progreso de la prueba puede

incorporarse en los tableros de tareas, los resúmenes de defectos y los
gráficos de quemados, que se pueden discutir durante una reunión diaria.
• Además de adaptar los informes de prueba según el contexto del proyecto,

los informes de prueba deben adaptarse de acuerdo a la audiencia que
recibirá el informe.
5.4 Gestión de la Configuración
Gestión de la configuración
• Forma parte de los procesos que intervienen en el desarrollo de
software.
• Determina claramente los elementos que componen el software

o sistema. Estos incluyen código fuente, scripts de prueba, software
de terceros, hardware, datos y documentación de desarrollo y
pruebas.
• Facilita el manejo ordenado de la información y cambios del

sistema. Los cambios se proponen, evalúan e implementan
utilizando un enfoque estandarizado y sistemático.
• Asegura que estos elementos se administran durante todo el ciclo

de vida del proyecto y del producto.
Retos que resuelve la gestión de la configuración:
• Cuando un grupo de personas tienen que trabajar con un software que está
cambiando constantemente.
• Cuando se tiene que soportar más de una versión del software como por
ejemplo:
⁃ Sistemas liberados
⁃ Sistemas en desarrollo
⁃ Configuraciones personalizadas del sistema (diferentes funcionalidades)
⁃ El software debe ejecutarse en diferentes sistemas operativos
• Identificar la versión actual de un documento o software, ¿qué cambió? y
¿quién lo cambió?
• ¿Qué versión del archivo se probó?
• ¿Qué versiones de los artefactos constituyen la versión actual?
Gestión de la configuración nos permite:
• Administrar cambios en documentos, programas, archivos, entre otros.

• Llevar un seguimiento de los cambios identificando fecha, hora y
responsable del cambio.
• Controlar acceso a los documentos, desarrollo en paralelo (dos personas
pueden trabajar sobre el mismo documento o pieza de código).
• Permite recuperar versiones anteriores cuando es necesario.
• Mantener y organizar diferentes versiones del software que son utilizadas
en diferentes configuraciones.
La gestión de la configuración y las pruebas de software:
• Permite controlar las versiones del código que se probará así como
documentación de pruebas (testware) y desarrollo, archivos de
configuración, requisitos y datos de prueba (No incluye datos productivos).
• Soporta el proceso de generación de una versión del sistema para el

ambiente de pruebas.
• Permite mantener un registro de lo que se está probando con los archivos

y componentes que lo conforman.
• La GC no es una actividad propia del proceso de pruebas.

5.5 Riegos y Pruebas
Riesgos de producto y proyecto
El riesgo implica la posibilidad de un evento en el futuro que tenga

consecuencias negativas.
El riesgo es un problema potencial que puede o no ocurrir en el futuro

y el cual podría poner en peligro los objetivos de los implicados del
proyecto.
• Cuando el riesgo se ha materializado se convierte en un problema.
• El nivel de riesgo se determina con la probabilidad y el impacto.
• Los riesgos se clasifican en riesgos del proyecto y los riesgos del

producto.
Riesgos de producto y proyecto
El riesgo es un problema potencial que puede o no ocurrir en el futuro

y el cual podría poner en peligro los objetivos de los implicados del
proyecto.
• Cuando el riesgo se ha materializado se convierte en un problema.
• El nivel de riesgo se determina con la probabilidad y el impacto.
• Los riesgos se clasifican en riesgos del proyecto y los riesgos del

producto.
Riesgos de producto
Implica la posibilidad de que un producto de trabajo (por ejemplo,
una especificación, componente, sistema o prueba) no satisface las
necesidades de sus usuarios y/o partes interesadas.
Cuando los riesgos del producto se asocian

con características de calidad específicas de
un producto (por ejemplo, idoneidad
funcional, confiabilidad, rendimiento,
usabilidad, seguridad, compatibilidad,
mantenibilidad y portabilidad), también se
denominan riesgos de calidad.
Ejemplos de riesgos de producto
• El software no realiza las funciones requeridas de acuerdo con la

especificación.
• El software no realiza las funciones previstas de acuerdo con las
necesidades de los usuarios, clientes y/o partes interesadas.
• La arquitectura del sistema podría no ser adecuada para algunos requisitos
no funcionales.
• Un cálculo podría realizarse de forma incorrecta.
• Una bucle podría codificarse incorrectamente.
• Los tiempos de respuesta podrían ser inadecuados para un sistema de
procesamiento de transacciones de alto rendimiento.
• La retroalimentación de la experiencia del usuario podría no cumplir con
las expectativas del producto.
Riesgos de proyecto
El riesgo del proyecto implica

situaciones que, en caso de que
ocurran, pueden tener un efecto
negativo en la capacidad de un
proyecto para lograr sus objetivos.
Ejemplos de riesgos de proyecto [1/4]

Problemas del proyecto:
• Los retrasos que pueden ocurrir en la entrega, la finalización de la tarea o
el cumplimiento de los criterios de salida o la definición de done.
• Malas estimaciones, reasignación de fondos a proyectos de mayor
prioridad o recorte general de costos en toda la organización puede
resultar en una financiación inadecuada.
• Los cambios tardíos pueden dar lugar a re-trabajo.
Problemas organizacionales:
• Las habilidades, entrenamiento y personal pueden ser insuficientes.
• Los conflictos del personal pueden causar problemas.
• Es posible que los usuarios, el personal de negocios o los expertos en la
materia no estén disponibles debido a prioridades comerciales.

Problemas políticos:
• Los testers no pueden comunicar adecuadamente sus necesidades y/o los
resultados de las pruebas.
• Los desarrolladores y/o testers pueden fallar en el seguimiento de la
información que se encuentra en las pruebas y revisiones.
• Puede haber una actitud inapropiada de las expectativas de las pruebas
(p. ej., no apreciar el valor de encontrar defectos durante las pruebas).
Problemas con proveedores:

• Un tercero que no entrega un producto o servicio necesario, o que va a la
quiebra.
• Problemas contractuales pueden causar problemas al proyecto.

Problemas técnicos:
• Requisitos mal definidos.
• Requisitos que no se cumplen dadas las restricciones existentes.
• No está listo el ambiente de prueba.
• La conversión de datos, la planificación de la migración y el soporte de las
herramientas pueden estar atrasados.
• Las debilidades en el proceso de desarrollo pueden afectar la consistencia
o la calidad de los productos de trabajo del proyecto, como el diseño, el
código, la configuración, los datos de prueba y los casos de prueba.
• La mala gestión de defectos y problemas similares pueden dar lugar a
defectos acumulados y otras deudas técnicas.
Los riesgos del proyecto pueden afectar tanto las actividades de desarrollo como las
actividades de prueba.
Generalmente los gerentes de proyecto son responsables de manejar todos los riesgos del
proyecto, pero también puede suceder que los líderes de prueba tengan la responsabilidad de los
riesgos del proyecto relacionados con la pruebas.
Pruebas basadas en riesgos y calidad del producto

Enfoque basado en riesgo
Nos ayuda a reducir los niveles de riesgo del producto, pues se enfoca en el esfuerzo de
la prueba, para decidir dónde y cuándo comenzar las pruebas e identificar las áreas que
necesitan más atención.
• Implica el análisis temprano del riesgo del producto, que incluye la identificación de
los riesgos del producto y la evaluación de la probabilidad y el impacto.
• La información de riesgo del producto se utiliza para guiar la planeación de la

prueba, la especificación, la preparación y la ejecución de los casos de prueba y el
control y seguimiento.
• Las pruebas se utilizan para reducir la probabilidad de que ocurra un problema, o para
reducir el impacto del mismo.
• Las pruebas se utilizan como una actividad de mitigación de riesgos, para brindar
retroalimentación sobre los riesgos identificados y de riesgos residuales (no resueltos).
En este enfoque, los resultados de análisis de riesgo de producto se utilizan

para:
Priorizar las pruebas nos ayuda
a encontrar los defectos críticos Nivel de Riesgo = Impacto x
tan pronto como sea posible. Probabilidad
Guía la planificación, la
especificación y la ejecución
de la prueba. Cuanto mayor sea el riesgo,
mayor será la cobertura
requerida de pruebas.
Ayuda a determinar el
alcance: técnicas y tipos Planear actividades además
de pruebas a utilizar, de las pruebas para reducir el
priorización de casos de riesgo p. ej., capacitación.
prueba
“Las pruebas basadas en el riesgo se basan en el conocimiento colectivo y el

conocimiento de las partes interesadas del proyecto para llevar a cabo el
análisis del riesgo del producto”
Para asegurar que este enfoque minimice la posibilidad de un fallo del producto se deben
de seguir actividades de gestión de riesgos:
• Evaluar y reevaluar de manera regular lo que puede salir mal (riesgos).

• Determinar qué riesgos son importantes para enfrentar.
• Implementar acciones de mitigación.
• Hacer planes de contingencia en caso de que se conviertan en eventos reales.
Las pruebas pueden identificar nuevos riesgos, ayudar a determinar qué riesgos deben
mitigarse y disminuir la incertidumbre sobre los riesgos.
Impacto x Insignificante Menor Moderado Mayor Catastrófico
Probabilidad 1 2 3 4 5
Muy Alta 5 5 10 15 10 25
Alta 4 4 8 12 16 20
Media 3 3 6 9 12 15
Baja 2 2 4 6 8 10
Muy Baja 1 1 2 3 4 5
A medida que avanza el proyecto, debido a las actividades de mitigación,

los riesgos pueden reducirse en importancia o desaparecer por completo.
5.6 Gestión de Defectos
“Un incidente es una diferencia entre un

resultado real y el resultado esperado”
• Uno de los objetivos de las pruebas es

encontrar defectos, así que todos los
defectos que sean detectados durante las
pruebas deben registrarse.
• La forma en que se registran los defectos

puede variar, según el contexto del
componente o sistema que se esté
probando, el nivel de prueba y el modelo de
ciclo de vida de desarrollo de software.
• Cualquier incidencia identificada debe investigarse y rastrearse desde el

descubrimiento y la clasificación hasta su corrección.
• Para gestionar incidencias hasta su corrección, una organización debe

establecer un proceso de gestión de incidencias que incluya un flujo de
trabajo (ciclo de vida) y reglas para la clasificación.
• Este proceso se tiene que acordar con todos los que participan en la gestión
de incidencias, incluidos los diseñadores, desarrolladores, testers y
propietarios de productos. En algunas organizaciones, el registro y
seguimiento de incidencias puede ser muy informal.
• Durante el proceso de gestión de incidencias, se pueden reportar falsos

positivos. Los testers deben intentar minimizar el número de falsos positivos
reportados como incidencias.
• Se pueden reportar durante cualquier fase del ciclo de vida del

desarrollo, la codificación, el análisis estático, las revisiones, las pruebas
dinámicas o durante el uso de un producto de software.
• Se pueden reportar problemas en el código o sistema de trabajo, o en

cualquier tipo de documentación, incluidos los requisitos, las historias de
usuario y los criterios de aceptación, los documentos de desarrollo, los
documentos de prueba, los manuales de usuario o las guías de instalación.
• Defectos [Pruebas estáticas]

Incidencias • Fallos [Pruebas dinámicas]
Los informes de incidencias tienen los siguientes objetivos:
• Proporcionar a los desarrolladores información sobre cualquier evento

adverso que haya ocurrido, para permitirles identificar los problemas y
corregirlos rápidamente.
• Proporcionar a los gerentes de pruebas un medio para dar seguimiento a la

calidad del producto de trabajo y el impacto en las pruebas.
• Proporcionar ideas para el desarrollo y mejorar el proceso de prueba.

Contenido de un informe de incidencias, puede incluir (1/2):

• Identificador.
• Título y un breve resumen del defecto.
• Fecha, organización emisora y autor.
• Identificación del elemento de prueba y el ambiente.
• Fase del desarrollo en la que se detectó.
• Descripción del defecto que permita la reproducción y
resolución, incluidos registros, capturas de pantalla o
grabaciones.
• Resultados esperados y reales.
• Alcance o grado de impacto (gravedad) del defecto en los
asuntos de las partes interesadas.
• Urgencia / prioridad para arreglar.
• Estado del informe del defecto (Pj, abierto, diferido, duplicado,
en espera, re-test, reabierto, cerrado).
• Conclusiones, recomendaciones y aprobaciones.
• Problemas globales, como otras áreas que pueden verse
afectadas por un cambio resultante del defecto.
Contenido de un informe de incidencias, puede incluir (1/2):

• Historial de cambios, como la secuencia de acciones tomadas por los miembros del
equipo del proyecto con respecto al defecto para aislarlo, repararlo y confirmarlo
como corregido.
• Referencias, incluido el caso de prueba que reveló el problema.
Un ejemplo del contenido de un informe

de defectos se puede encontrar en la
norma ISO/IEC/IEEE 29119-3
Describe los detalles del bug
El arte de reportar bugs… en un área altamente visible
Describe el bug
de forma precisa
Resalta que tan otros lo
peligroso y reconozcan
dañino es el bug
Explicar la
ubicación y el Incluye el horario,
entorno donde se la fecha en que se
encuentra el bug encontró el bug
Detalla los pasos

para encontrar el
bug
Escribe una descripción
corta del bug
Nuevo
Asignado Diferido
Abierto Rechazado
Corregido Duplicado
Ciclo de Vida de No es un
Pendiente P.
un Defecto Confirmación
defecto
Para tener un proceso de

Re-abierto P. Confirmación
gestión de defectos eficaz y
eficiente, las organizaciones
Verificado pueden definir estándares
para los atributos, la
clasificación y el flujo de
Cerrado trabajo de las incidencias.
Consideraciones
Algunos de estos detalles pueden incluirse y/o administrarse de forma
automatica al usar herramientas de gestión de incidencias:
• Asignación automática de un identificador

• Asignación y actualización del estado del informe de incidencias
Los defectos encontrados durante las pruebas estáticas, particularmente

las revisiones, normalmente se documentan de una manera diferente,
por ejemplo, en las notas de la reunión de revisión.

Capitulo 5

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

Capitulo 5

Cargado por

Copyright:

Formatos disponibles

CAPÍTULO 5.

La independencia no es un reemplazo de la familiaridad, y en ocasiones los

+ INDEPENDENCIA 5. Equipo independiente especializado en pruebas

3. Equipo independiente que se puede formar con

2. La prueba la realiza alguien diferente a quien

1. No hay testers independientes, son los

La forma en la que se implementa independencia de las pruebas variará

En el desarrollo ágil, los

En algunas organizaciones que usan métodos ágiles, los

Beneficios potenciales de la independencia de las pruebas:

Los testers independientes pueden reconocer diferentes tipos de fallas

Un tester independiente puede verificar, desafiar o refutar los

Inconvenientes de la independencia de las pruebas:

• Podrían percibir al equipo de pruebas como un cuello de botella

• Los desarrolladores pueden perder su sentido de responsabilidad por

• Los testers independientes pueden carecer de información importante

“Las organizaciones pueden lograr con éxito la independencia de

Tareas del Líder de pruebas y del Tester

Este rol tiene la responsabilidad general del

• Esta función puede ser realizada por un

• En proyectos u organizaciones grandes, varios

Tareas típicas del líder de pruebas [Test Lead]: 1/3

• Desarrolla o revisa la política de prueba de la organización.

Tareas típicas del líder de pruebas [Test Lead]: 2/3

• Prepara y entrega informes del progreso de las pruebas basados en la

Tareas típicas del líder de pruebas [Test Lead]: 3/3

• Decide a cerca de la implementación del entorno o ambiente de prueba.

“El uso de herramientas y plantillas

La forma en que se lleva a cabo la función de líder de pruebas varía según el

En el desarrollo ágil, algunas de las tareas del líder son realizadas

Tareas típicas del tester [Test Lead]: 1/2

• Revisa y contribuye con el plan de pruebas.

Tareas típicas del tester [Test Lead]: 1/2

• Prepara y adquiere los datos de prueba.

Se pueden manejar roles especializados en ciertas funciones como por

Cada proyecto tendrá diferentes niveles de prueba y diferentes personas pueden

Analistas de negocios, expertos en Aceptación

Propósito y contenido del Plan de prueba

• La planeación esta influenciada por la política y estrategia de pruebas

• Un plan de prueba describe las actividades de prueba para proyectos

• La planificación de pruebas es una actividad continua y se realiza a lo

• Conforme avanza el proyecto, el plan se actualiza ya que se cuenta

Política de A nivel de la organización.

Describe y coordina las Plan de Resume todas las pruebas

Detalles específicos para Plan de

Actividades de la planeación de pruebas 1/2

• Determina el alcance, objetivos y riesgos de las pruebas.

Actividades de la planeación de pruebas 2/2

• Crea un calendario de actividades para el análisis de prueba,

”Los puntos anteriores deben de estar documentados en

La Estrategia de pruebas proporciona una

Los tipos más comunes de estrategías incluyen:

Basada en modelos (model-based):

Cumplimiento de procesos (cumplimiento de estandares)

Dirigido (o consultivo) (Consultative or directed):

Contrario a la regresion (Regression-averse):

Para lograr pruebas más efectivas se recomienda combinar los diferentes

Adaptan la estrategia con base en la complejidad y objetivos del proyecto, el tipo

Criterios de entrada y salida [definición de ready y done]

ready To do In progress done

¿Qué pasa si los criterios de salida no se

Puede ser aceptable finalizar las pruebas en tales

Calendario de la ejecución de pruebas