// SOFTWARE
Prueba del testing: por qué una captura no basta
6 min de lecturanijitech
Lo más discutido de un informe de pruebas no es el error encontrado sino si la prueba se ejecutó de verdad. Una captura de pantalla no lo demuestra; un registro de ejecución sí.
Artículo completo
Se entrega el informe, el cliente se atasca en un escenario y la misma pregunta llega a la mesa: «¿esto se probó de verdad?». Si no hay más que una captura de pantalla, la respuesta queda en manos de la memoria. El tester cuenta lo que hizo, el cliente no se convence; los dos tienen razón, porque ninguno tiene pruebas.
Este artículo explica cómo desaparece esa discusión. La respuesta no son más capturas; es un registro de qué se ejecutó, en qué entorno y cuándo, guardado de una forma que no puede editarse después.
Qué demuestra una captura y qué no
Una captura de pantalla muestra un instante: esa pantalla se veía así en ese momento. No dice en qué versión, en qué dispositivo ni tras qué pasos se tomó. Puede recortarse, editarse o sacarse de otra sesión. Sirve cuando se encuentra un error; no muestra que los veinte escenarios sin error se probaron de verdad.
Cuatro preguntas que debe responder una evidencia de prueba
- En qué entorno se ejecutó: sistema operativo, versión, dispositivo, navegador, firmware
- Qué escenario empezó cuándo y terminó cuándo
- Si los archivos adjuntos (registros, grabación de pantalla) cambiaron después
- Quién escribió el registro y cuándo; si puede editarse
El registro de ejecución: guardar tres cosas a la vez
La solución es sacar el registro de manos humanas. Un agente que corre en la máquina del tester toma la huella del entorno, escribe la marca de inicio y fin de cada escenario y guarda un resumen (hash) de cada archivo adjunto. El tester añade capturas, registros y pasos de reproducción; todo sale en un solo paquete.
El punto crítico es la inalterabilidad. Si ni el tester ni la plataforma pueden editar el registro después, un informe rechazado se discute sobre el registro, no sobre lo que cada uno recuerda. La reclamación mira el mismo registro; al tester que tiene razón se le paga.
Independencia: quien encuentra y quien corrige no deben ser la misma parte
El equipo que escribe el producto no puede probarlo con imparcialidad; no es un defecto, es la naturaleza de las cosas. El desarrollador sabe cómo debe funcionar el flujo y lo sigue sin darse cuenta. El usuario no lo sabe y va por otro camino. Por eso las pruebas independientes no son solo «que mire alguien de fuera»: cuando la parte que encontró el hallazgo también verifica la corrección, sin ser la que la hizo, la verificación es realmente independiente.
Por qué el cupo forma parte de la prueba
La competencia invisible es la gemela del trabajo invisible. Si el número de testers que admite un trabajo está escrito de antemano, el tester dedica su tiempo sabiendo con cuántos compite; cuando el cupo se llena, el trabajo sale de la lista. Si la tarifa también es fija de antemano y no cambia con el número de errores encontrados, un trabajo con cero errores también se paga: lo que se paga no es el error sino que los escenarios se ejecutaron.
Resumen
Cuatro condiciones para un testing con evidencia
- Una captura de pantalla es evidencia de un error, no de una prueba
- Entorno, marcas de tiempo y resúmenes de archivos los escribe un agente y nunca cambian
- Quien encuentra, quien corrige y quien verifica no son la misma parte
- Cupo y tarifa están escritos de antemano; las reclamaciones van sobre el registro
Productos mencionados en este artículo
Del glosario: Conjunto de evaluación (eval) · Decisión aprobada por humanos (human-in-the-loop)