Gestión de defectos sin sobrecostos
Clase 22 de 29 • Curso de Fundamentos de Pruebas de Software
Contenido del curso
Principios de las pruebas
- 2

Por qué el testing moderno previene errores
09:26 min - 3

Pruebas de software en cada etapa del desarrollo
06:51 min - 4
Pruebas en el Ciclo de Vida del Software: Mejora y Optimización
01:35 min - 5

Anomalía vs defecto vs fallo vs error
10:04 min - 6

Los siete principios del testing moderno
11:43 min - 7

Roles de testing especializados y tu path de crecimiento
12:18 min
Testing
- 8

Testing en cada fase del desarrollo
13:19 min - 9

Mapas mentales para estrategias de testing
09:10 min - 10

Testing vs checking en automatización de pruebas
10:53 min - 11

Testing ágil: todo el equipo prueba
08:03 min - 12

Niveles de pruebas: componentes a sistema
05:11 min - 13

Tipos de pruebas de software explicados
04:42 min - 14

Pruebas estáticas vs dinámicas en testing
10:01 min - 15

Cómo diseñar casos de prueba efectivos
13:10 min
Gestión, monitoreo y control
Gestión de bugs
Depuración
Bases de la automatización de pruebas
Una gestión de defectos clara evita cuellos de botella, retrabajo y sobrecostos. Aquí se explica, paso a paso, cómo estructurar el proceso de books (defectos): desde el reporte y los estados hasta el control de permisos, con foco en evidencias mínimas y decisiones clave para no desviarse en tiempo y presupuesto.
¿Cómo gestionar books (defectos) para evitar sobrecostos?
La administración deficiente y la falta de seguimiento generan retrabajo y mala documentación, lo que puede sacar al proyecto de presupuesto y tiempo. La clave es establecer un proceso con evidencias, criterios de estatus y responsables claros.
¿Por qué aparecen los defectos?
- Cambios de requerimientos y falta de tiempo en iteraciones ágiles.
- Trabajo modular con cabos sueltos que generan fallos.
- Diseño de código que crece y se vuelve complejo.
- Rotación de personal y curva de aprendizaje en productos maduros.
- Equipo con información insuficiente para gestionar sus actividades.
¿Qué documentar como evidencia mínima?
- Descripción clara y contraria a los análisis o requerimientos establecidos.
- Evidencias mínimas: pasos, datos usados y entorno.
- Impacto esperado en el flujo principal y a nivel componente.
- Criterios para saber si está resuelto, quién lo tiene y quién debe aprobar.
- Fecha objetivo y visibilidad en un monitor o dashboard.
¿Qué decisiones definen el proceso?
- ¿Qué hacer cuando algo no cumple los requerimientos?
- ¿Cuánta información es necesaria documentar?
- ¿Cómo se aprueba la reparación y quién decide su prioridad e iteración?
¿Cuál es el flujo de estados y el retrabajo en la gestión?
El ciclo inicia cuando se reporta el defecto y pasa a abierto tras revisión. Si se decide repararlo en esta u otra iteración, se asigna a un desarrollador; cuando termina, pasa a arreglado. Con una confirmación exitosa de pruebas, se marca cerrado.
¿Qué estados clave existen?
- Reportado: registrado con evidencias mínimas.
- Abierto: revisado y validado para gestión.
- Asignado: tiene dueño para su reparación.
- Arreglado: el desarrollador indica que concluyó.
- Cerrado: el equipo de pruebas confirma la corrección.
¿Cuándo reabrir, rechazar o diferir?
- Rechazado: cuando no es un problema real; se trata como sugerencia.
- Diferido: se declina reparar ahora y se pospone a otra iteración por prioridad.
- Reabierto: falla la prueba de confirmación o reaparece por nuevas plataformas, nuevos exploradores o datos distintos.
- Análisis de impacto: identifica áreas afectadas más allá del error visible.
¿Cómo crece el retrabajo y por qué importa?
- Reporte mal hecho: se rechaza, se reescribe y se reabre, sumando pasos.
- Discusión sobre si entra en la iteración: añade espera y más puntos.
- Olvido de contexto en la siguiente iteración: obliga a rehacer o rechazar.
- Malas prácticas: marcar como arreglado sin reparar; QA lo detecta y vuelve a asignarse.
- Métrica ilustrativa del flujo: un camino exitoso puede cerrar en cuatro pasos; con retrabajo, los puntos se acumulan (tres, cuatro, cinco, seis, siete, ocho…) y pueden crecer indefinidamente si no se corrige la forma de trabajar.
¿Quién define responsabilidades y permisos en el proceso?
Para una gestión correcta, se deben asignar responsabilidades y permisos: quién puede cambiar estados y quién aprueba cada transición, evitando cambios no controlados que introducen nuevos defectos.
¿Cómo controlar estados y aprobaciones?
- Definir quién cambia de abierto a asignado y a arreglado.
- Validación previa del líder de desarrollo: revisar que no se inyecten nuevos defectos, se cumplan prácticas de código y no haya cambios no solicitados.
- Confirmación por el equipo de pruebas antes de cerrar.
¿Cómo evitar cambios no comunicados?
- Generar un nuevo ticket ante hallazgos adicionales, no modificar en silencio.
- Notificar al equipo para prevenir impactos en otras áreas.
- Mantener trazabilidad: quién cambió, qué cambió y por qué.
¿Tú cómo implementarías la gestión de defectos en tu equipo? Comparte en comentarios tus pasos, experiencias y dudas para ayudarte con más tips prácticos.