Mucho se ha hablado de cómo y en qué momento se debe probar, pero ¿y después de las pruebas? El verdadero valor de las pruebas está en sus resultados. Cuando los procesos y equipos de prueba solo tienen la intención de encontrar defectos y no la de prevenirlos, algo se está haciendo de forma incorrecta. Si un insecto se nos aparece lo aplastamos. Si un biólogo encuentra uno, lo examinará. El tester debe contar con ésta capacidad en el mundo del software y aprender de los defectos. El objetivo de la sesión es mostrar la importancia que tienen los 'bugs' en el camino a la calidad, y el deber que tienen las áreas involucradas en base al Proceso de Administración de Defectos: - Principales errores del tester tratando con defectos. - Principio 4 del testing: Agrupación de defectos. - Ciclo de vida de un defecto. - Severidad y Prioridad. - Mejores prácticas para la asignación y comprobación de resolución (re-test y regresión) - TMMi y la Prevención de Defectos. Semblanza del conferencista: Carlos González cuenta con amplia participación en proyectos de TI cubriendo ciclos de pruebas completos. Actualmente se desempeña como Test Specialist en IBM México donde ha contribuido en la implementación de procesos y metodologías de pruebas Apasionado por el Testing; creador de la iniciativa Latin America Software Testing (testingla.com) buscando establecer criterios sólidos para el desarrollo y madurez de las pruebas en México y Latinoamérica. Cuenta con la certificación otorgada por el ISTQB en fundamentos de pruebas.

1. Aprendiendo de nuestros
errores.
La verdadera importancia de
los Defectos de Software.
Carlos U. González
Tester / ISTQB FL

2. 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)

3. BUGS. CONOCIENDO
AL ENEMIGO
ES SOCIABLE
NO LE GUSTA SER
CONFUNDIDO
ADAPTABLE AL
MEDIO AMBIENTE
LOS RANGOS SON
IMPORTANTES PARA EL

4. - 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

5. 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

6. PRIORIDAD
1.- Alta
2.- Media
3.- Baja
Urgencia de corrección debido al daño
ocasionado en la funcionalidad

7. 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ó

8. PROCESO DE
ADMINISTRACIÓN
DE DEFECTOS
La mayoría de los
defectos son
causados ​​por fallas
en los procesos en
lugar de errores
humanos.

9. 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

10. 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

11. PRINCIPIO 4 DEL TESTING:
Agrupación de defectos

12. 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?
0
1
2
3
4
5
6
Defectos
Ocurrencia de defectos
Fase 1
Regresión
Fase 2

13. 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?

14. • 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?

15. 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?

16. • 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

17. TESTING Y PREVENCIÓN DE
DEFECTOS

18. ¿QUÉ
NECESITAMOS?

19. 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?)

20. 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)

21. Preguntas
@urielgk
cu.hs@hotmail.com
testingla.com