![Page 1: Aprendiendo de nuestros errores. La verdadera importancia de los defectos de software](https://reader034.vdocumento.com/reader034/viewer/2022052212/554fb0e1b4c90586258b512a/html5/thumbnails/1.jpg)
Aprendiendo de nuestros errores.
La verdadera importancia de los Defectos de Software.
Carlos U. González Tester / ISTQB FL
![Page 2: Aprendiendo de nuestros errores. La verdadera importancia de los defectos de software](https://reader034.vdocumento.com/reader034/viewer/2022052212/554fb0e1b4c90586258b512a/html5/thumbnails/2.jpg)
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)
![Page 3: Aprendiendo de nuestros errores. La verdadera importancia de los defectos de software](https://reader034.vdocumento.com/reader034/viewer/2022052212/554fb0e1b4c90586258b512a/html5/thumbnails/3.jpg)
BUGS. CONOCIENDO
AL ENEMIGO
ES SOCIABLE
NO LE GUSTA SER
CONFUNDIDO
ADAPTABLE AL
MEDIO AMBIENTE
LOS RANGOS SON
IMPORTANTES PARA EL
![Page 4: Aprendiendo de nuestros errores. La verdadera importancia de los defectos de software](https://reader034.vdocumento.com/reader034/viewer/2022052212/554fb0e1b4c90586258b512a/html5/thumbnails/4.jpg)
- 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
![Page 5: Aprendiendo de nuestros errores. La verdadera importancia de los defectos de software](https://reader034.vdocumento.com/reader034/viewer/2022052212/554fb0e1b4c90586258b512a/html5/thumbnails/5.jpg)
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
![Page 6: Aprendiendo de nuestros errores. La verdadera importancia de los defectos de software](https://reader034.vdocumento.com/reader034/viewer/2022052212/554fb0e1b4c90586258b512a/html5/thumbnails/6.jpg)
PRIORIDAD
1.- Alta
2.- Media
3.- Baja
Urgencia de corrección debido al daño
ocasionado en la funcionalidad
![Page 7: Aprendiendo de nuestros errores. La verdadera importancia de los defectos de software](https://reader034.vdocumento.com/reader034/viewer/2022052212/554fb0e1b4c90586258b512a/html5/thumbnails/7.jpg)
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ó
![Page 8: Aprendiendo de nuestros errores. La verdadera importancia de los defectos de software](https://reader034.vdocumento.com/reader034/viewer/2022052212/554fb0e1b4c90586258b512a/html5/thumbnails/8.jpg)
PROCESO DE ADMINISTRACIÓN DE DEFECTOS
La mayoría de los defectos son
causados por fallas en los procesos en
lugar de errores humanos.
![Page 9: Aprendiendo de nuestros errores. La verdadera importancia de los defectos de software](https://reader034.vdocumento.com/reader034/viewer/2022052212/554fb0e1b4c90586258b512a/html5/thumbnails/9.jpg)
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
![Page 10: Aprendiendo de nuestros errores. La verdadera importancia de los defectos de software](https://reader034.vdocumento.com/reader034/viewer/2022052212/554fb0e1b4c90586258b512a/html5/thumbnails/10.jpg)
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
![Page 11: Aprendiendo de nuestros errores. La verdadera importancia de los defectos de software](https://reader034.vdocumento.com/reader034/viewer/2022052212/554fb0e1b4c90586258b512a/html5/thumbnails/11.jpg)
PRINCIPIO 4 DEL TESTING: Agrupación de defectos
![Page 12: Aprendiendo de nuestros errores. La verdadera importancia de los defectos de software](https://reader034.vdocumento.com/reader034/viewer/2022052212/554fb0e1b4c90586258b512a/html5/thumbnails/12.jpg)
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
![Page 13: Aprendiendo de nuestros errores. La verdadera importancia de los defectos de software](https://reader034.vdocumento.com/reader034/viewer/2022052212/554fb0e1b4c90586258b512a/html5/thumbnails/13.jpg)
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?
![Page 14: Aprendiendo de nuestros errores. La verdadera importancia de los defectos de software](https://reader034.vdocumento.com/reader034/viewer/2022052212/554fb0e1b4c90586258b512a/html5/thumbnails/14.jpg)
• 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?
![Page 15: Aprendiendo de nuestros errores. La verdadera importancia de los defectos de software](https://reader034.vdocumento.com/reader034/viewer/2022052212/554fb0e1b4c90586258b512a/html5/thumbnails/15.jpg)
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?
![Page 16: Aprendiendo de nuestros errores. La verdadera importancia de los defectos de software](https://reader034.vdocumento.com/reader034/viewer/2022052212/554fb0e1b4c90586258b512a/html5/thumbnails/16.jpg)
• 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
![Page 17: Aprendiendo de nuestros errores. La verdadera importancia de los defectos de software](https://reader034.vdocumento.com/reader034/viewer/2022052212/554fb0e1b4c90586258b512a/html5/thumbnails/17.jpg)
TESTING Y PREVENCIÓN DE DEFECTOS
![Page 18: Aprendiendo de nuestros errores. La verdadera importancia de los defectos de software](https://reader034.vdocumento.com/reader034/viewer/2022052212/554fb0e1b4c90586258b512a/html5/thumbnails/18.jpg)
¿QUÉ NECESITAMOS?
![Page 19: Aprendiendo de nuestros errores. La verdadera importancia de los defectos de software](https://reader034.vdocumento.com/reader034/viewer/2022052212/554fb0e1b4c90586258b512a/html5/thumbnails/19.jpg)
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?)
![Page 20: Aprendiendo de nuestros errores. La verdadera importancia de los defectos de software](https://reader034.vdocumento.com/reader034/viewer/2022052212/554fb0e1b4c90586258b512a/html5/thumbnails/20.jpg)
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)