GESTIÓN DE DEFECTOS

Uno de los objetivos del Testing es encontrar defectos en el software.

Esto ocurre en diferentes etapas del ciclo de vida.

Es decir, puede ser en pruebas unitarias, en pruebas integrales, en pruebas del sistema, en el UAT y por supuesto lo
menos deseado en el ambiente productivo.

Evidentemente mientras más temprano se encuentre el defecto más sencillo será resolverlo y menor el costo que se
pague por él.

Es de considerar que en la jerga diaria, defectos o falla es lo mismo, por lo tanto estaremos tratándolo de la misma
manera.

Comencemos con la definición del ISTQB.

Específicamente aquí se está hablando de algún problema del código asociado al software o de que la configuración
de los datos o parámetros no son los correctos por lo que produce una falla.

Yendo a más, esta falla produce un desvío, un delta, una diferencia entre el resultado esperado y el resultado
obtenido.

Pero por otra parte y en términos generales vean cómo el IEEE1044 define ‘anomalía’.
¿Consideran entonces que un defecto también es una anomalía?

Este concepto, nos permite ver como detecciones tempranas producen mejores resultados que el enfoque sobre
desvíos.

DISEÑO DE DEFECTOS
Así como describimos en el capítulo anterior los pasos para diseñar casos de pruebas, aquí realizaremos lo mismo,
pero en este caso son solo seis (6), a saber:
Tengan en cuenta que el punto 5 establece claramente que debe ser ligado al caso de prueba que se está probando.

Ahora, puede ocurrir que simplemente se está ejecutando en Producción por lo cual se deberá asociarlo
directamente al requerimiento o caso uso o de desconocerlo agregarlo a la lista de defectos (sí, sin poder trazarlo
con un caso de prueba, pero considerando que el próximos requisito a probar establezca la revisión de ello).

El siguiente esquema muestra cómo se genera un desvío de una manera práctica: entradas-proceso-salida.

Simplemente la entrada es ‘resultado esperado’ y ‘resultado obtenido’l , el proceso es la ejecución del caso de
prueba. La salida es el ‘bugs’.
ESTRUCTURA DE UN DEFECTO
Así como un caso de prueba debe ser registrado con una documentación detallada que permita su trazabilidad y al
mismo tiempo simple de actualizar y de bajo costo de mantener; el defecto debe cumplir con las mismas reglas.

Así entonces enumeramos los campos que deben considerarse en un defecto:

Id: Identificador único para cada defecto (puede ser composición del caso de prueba con la numeración correlativa
del defecto)
Descripción: Título breve de cuál fue la falla.
Casuística: Referido a ‘datos’ necesarios para ejecutar llegar al defecto
Tipo de Defecto: Permite identificar a quien se derivara el mismo (software, ambientes, base de datos, red)
Prioridad: Relacionado a la importancia de TC (alta, media, baja)
Severidad: Relacionada a la criticidad del TC (de negocio, funcional, formal)
Ciclo: el ciclo que se está ejecutando
Pasos a ejecutar: Detalle a seguir para poder ejecutar el TC
Status: estado del defecto (abierto, en proceso, reasignado, cerrado)
Tester: persona que encontró el defecto
Asignado: persona a la que se le asignó la resolución del defecto
Fecha de ejecución
Id del TC: para la trazabilidad
Id del Caso de Uso: si es preciso para no perder la trazabilidad

Al describir los pasos o ‘step by step’ podemos asignar los pasos de TC o describirlo detalladamente indicando:
 ID del paso: puede ser la combinación mnemotécnica de ID Bugs + ID Step
Precondiciones: Condiciones a cumplir previa ejecución del paso
Descripción: Título breve, de qué se está haciendo
Status: estado del defecto
Resultado esperado: Descripción de lo debería verse
Resultado obtenido: Descripción de lo que realmente se obtuvo después de la ejecución del paso
Evidencia: print de la pantalla demostrando que se ha realizado el paso
Fecha de ejecución
Id del Defecto: para no perder la trazabilidad

Existen herramientas tecnológicas que simplifican el manejo, documentación, y mantenimiento de la registración.

TIPS
Apunta a cómo diseñar defectos de una manera simple y sencilla:

1. Sean conciso y preciso

2. Utilice un lenguaje claro, simple, entendible
3. Evite faltas de ortografía
4. Piense cómo lo podría repetir el desarrollador
5. Agregue evidencia (print-screen) útil y clara; esto no quiere decir que más evidencias es mejor
6. Asocie el defecto al caso de prueba (trazable)
7. Agregue los pasos del TC, si fuese necesario

Recuerde:

• Cuanto mejor sea la descripción del defecto, más confiable será su seguimiento.

• Un defecto BIEN diseñado, puede ser comprendido y ejecutado por cualquier otro colaborador del
equipo.

SEGUIMIENTO DE UN DEFECTO
Como comentábamos en el curso, el denominado bug-tracking o seguimiento de los defectos se puede establecer a
través de alguna herramienta informática.

Básicamente contempla los siguientes puntos:

CAUSA-RAÍZ DE LOS DEFECTOS
Por último es bueno tener en cuenta cuales son las posibles causas para anticiparse a las mismas.

Así como lo vimos en clase, les dejo los siguientes cuatro cuadros que tratan de esbosar la mayoría de ellas:
REGISTRACIÓN DE DEFECTOS
Una manera de registrar los defectos es utilizando planillas donde los campos de la estructura se muestran
organizadamente en columnas.

Planilla de defectos

ID del Tipo
Nombre / DescripciónEvidenciaStatusPrioridad (Severidad) CicloFecha detectadaResponsableAsignado a
Defecto