Aprendiendo de nuestros errores.

La verdadera importancia de los Defectos de Software.

Carlos U. González Tester / ISTQB FL

Error: Acción humana

que produce resultados

incorrectos

Defecto: Desperfecto causante del mal desempeño en un sistema

Error

Defecto

Fallo Proyectos

caídos

desarrollo testing cliente Líderes, PM’s (todos)

BUGS. CONOCIENDO

AL ENEMIGO

ES SOCIABLE

NO LE GUSTA SER

CONFUNDIDO

ADAPTABLE AL

MEDIO AMBIENTE

LOS RANGOS SON

IMPORTANTES PARA EL

- Abierto

- Rechazado

- En Reparación

- Cerrado

- No Resuelto

CICLO DE VIDA DE LOS DEFECTOS

El número de estados dependerá de la definición para cada proyecto

El número de estados y el proceso deben ser lo más ligero y ágil posible

Solo un tester debe cerrar defectos

SEVERIDAD

1.- Crítico

2.- Medio

3.- Menor

Impacto dentro del sistema o producto que

impide el correcto funcionamiento de los

flujos tanto principales como alternos

PRIORIDAD

1.- Alta

2.- Media

3.- Baja

Urgencia de corrección debido al daño

ocasionado en la funcionalidad

ASIGNACIÓN PARA LA RESOLUCIÓN DE DEFECTOS

IEEE 829

Datos de Incidencia (Identificador, versión de

aplicación, entorno, Autor, Fecha)

Clasificación (severidad, estado, prioridad)

Descripción (caso de prueba, resultado del

defecto, resultado esperado, informe, captura de

pantalla, pasos ejecutados)

El Reporte describe al defecto ¿cómo es? ¿Dónde

se vio? ¿qué daño causa? ¿en qué momento se

dio?

NO describe que lo causó

PROCESO DE ADMINISTRACIÓN DE DEFECTOS

La mayoría de los defectos son

causados por fallas en los procesos en

lugar de errores humanos.

1.- El objetivo principal es la PREVENCIÓN

DE DEFECTOS y no la DETECCIÓN de los mismos.

2.- Encontrar los defectos LO MÁS PRONTO POSIBLE Y MINIMIZAR SUS IMPACTOS

3. Las estrategias, prioridades y soluciones deben enfocarse en la REDUCCIÓN DE RIESGOS del proyecto

4.- A pesar de su clasificación, TODOS los defectos son importantes

PRINCIPIOS

La mayoría de los errores ocurren en un pequeño número de funciones probadas

El 80% de los defectos se generan por el 20% de las módulos, causas, procesos, etc.

PRINCIPIO 4 DEL TESTING: Agrupación de defectos y Principio de Pareto

PRINCIPIO 4 DEL TESTING: Agrupación de defectos

Identificar y analizar las causas comunes de defectos de todo el ciclo de vida y tomar medidas para evitar más defectos por las mismas razones

PREVENCIÓN DE DEFECTOS ¿Qué hacer?

0123456

Defe

cto

s

Ocurrencia de defectos

Fase 1

Regresión

Fase 2

Selección de defectos a analizar de acuerdo a:

- RIESGO

- VALOR AGREGADO

(costos, importancia, mantenimiento)

¡La selección de análisis de defectos se realiza junto con los interesados en el proyecto!

PREVENCIÓN DE DEFECTOS ¿cómo hacerlo?

• El daño de un defecto sobre el sistema

• La frecuencia de ocurrencia de defectos

• El esfuerzo que se necesita para reparar el defecto

• Una estimación del esfuerzo que se necesita para evitar que el

defecto vuelva a ocurrir

• Los costos de reproceso del defecto

• La medida en que el defecto tiene un impacto negativo en el

rendimiento del proceso

PREVENCIÓN DE DEFECTOS ¿qué parámetros usar?

1. Causa raíz de los defectos ¿qué nos llevó a tener estos defectos?

(cambios de requerimientos, malinterpretaciones, declaraciones erróneas de variables, condiciones no contempladas)

2. Causas comunes de los defectos ¿en que categoría se dieron los defectos?

(procesos, requerimientos, diseño, codificación, comunicación, competencias del personal)

PREVENCIÓN DE DEFECTOS ¿cómo analizar?

• Contribución a la organización

• Impacto y coste

• Consecuencias de no atender los defectos

• Impacto esperado en la calidad

PREVENCIÓN DE DEFECTOS Definir Acciones y Estrategias

TESTING Y PREVENCIÓN DE DEFECTOS

¿QUÉ NECESITAMOS?

PRINCIPALES ERRORES DEL TESTER TRATANDO CON DEFECTOS

1. No darle seguimiento a los defectos levantados de acuerdo a severidad y prioridad 2. No dar el camino de reproducción del defecto (pérdida de tiempo para desarrollo) 3. Omitir detalles importantes sobre el defecto (¿qué severidad?, ¿en que ambiente fue?)

PRINCIPALES ERRORES DEL TESTER TRATANDO CON DEFECTOS

4. Hacerle caso a los desarrolladores! (los defectos solo pueden ser cerrados por testers, con la información y elementos reales)

5. ¡ser solo un tester! (un tester debe dar visión del estado de calidad del proyecto en general)

Preguntas

@urielgk cu.hs@hotmail.com

testingla.com