Guarda las pruebas del fallo antes de repetir el test
La última captura no muestra todo el camino hasta el fallo. Guarda la secuencia, el contexto de red y la comprobación antes de repetir la prueba.
Edición traducida. Los identificadores técnicos permanecen en su forma original.
Una prueba ilustrativa abre una página de configuración, envía un cambio y falla porque el valor esperado nunca aparece. Alguien publica la última captura de pantalla. Muestra un panel vacío. ¿El usuario cerró sesión? ¿Falló la solicitud de guardado? ¿La comprobación se realizó contra el registro equivocado? La imagen por sí sola no puede responder a esas preguntas.
El fracaso de una prueba es una secuencia, no una fotografía. Este artículo propone un pequeño paquete de evidencia que un ingeniero o desarrollador de control de calidad puede leer sin repetir toda la exploración. El objetivo es reducir las investigaciones evitables, no recopilar todos los bytes posibles ni prometer un diagnóstico automático.
Comienza con la acción y su contexto.
Trace Viewer de Playwright le permite inspeccionar un seguimiento de prueba grabado con una línea de tiempo de acción e instantáneas asociadas. Su documentación describe el examen de la fuente, los errores, la salida de la consola y la actividad de la red. Esas vistas responden a diferentes preguntas: qué intentó la prueba, qué mostró la página y qué intercambió la aplicación. Una captura de pantalla sigue siendo útil, pero es una vista dentro de un paquete más grande.
Registre el identificador de la prueba, la revisión del código, el entorno, la función de la cuenta inicial y la comprobación que falló. Describe el estado esperado en palabras sencillas. Mantenga los secretos fuera de la descripción. La evidencia debe decir qué función de prueba se utilizó, no publicar una cookie de sesión o la identidad de un cliente real.
El traspaso de cinco campos
Utilice cinco campos para cada error: resultado esperado, resultado real, primer paso fallido, ubicación del rastro o artefacto y condiciones de reproducción. En resultado real, distinga una respuesta de error recibida de una ausencia de contenido visible. Bajo condiciones, tenga en cuenta el registro sembrado relevante y si una prueba paralela podría haberlo cambiado.
No permita que la explicación de un agente reemplace la evidencia original. Una narrativa segura es una hipótesis hasta que el registro de acciones o el estado de la aplicación la respalda. Marque las causas sospechosas como sospechosas. Si el artefacto no está disponible, indique esa brecha en lugar de escribir una secuencia plausible a partir de la captura de pantalla final.
Este formato ayuda a ambos tipos de equipo. Un líder de control de calidad obtiene una transferencia revisable en lugar de un muro de texto generado. Una empresa sin un ingeniero de control de calidad dedicado recibe un incidente que otro desarrollador puede detectar después de que el evaluador original abandona el escritorio. Ninguno de los dos requiere una causa raíz ficticia para parecer completo.
Elija cuándo recopilar un seguimiento
Las opciones de prueba de Playwright documentan los modos de rastreo, incluida la retención de un rastreo en caso de falla y la grabación en el primer reintento. La elección importa. Un seguimiento de primer reintento registra el intento posterior, que puede comportarse de manera diferente al error original. Si se necesita evidencia del primer intento para un flujo crítico, no asuma que una grabación de solo reintento la contiene.
Elija una política de artefactos para cada clase de riesgo y verifique que realmente produzca el archivo necesario. Capturar cada ejecución puede costar tiempo y almacenamiento. Captar muy poco puede costar una investigación. Mida esos costos en su suite en lugar de adoptar una regla universal de una demostración.
Protege el paquete antes de compartirlo
Los seguimientos y las capturas de pantalla pueden contener contenido de la página y detalles de la solicitud. Utilice datos provisionales sintéticos, limite el acceso a los artefactos y establezca una ventana de retención. Revise el contenido real antes de compartir un rastro fuera del equipo. Eliminar un nombre de archivo que parece confidencial no elimina la sesión ni los datos personales dentro del archivo.
La página pública de AnyTest describe las observaciones en cada paso y los motivos del fracaso. Este es un contexto útil del producto, pero no es una comprobación de que su resultado sea idéntico a un trazo de Playwright. Mantenga separados los formatos de evidencia del proveedor y verifique lo que realmente conserva el corredor elegido.
Mida la investigación, no el recuento de capturas de pantalla
Durante una prueba piloto, registre los minutos desde la primera falla hasta una descripción reproducible y luego hasta una causa confirmada. Separe el tiempo dedicado a buscar los artefactos faltantes del tiempo dedicado a reparar el producto. Agentic QA ahorra tiempo de investigación solo si la evidencia es utilizable y el revisor puede confiar en su procedencia. Un paquete más pequeño que responda a la pregunta es mejor que un archivo grande que nadie abre.
Preguntas comunes
¿Es suficiente una captura de pantalla para depurar un error de un extremo a otro?
A veces, pero normalmente no puede mostrar las acciones anteriores o el contexto de la red. Un seguimiento y una comprobación fallida explícita pueden proporcionar la secuencia que falta.
¿El seguimiento del primer reintento contiene el error original?
Registra el primer intento de reintento. Ese intento puede diferir del fracaso original, así que elija la configuración de seguimiento según la evidencia que necesita.
¿Pueden los rastros de prueba contener datos privados?
Sí. Las instantáneas de páginas y los detalles de la red pueden exponer contenido privado. Utilice datos provisionales, restrinja el acceso, verifique el contenido y establezca límites de retención.