Diseñar buenos casos de prueba es importante, pero el valor del testing aparece cuando esos casos se ejecutan, se observan resultados y se registra información útil para el equipo.
La ejecución de pruebas consiste en realizar las verificaciones planificadas o exploratorias, comparar el resultado obtenido con el resultado esperado y documentar el estado de cada prueba.
Registrar resultados con claridad permite saber qué se probó, qué pasó, qué falló, qué quedó bloqueado y qué riesgos siguen pendientes.
Antes de comenzar la ejecución conviene revisar que estén dadas las condiciones necesarias. De lo contrario, se puede perder tiempo con bloqueos evitables.
Checklist básico:
Una ejecución ordenada empieza antes de presionar el primer botón.
Ejecutar una prueba no es solo seguir pasos. Implica observar, comparar y decidir.
La observación es clave. A veces el resultado principal es correcto, pero aparecen mensajes, demoras o comportamientos secundarios que también deben analizarse.
Durante la ejecución, siempre debemos distinguir entre:
Ejemplo:
Esta diferencia es la base para decidir si el caso aprueba, falla o requiere análisis adicional.
Los estados ayudan a comunicar el avance y resultado de las pruebas. Los más comunes son:
| Estado | Significado |
|---|---|
| Aprobado | El resultado obtenido coincide con el resultado esperado. |
| Fallido | El resultado obtenido no coincide con el resultado esperado. |
| Bloqueado | No se pudo ejecutar por una condición externa al caso. |
| No ejecutado | La prueba aún no fue realizada. |
| No aplica | El caso no corresponde para esa versión, configuración o alcance. |
Usar estados consistentes evita confusiones al informar avances.
Una prueba se marca como aprobada cuando el resultado obtenido coincide con el resultado esperado y no se observan diferencias relevantes.
Ejemplo:
Si todo coincide con lo esperado, el caso puede aprobarse. Si aparece un comportamiento secundario dudoso, conviene registrarlo o consultarlo antes de aprobar sin análisis.
Una prueba se marca como fallida cuando el comportamiento observado no coincide con el esperado.
Ejemplos:
Cuando un caso falla, normalmente corresponde registrar una incidencia con información suficiente para reproducir el problema.
Una prueba está bloqueada cuando no puede ejecutarse por una condición externa a lo que se quiere probar.
Ejemplos:
Bloqueado no significa aprobado ni fallido. Significa que no se pudo obtener información válida sobre ese caso.
La evidencia ayuda a respaldar lo observado. Puede ser necesaria especialmente en fallas, pruebas críticas, auditorías o validaciones de aceptación.
Ejemplos de evidencia:
La evidencia debe ser útil y suficiente. No siempre hace falta capturar todo, pero sí lo necesario para entender el resultado.
Un registro de ejecución puede incluir:
Este registro permite reconstruir qué ocurrió y ayuda a tomar decisiones sobre la versión.
| Caso | CP-LOGIN-002 |
|---|---|
| Objetivo | Rechazar inicio de sesión con contraseña incorrecta. |
| Ambiente | QA - versión 2.4.0 |
| Datos usados | usuario.activo@correo.com / contraseña incorrecta |
| Resultado esperado | Mostrar mensaje "Correo o contraseña incorrectos". |
| Resultado obtenido | El sistema muestra "Error interno del servidor". |
| Estado | Fallido |
| Incidencia | DEF-238 |
El registro de resultados aplica tanto a pruebas manuales como automatizadas.
En pruebas manuales, una persona registra estado, observaciones y evidencias. En pruebas automatizadas, la herramienta suele generar reportes con casos pasados, fallidos, tiempos de ejecución, errores y capturas o logs.
En ambos casos, el resultado necesita interpretación. Una prueba automatizada fallida puede indicar un defecto real, un problema de ambiente, datos incorrectos o una prueba desactualizada.
El retesting consiste en volver a ejecutar una prueba que falló después de que el defecto fue corregido.
Ejemplo:
Re-ejecutar confirma que el problema reportado fue resuelto.
Además de reprobar el caso fallido, puede ser necesario ejecutar pruebas de regresión. Una corrección puede resolver un defecto y romper otra funcionalidad relacionada.
Ejemplo: se corrige el rechazo de contraseña incorrecta. Luego conviene validar también:
La regresión se define según impacto y riesgo del cambio.
A veces el resultado no es claramente aprobado ni fallido. Puede haber ambigüedad en el requisito, datos incompletos o comportamiento no documentado.
En esos casos conviene:
Un resultado dudoso puede revelar una falla en la documentación, no necesariamente en el código.
Durante una ejecución, el equipo necesita conocer el avance. Un reporte simple puede incluir:
El reporte no debe limitarse a porcentajes. También debe explicar riesgos relevantes para decidir.
| Suite | Regresión de compra |
|---|---|
| Total de casos | 40 |
| Ejecutados | 35 |
| Aprobados | 30 |
| Fallidos | 3 |
| Bloqueados | 2 |
| No ejecutados | 5 |
| Riesgo principal | Dos casos de pago bloqueados por indisponibilidad del sandbox. |
Este resumen combina números con contexto, lo cual ayuda mucho más que un porcentaje aislado.
Al ejecutar pruebas y registrar resultados, algunos errores frecuentes son:
Para ejecutar y registrar mejor conviene:
La ejecución de pruebas transforma los casos diseñados en información concreta sobre el producto. Pero esa información solo es útil si se registra con claridad: qué se probó, en qué ambiente, con qué datos, qué se esperaba y qué ocurrió.
Un buen registro permite reproducir defectos, medir avance, tomar decisiones y mantener trazabilidad. Ejecutar sin registrar correctamente reduce el valor del testing.
En el próximo tema estudiaremos cómo reportar defectos con información mínima y claridad, para que el equipo pueda entenderlos, reproducirlos y corregirlos de manera eficiente.