Las pruebas de software aportan información sobre calidad y riesgo. Dentro de ese contexto, dos conceptos son fundamentales: verificación y validación. Además, cuando se encuentran problemas, el equipo necesita gestionarlos de manera ordenada mediante una buena gestión de defectos.
Verificar y validar ayudan a responder si el sistema fue construido correctamente y si realmente resuelve la necesidad. Gestionar defectos ayuda a registrar, priorizar, corregir y aprender de los problemas encontrados.
En este tema veremos cómo se conectan estas actividades y por qué son importantes para la Ingeniería de Software.
La verificación busca comprobar si el software, los documentos o los componentes fueron construidos de acuerdo con lo especificado. Responde a la pregunta: ¿estamos construyendo correctamente el producto?
Ejemplos de verificación:
La validación busca comprobar si el software resuelve la necesidad real del usuario o del negocio. Responde a la pregunta: ¿estamos construyendo el producto correcto?
Ejemplos de validación:
La validación es esencial porque un sistema puede cumplir la especificación y aun así no resolver el problema correcto.
| Aspecto | Verificación | Validación |
|---|---|---|
| Pregunta | ¿Construimos correctamente lo especificado? | ¿Construimos lo que realmente se necesita? |
| Referencia | Requisitos, diseño, estándares, criterios técnicos. | Necesidades de usuarios, objetivos de negocio, contexto real. |
| Ejemplo | La reserva se cancela según la regla de dos horas. | El flujo de cancelación resulta comprensible para usuarios reales. |
| Participantes | Equipo técnico, testers, revisores. | Usuarios, clientes, referentes de negocio y equipo. |
Estas actividades pueden aparecer durante todo el ciclo de vida del software.
No todo se verifica con pruebas ejecutables. Algunas verificaciones se realizan revisando documentos, modelos, código o decisiones.
Un defecto es un problema en el producto, código, configuración, diseño, documentación o datos que puede provocar un comportamiento incorrecto o indeseado.
Ejemplos de defectos:
Los defectos no siempre están en el código. También pueden estar en requisitos, documentación, datos, configuración o procesos.
La gestión de defectos es el proceso de registrar, analizar, priorizar, corregir, verificar y cerrar defectos. Su objetivo es que los problemas encontrados no se pierdan y puedan tratarse según su impacto.
Incluye actividades como:
Un buen reporte de defecto debe permitir comprender el problema y, si es posible, reproducirlo. Cuanta más clara sea la información, más rápido podrá analizarse.
| Título | Resumen claro del problema. |
|---|---|
| Descripción | Qué ocurre y por qué se considera incorrecto. |
| Pasos para reproducir | Secuencia de acciones que permite observar el problema. |
| Resultado esperado | Qué debería ocurrir. |
| Resultado obtenido | Qué ocurrió realmente. |
| Ambiente | Navegador, versión, sistema, datos o configuración relevante. |
| Evidencia | Captura, video, log, identificador de operación o archivo relacionado. |
| Impacto | Qué usuarios, funciones o procesos se ven afectados. |
La severidad y la prioridad no significan lo mismo.
| Concepto | Qué indica | Ejemplo |
|---|---|---|
| Severidad | Impacto técnico o funcional del defecto. | El sistema permite cobrar un importe incorrecto. |
| Prioridad | Urgencia con la que debe corregirse. | Debe corregirse antes de publicar la versión. |
Un defecto puede tener alta severidad pero baja prioridad si ocurre en una función que no se usará en la próxima entrega. También puede tener baja severidad pero alta prioridad si afecta una demostración o mensaje visible importante.
Un defecto suele pasar por distintos estados. Los nombres pueden variar según la herramienta o el equipo, pero un flujo simple es:
También pueden existir estados como:
Ejemplo para un sistema de reservas:
| Título | El sistema permite reservar dos veces el mismo horario. |
|---|---|
| Pasos | Ingresar con dos usuarios, seleccionar el mismo horario disponible y confirmar ambas reservas casi al mismo tiempo. |
| Resultado esperado | Solo una reserva debe confirmarse; la segunda debe informar que el horario ya no está disponible. |
| Resultado obtenido | Ambas reservas quedan confirmadas para el mismo horario. |
| Impacto | Puede generar sobreventa de cupos y conflictos operativos. |
| Severidad | Alta. |
| Prioridad | Alta si la funcionalidad será publicada en la próxima entrega. |
Cuando un defecto se corrige, debe verificarse que la corrección funciona. Esta verificación no debería limitarse al caso exacto reportado si existen riesgos relacionados.
Conviene revisar:
Una regresión ocurre cuando algo que antes funcionaba deja de funcionar por un cambio reciente. Por eso, al corregir un defecto conviene agregar pruebas que eviten que el mismo problema vuelva a aparecer.
Ejemplo:
La gestión de defectos no solo corrige problemas actuales; también ayuda a prevenir repetición.
Cuando un defecto es grave o se repite, conviene analizar su causa raíz. La pregunta no es solo "¿qué línea de código falló?", sino "¿por qué el defecto llegó hasta aquí?".
Posibles causas:
Analizar causas permite mejorar el proceso, no solo corregir síntomas.
Las métricas deben usarse con cuidado, pero pueden aportar información útil.
Las métricas no deben usarse para culpar personas. Deben ayudar a entender riesgos, calidad y oportunidades de mejora.
Varias personas pueden participar:
La gestión de defectos funciona mejor cuando el equipo colabora en lugar de tratar el defecto como un problema de un solo rol.
Al gestionar defectos suelen aparecer errores como:
Algunas buenas prácticas son:
Verificación, validación y gestión de defectos son prácticas centrales para construir software con mayor calidad. Permiten comprobar cumplimiento, validar utilidad real y tratar los problemas encontrados de forma ordenada.
Para quien comienza, la idea principal es esta: un defecto bien gestionado no solo se corrige; también deja información útil para mejorar el producto, las pruebas y el proceso de desarrollo.
En el próximo tema veremos calidad del producto software y atributos de calidad, ampliando la mirada más allá de defectos funcionales hacia características generales del producto.