Capítulo 4

Capítulo 4
Ejecución de Pruebas & Reportes de Incidentes
1.Objetivo
Especificar los principales lineamientos y buenas prácticas para el diseño de un plan de pruebas.
2.Alcance
Este documento da soporte a los equipos involucrados en todos los servicios de QA y QC ejecutados
por Tsoft.
3.Responsabilidad
El Responsable de QA es el responsable máximo de concientizar a los equipos de QA sobre lo
establecido en este documento, como así también de su comunicación y capacitación.
4.Referencia
Norma ISO 9001 (La Versión Vigente de la Norma se define en el Registro de Documentos Externos del SGC).
5.Desarrollo
5.1. Conceptos Generales. ...................................................................................................................... 2
6.1.1 Ciclo de pruebas ............................................................................................................................ 2
6.1.2 Iteración ........................................................................................................................................... 2
6.1.3 Fase ................................................................................................................................................. 2
5.2. Documentación durante la ejecución de las pruebas................................................................... 3
6.2.1 Evidencias ....................................................................................................................................... 3
6.2.2 Registro de pruebas ...................................................................................................................... 3
6.2.3 Informe de incidentes .................................................................................................................... 4
5.3. Taxonomía de las Incidencias ......................................................................................................... 5
6.3.1 Criticidad de las Incidencias ......................................................................................................... 5
6.3.2 Ciclo de vida de un incidente. ...................................................................................................... 8
5.4. Seguimiento de Incidencias ............................................................................................................. 9
6.4.1 Verificación de Correcciones ....................................................................................................... 9
5.5. Documentación para la finalización de las pruebas ................................................................... 10
6.5.1 Informe de resumen de pruebas ............................................................................................... 10
Aprobó su
En caso de que este documento esté impreso o se encuentre en una ubicación Elaborado y Aprobado por
Publicación
distinta a la especificada oficialmente para copias controladas en el procedimiento
“PRO-01 -Control de Documentos”, se convierte automática-mente en “COPIA NO K. Fernandez, P. Dedonato,
CONTROLADA” y es solamente para información. Walter Grasso
C. Plakoudakis
DOC-05 – Capitulo 4 - Ejecución de Pruebas & Reportes de Incidentes (Rev. 01)
1 / 12
TSOFT | Av. Belgrano 687 7P C1092AAG Buenos Aires, Argentina | Tel. (+54 11) 5128-3000 | www.tsoft.com.ar
Capítulo 4
EJECUCION DE PRUEBAS / REPORTE DE INCIDENTES
5.1. Conceptos Generales.
5.1.1 Ciclo de pruebas
Con cada nueva versión o fix del producto se realizan alguna o todas las tareas asociadas a las
pruebas, a esto se le llama un ciclo de prueba. Durante el ciclo de vida de un producto, sin
importar cuál sea el proceso de desarrollo, se van generando distintas versiones de la
aplicación. Las actividades de la prueba se realizan para una determinada versión del producto,
sobre la cual se ejecutan las pruebas yse reportan los incidentes encontrados. Las pruebas que
serán ejecutadas sobre una versión son planificadas con anticipación y deberían se re-
ejecutadas, a menos que las prioridades cambien.
En un ciclo de prueba se puede ejecutar una, alguna o todas las pruebas planificadas para el
producto. Cada ciclo de prueba está asociado a una versión inicial o a un fix de la misma
versión del producto a probar.
Uno de los principales desafíos desde el punto de vista de la prueba independiente es estimar
cuantos ciclos de prueba se requieren, ya que no todas las versiones que genera desarrollo
llegan a ser probadas por el equipo de prueba, entre dos ciclos de prueba podrían existir más
de dos versiones del producto generadas por el equipo de desarrollo.
NOTA: Un fix es la versión corregida de cierta aplicación / módulo / entregable realizada por
desarrollo producto de los incidentes reportados durante un ciclo de pruebas.
5.1.2 Iteración
Una de las estrategias posibles durante el ciclo de vida de desarrollo de la aplicación podría ser
por etapas, donde en cada nueva etapa se vaya liberando una nueva funcionalidad. En este
esquema cada vez que la aplicación llega a Testing con una funcionalidad agregada decimos
que es una nueva iteración del producto.
5.1.3 Fase
Durante el ciclo de vida de desarrollo denominamos fase a cada una de las etapas por las
cuales va pasando cada nueva versión de producto desde que se analiza hasta que es liberado
a producción.
Aprobó su
Publicación
C. Plakoudakis
2 / 12
Capítulo 4
5.2. Documentación durante la ejecución de las pruebas.
Durante la ejecución de las pruebas es fundamental conocer el estado del proceso de testing,
saber qué pruebas se han ejecutado y cuáles quedan pendientes, qué defectos se han
encontrado. Para ello, se crean los registros de pruebas y los informes de incidentes.
5.2.1 Evidencias
Documento que registra el resultado de una acción determinada dentro de una prueba, que
podría ser un caso de prueba o un paso dentro de un caso de prueba.
La evidencia aplica tanto para un resultado positivo como para uno negativo. En este último
caso, la evidencia podría acompañar al incidente.
5.2.2 Registro de pruebas
Aprobó su
Publicación
C. Plakoudakis
3 / 12
Capítulo 4
Un objetivo fundamental del proceso de testing es proporcionar información acerca del sistema
que se está probando. El registro de pruebas documenta los aspectos relativos a la ejecución
de las pruebas: qué test se han ejecutado, quién y cuándo los ha ejecutado, en qué orden, en
qué entorno, si el test ha pasado o ha fallado. En este documento es importante también,
asociar la información de ejecución de cada test con versiones específicas del software en
prueba para garantizar la trazabilidad.
La información recogida en el registro de pruebas permite conocer el progreso de la fase de

ejecución de pruebas y tomar decisiones acerca de si el software está listo para pasar a la
siguiente fase.
El registro de pruebas puede dar un panorama de la salud del sistema, el avance de las tareas
de testing, el esfuerzo que nos está requiriendo, la productividad del equipo de desarrollo y
testing.
5.2.3 Informe de incidentes
Hay que resaltar la referencia al término “incidente”; un incidente no tiene porqué deberse
necesariamente a un defecto en el sistema. Un incidente representa una discrepancia entre los
resultados esperados y los resultados obtenidos. Esta discrepancia puede deberse a varios
motivos, como un defecto, un error en la especificación de los casos de prueba, una mala
interpretación de los requisitos, etc.
El informe de incidentes debe contener toda la información necesaria para la identificación y

resolución del incidente: entradas utilizadas, resultados esperados, resultados obtenidos, paso
del procedimiento en el que se ha producido el incidente, configuración del entorno, valoración
del impacto.
Ejemplo de reporte de incidentes:
 Id: Para identificar cada incidente. Por lo general, si se cuenta con una aplicación de
tracking de defectos, el número de identificación lo genera de forma automática.
 Descripción: Breve resumen de la problemática a reportar. Por ej.: Si contamos con

caso de uso se podría reportar de la siguiente manera, CUX – Número de cliente. Error
al ingresar caracteres inválidos.
 Prioridad: Alta, Media, Baja
 La severidad que se le asigna a un reporte, muestra lo que el defecto encontrado “le

hace al sistema”
 Tipo de incidente: Funcional, presentación, inconsistencia de documentación, etc.(Esta

tipificación es acorde al proyecto con el que se está trabajando)
Aprobó su
Publicación
C. Plakoudakis
4 / 12
Capítulo 4
 Paso a paso: Detalle de los pasos a seguir para poder reproducir el incidente.
 Adjunto: Si es necesario se puede adjuntar pantalla, archivo interviniente en la prueba

o evidencia.
 Versión de la aplicación: Versión de la aplicación donde fue detectado el incidente.
 Resultado esperado: Lo que se espera recibir de la aplicación según documentación y

análisis funcional.
 Resultado obtenido: Lo que realmente se obtuvo de la aplicación.
 Parámetros: Datos utilizados para la prueba.
5.3. Taxonomía de las Incidencias
A continuación se describen los tipos más frecuentes de incidencias que pueden detectarse
durante la ejecución de las pruebas.
Tipo de
Descripción
Incidencia
Funcional El programa no realiza todas las funciones que debe realizar o las realiza
en modo incorrecto.
Interfaz entre El programa se comunica incorrectamente con otro/s programa/s.
aplicaciones
Interfaz con El programa interactúa incorrectamente con el usuario debido a fallas en las
usuario pantallas.
Acceso a Datos El programa lee/escribe incorrectamente datos de un archivo o base de
datos.
Performance El programa tiene un conjunto de instrucciones que ejecutan una función en
un período de tiempo que no se considera aceptable.
Fórmulas y cálculo El programa realiza algún cálculo en manera errónea por defectos en
fórmulas matemáticas o cálculos.
Documentación La documentación del programa es incorrecta.
Look & feel Errores de sintaxis, ortográficos, presentación en la pantalla.

Otros Cualquier error no contemplado en la clasificación anterior.
Usabilidad El sistema no cumple con los estándares de mercado en cuanto al uso.
Ejemplo: el botón Aceptar se encuentra a la izquierda del botón Cancelar.
Navegabilidad Diseño que permite al usuario tener control sobre la aplicación. Ejemplo: en
todas las pantallas debe haber un botón: Volver.
5.3.1 Criticidad de las Incidencias
Una posible clasificación de criticidad de incidencias puede ser la siguiente:
Aprobó su
Publicación
C. Plakoudakis
5 / 12
Capítulo 4
Invalidante, Bloqueante ó Crítica
Se asigna esta incidencia ante la ocurrencia de alguno de los siguientes casos o eventos
similares:
Cancelaciones: Detenciones de la ejecución del sistema, las cuales impidan continuar con el
uso de la aplicación.
 Errores no controlados: Se presenta una ventana o pantalla con un mensaje de error

no manejado por el código de la aplicación en prueba (propios de SO, BD, o
aplicaciones de base como navegadores Web, Java VM, etc.), impidiendo la
finalización en forma normal de la funcionalidad invocada o en curso.
 Problemas de funcionalidad: Falta alguna función para poder completar el ciclo del
negocio (ej.: opciones de menú faltantes, o botones que no funcionan; se pone por
caso una opción de Alta no disponible en un ABM).
Una funcionalidad no declarada en la especificación y que el programa realiza,
afectando al ciclo del negocio (ej.: una opción de Baja de un elemento definido como
permanente o que no deba ser eliminado).
 Problemas de ambiente: La aplicación se encuentra instalada de forma que no

permita invocar la funcionalidad, o concluir la transacción, de acuerdo a la
especificación funcional. Se incluyen problemas del ambiente de ejecución (en el
servidor, cliente, red, etc.) que impidan la utilización de la aplicación, o que afecten a
funcionalidades propias del ciclo del negocio. Se consideran también problemas de
migración de objetos y datos. También deben tenerse en cuenta los problemas
relacionados con aplicaciones externas a las que se está probando.
Grave ó Alta
similares:
 Problemas de funcionalidad: Falta alguna función que no afecte al ciclo del negocio
(ej.: ordenamientos, opciones de desplazamiento, o configuración de pantallas).
Una funcionalidad no declarada en la especificación y que el programa realiza, y no
afecte al ciclo del negocio (ej.: opciones de envío de información por correo, o
impresión).
 Validaciones: Restricciones a una acción que debe estar permitida, y viceversa

(permisos a una acción incorrecta). Validaciones faltantes o incompletas.
 Problemas con datos: Errores en la lectura, manejo, interpretación y/o actualización

de datos, afectando a su valor o contenido.
Aprobó su
Publicación
C. Plakoudakis
6 / 12
Capítulo 4
 Máscaras erróneas: Formato erróneo de presentación de datos (en pantallas,
reportes, impresos, archivos, etc.), que impida la lectura, o utilización de su contenido o
valor.
 Campos faltantes o sobrantes: Faltan campos en una pantalla o reporte. Sobran

campos en una pantalla o reporte de modo tal que afecte a la lectura, comprensión, o
utilización del resto de la información presentada.
 Textos erróneos: Los textos mostrados en una pantalla, reporte, botón, u opción del
menú, que tienen errores de contenido, y afecten a la lectura o comprensión de datos
(ej.: títulos, cabeceras de reportes o grillas, etc.).
 Problemas de Performance: Se produce cuando la ejecución de la funcionalidad

invocada no responde dentro del tiempo de respuesta definido como aceptable.
 Problemas de ambiente: Problemas del ambiente de ejecución que no impidan la

utilización de la aplicación, o que no afecten a funcionalidades propias del ciclo del
negocio. Se consideran también problemas de migración de objetos y datos. También
deben tenerse en cuenta los problemas relacionados con aplicaciones externas a las
que se está probando.
Común ó Media
similares:
 Ordenamientos: Presentación de listas en pantallas o en reportes, cuyo ordenamiento

por defecto no es el definido.
 Secuencia incorrecta de validación: Debe tenerse en cuenta el orden en que se

realizan las validaciones a nivel de campo.
 Textos erróneos: Los textos mostrados en una pantalla, reporte, botón, u opción del
menú, que tienen errores de contenido, y no afecten a la lectura o comprensión. Se
consideran, entre otros, los mensajes incorrectos emitidos en validaciones o funciones
que se activan o se realizan correctamente.
 Problemas de refresh: No se refrescan (limpian ó actualizan) correctamente los

campos de una pantalla, sin que esto implique perder el valor impactado durante la
operación.
 Máscaras erróneas: Formato erróneo de presentación de datos (en pantallas,

reportes, impresos, archivos, etc.), que no impida la lectura, comprensión, o utilización
de su contenido o valor.
 Campos sobrantes: Sobran campos en una pantalla o reporte de modo tal que no
afecte a la lectura, comprensión, o utilización del resto de la información presentada.
Aprobó su
Publicación
C. Plakoudakis
7 / 12
Capítulo 4
Leve ó Baja
similares, cuando no impida la lectura, comprensión, o utilización del contenido o valor de los
datos:
 Falta de homogeneidad: Se produce cuando no existe una correspondencia entre los

atributos de presentación definidos según la especificación y los observados en
pantallas y reportes.
 Errores de Ortografía: Se detectan errores de ortografía en textos asociados a

pantallas, reportes, botones u opciones del menú.
 Ubicación errónea: Textos, campos, opciones del menú, listas y botones que se
encuentran en una disposición (ubicación) no deseada.
 Atributos de presentación erróneos: Tamaños, colores, características erróneas que

afecten a pantallas, reportes, campos, botones u opciones del menú.
Mejora
similares:
 Modificaciones sugeridas: Que no son necesarias para el funcionamiento de la

aplicación, pero de incorporarse incrementaría la calidad del producto.
 Diferencias detectadas respecto al relevamiento o solicitudes del usuario:

Aquellos casos que no hayan sido reflejados en la documentación del prototipo pero el
usuario haya dejado indicado que deban responder a una determinada forma, dato o
comportamiento.
NOTA: La criticidad asignada a una incidencia puede variar a lo largo del proyecto, según las
validaciones del líder, referente funcional o el usuario y el contexto de otras incidencias
detectadas durante las pruebas.
5.3.2 Ciclo de vida de un incidente.
Aprobó su
Publicación
C. Plakoudakis
8 / 12
Capítulo 4
5.4. Seguimiento de Incidencias
A partir de la realización de las pruebas correspondientes a cada funcionalidad es necesario

realizar el seguimiento de las incidencias originadas en ellas. Este seguimiento involucra cerrar
las incidencias reportadas en base a las correcciones realizadas, o a las decisiones tomadas al
respecto (es común que ciertas incidencias de baja criticidad queden suspendidas para
corrección posterior a la puesta en Producción).
El seguimiento de las incidencias se realiza en cada nueva versión / fix.
5.4.1 Verificación de Correcciones
Una vez corregida una incidencia y pasada al ambiente de Pruebas, debe verificarse que la
misma ha sido resuelta, para lo cual debe seguirse el procedimiento que se describe a
continuación.
Aprobó su
Publicación
C. Plakoudakis
9 / 12
Capítulo 4
Si la incidencia se originó en la ejecución de un caso, el tester deberá re-ejecutarlo para
verificar que la falla no se produce. De ser así, se cierra la incidencia y si el caso puede
completarse correctamente, cambiará su estado a OK.
Podría suceder aquí que la incidencia estuviera efectivamente resuelta, pero al re-ejecutar el
caso se detectara un nuevo problema. En esta situación el tester deberá reportar una nueva
incidencia asociada al caso.
Si la incidencia no estaba vinculada a la ejecución de un caso, entonces debe reproducírsela

de acuerdo a los pasos descriptos en la incidencia. De no producirse la falla, la incidencia se
cierra.
Si al realizar la verificación de la corrección, el tester comprobará que la falla sigue

produciéndose, deberá reabrir la incidencia.
5.5. Documentación para la finalización de las pruebas
Una vez finalizado el proceso de pruebas, se tiene que proporcionar suficiente información para
que los involucrados en el proyecto puedan conocer los resultados y tomar decisiones.
5.5.1 Informe de resumen de pruebas
El informe final de pruebas se crea en hitos determinados del proyecto o al finalizar un ciclo de
pruebas determinado. La frecuencia de estos informes variará de acuerdo a las características
del proyecto y las necesidades del cliente. Permite comunicar a todos los intervinientes del
proyecto los resultados obtenidos para así decidir si el software está listo para pasar a la
siguiente fase. Podrá ser al final de cada ciclo, al final de cada iteración o ambos.
Este informe proporciona información sobre las pruebas realizadas y el tiempo consumido, así
como valoraciones acerca de la calidad del proceso de testing realizado, del nivel de calidad
alcanzado en el producto. Este informe final puede servir como base para planificar mejoras
futuras en el proceso de testing.
TIPS
 Es importante establecer un orden secuencial en las ejecuciones. Por ej.: Si las pruebas
consisten en dar de alta, modificar, eliminar y consultar una cuenta, el orden de las
pruebas debiera ser: Alta, Consulta, Modificación y por último Eliminación. Establecer
este orden ayuda a no consumir los datos de forma indiscriminada.
 Si se encuentra un defecto al cual no se le puede asociar un caso de prueba porque no
Aprobó su
Publicación
C. Plakoudakis
10 / 12
Capítulo 4
fue diseñado, se aconseja que se agregue el caso de prueba.
 Para cada caso de prueba se puede reportar más de un defecto.
 Un defecto sólo corresponde a un caso de prueba, salvo si se repite en varios casos de

prueba y estamos seguros que su corrección en ese módulo afecta a los demás para
los cuales reportamos el incidente. En este caso se debe reportar una sola incidencia,
asociada al caso de prueba y en los demás casos de prueba hacer referencia al caso
original.
 Es importante redactar correctamente y con el mayor nivel de detalle posible los

incidentes para evitar que el equipo de desarrollo los rechace porque no pueden
reproducirlos.
 Reportar y asociar los defectos a los casos de prueba en el momento de ser

encontrados, si se deja para más tarde puede que nos olvidemos de informarlo.
 Siempre describir un defecto por problema detectado. Si se reporta más de un problema

por defecto corremos el riesgo de que se corrija una parte de lo que fue reportado. Los
problemas restantes, a menudo quedan sin arreglar.
 Es probable que cuando se esté diseñando y/o ejecutando casos de prueba, surja
información que necesitemos para realizar esas tareas. Se recomienda crear una base
de conocimiento para facilitar la tarea a los demás integrantes del equipo y a su vez
actualizar los casos de prueba que fueron diseñados con anterioridad.
 A medida que el número de defectos encontrados aumenta, la probabilidad de que

existan defectos aún no descubiertos aumenta.
 Examinar un programa para comprobar que hace lo que se supone que debe hacer es
sólo la mitad del problema. La otra mitad consiste en ver si el programa hace lo que no
se supone que debe hacer.
 Es importante llevar una estadística de los tiempos en que la aplicación no se encuentra

disponible. De esa forma se puede justificar retraso en las tareas. Bitácora del testing.
 Agregar, siempre que se pueda, algún componente visual ya sea: archivo necesario
para la prueba, captura de pantalla. “Una imagen vale más que mil palabras” PD
 Puede pasar que reproducir un incidente reportado no dé el mismo resultado que al

momento de ser registrado. En este caso, informarlo a desarrollo y que sean ellos
quienes decidan qué tratamiento darle.
Aprobó su
Publicación
C. Plakoudakis
11 / 12
Capítulo 4
 No es conveniente reportar mejoras cuando el número de defectos encontrados es
demasiado alto.
 Para reportar defectos con palabras en mayúscula, negrita, subrayado ya que podría
resultar ofensivo para la persona receptora.
 Se puede definir qué casos de prueba se van a ejecutar de acuerdo a varios

factores: prioridad, tiempo, acuerdo con el cliente, tipo de test a realizar, etc.
6 Diagrama de flujo
No Aplica.
7 Anexos
No Aplica.
Aprobó su
Publicación
C. Plakoudakis
12 / 12

Capítulo 4 - Ejecución de Pruebas y Reportes de Incidentes

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 4 - Ejecución de Pruebas y Reportes de Incidentes

Cargado por

Copyright:

Formatos disponibles

Ejecución de Pruebas & Reportes de Incidentes

EJECUCION DE PRUEBAS / REPORTE DE INCIDENTES

5.1. Conceptos Generales.

5.1.1 Ciclo de pruebas

5.2. Documentación durante la ejecución de las pruebas.

5.2.2 Registro de pruebas

La información recogida en el registro de pruebas permite conocer el progreso de la fase de

5.2.3 Informe de incidentes

El informe de incidentes debe contener toda la información necesaria para la identificación y

Ejemplo de reporte de incidentes:

 Descripción: Breve resumen de la problemática a reportar. Por ej.: Si contamos con

 Prioridad: Alta, Media, Baja

 La severidad que se le asigna a un reporte, muestra lo que el defecto encontrado “le

 Tipo de incidente: Funcional, presentación, inconsistencia de documentación, etc.(Esta

 Adjunto: Si es necesario se puede adjuntar pantalla, archivo interviniente en la prueba

 Versión de la aplicación: Versión de la aplicación donde fue detectado el incidente.

 Resultado esperado: Lo que se espera recibir de la aplicación según documentación y

 Resultado obtenido: Lo que realmente se obtuvo de la aplicación.

 Parámetros: Datos utilizados para la prueba.

5.3. Taxonomía de las Incidencias

Look & feel Errores de sintaxis, ortográficos, presentación en la pantalla.

5.3.1 Criticidad de las Incidencias

Una posible clasificación de criticidad de incidencias puede ser la siguiente:

Invalidante, Bloqueante ó Crítica

 Errores no controlados: Se presenta una ventana o pantalla con un mensaje de error

 Problemas de ambiente: La aplicación se encuentra instalada de forma que no

 Validaciones: Restricciones a una acción que debe estar permitida, y viceversa

 Problemas con datos: Errores en la lectura, manejo, interpretación y/o actualización

 Campos faltantes o sobrantes: Faltan campos en una pantalla o reporte. Sobran

 Problemas de Performance: Se produce cuando la ejecución de la funcionalidad

 Problemas de ambiente: Problemas del ambiente de ejecución que no impidan la

 Ordenamientos: Presentación de listas en pantallas o en reportes, cuyo ordenamiento

 Secuencia incorrecta de validación: Debe tenerse en cuenta el orden en que se

 Problemas de refresh: No se refrescan (limpian ó actualizan) correctamente los

 Máscaras erróneas: Formato erróneo de presentación de datos (en pantallas,

 Falta de homogeneidad: Se produce cuando no existe una correspondencia entre los

 Errores de Ortografía: Se detectan errores de ortografía en textos asociados a

 Atributos de presentación erróneos: Tamaños, colores, características erróneas que

 Modificaciones sugeridas: Que no son necesarias para el funcionamiento de la

 Diferencias detectadas respecto al relevamiento o solicitudes del usuario:

5.3.2 Ciclo de vida de un incidente.

5.4. Seguimiento de Incidencias

A partir de la realización de las pruebas correspondientes a cada funcionalidad es necesario

El seguimiento de las incidencias se realiza en cada nueva versión / fix.

5.4.1 Verificación de Correcciones

Si la incidencia no estaba vinculada a la ejecución de un caso, entonces debe reproducírsela

Si al realizar la verificación de la corrección, el tester comprobará que la falla sigue

5.5. Documentación para la finalización de las pruebas

5.5.1 Informe de resumen de pruebas

 Para cada caso de prueba se puede reportar más de un defecto.

 Un defecto sólo corresponde a un caso de prueba, salvo si se repite en varios casos de

 Es importante redactar correctamente y con el mayor nivel de detalle posible los

 Reportar y asociar los defectos a los casos de prueba en el momento de ser

 Siempre describir un defecto por problema detectado. Si se reporta más de un problema

 A medida que el número de defectos encontrados aumenta, la probabilidad de que

 Es importante llevar una estadística de los tiempos en que la aplicación no se encuentra

 Puede pasar que reproducir un incidente reportado no dé el mismo resultado que al

 Se puede definir qué casos de prueba se van a ejecutar de acuerdo a varios

También podría gustarte