3 min de lectura

Reglas de fallo para resultados visuales incorrectos

RenderLog puede fallar una ejecución si el navegador llega a una verificación, CAPTCHA, inicio de sesión o selector ausente.

pruebas web sin códigoreglas de fallo
En esta página

Úsalo cuando

  • Muro de login en lugar de la página esperada.
  • Desafío o CAPTCHA antes de que el navegador llegue al contenido.
  • Selector ausente que demuestra que la página no cargó como debía.
Reglas de fallo para resultados visuales incorrectos

Las malas ejecuciones deben fallar pronto y no fingir que pasan

Una página bloqueada no es una página correcta. Si la ejecución cae en un muro de login, un CAPTCHA, una pantalla de desafío, un selector ausente o directamente en la vista equivocada, el resultado debe fallar como estado erróneo y no entrar en el historial normal como si nada.

Eso protege tanto las referencias visuales como el historial de aserciones. De lo contrario una página rota puede convertirse en un resultado aceptado o generar revisión inútil sobre una captura que nunca llegó al estado real.

Dónde importan más las reglas de fallo

Estas reglas importan sobre todo en páginas donde una captura limpia puede engañar: checkout, registro, documentación detrás de protecciones, páginas localizadas o flujos que dependen de cookies y esperas.

Cuanto más contexto necesite una página antes de ser revisable, más importante es hacer fallar los estados erróneos en vez de obligar a interpretar la imagen final.

Define el primer conjunto de reglas antes de confiar en el historial

Define primero los bloqueos obvios: selector ausente, muro de login, página de desafío o paso roto del flujo. Añade reglas más específicas solo donde la página realmente las necesite.

Así el historial se mantiene honesto. No se trata de construir un motor enorme de reglas sino de impedir que estados claramente erróneos parezcan resultados válidos.

Enlaces relacionados

Preguntas frecuentes

¿Por qué no revisar simplemente la captura a mano?
Porque las capturas en estado erróneo desperdician tiempo de revisión y pueden terminar como historial aceptado si el fallo no se marca con claridad.
¿Qué deberían cubrir las primeras reglas de fallo?
Empieza por los estados que demuestran claramente que el navegador nunca llegó a la página prevista: muros de login, páginas de desafío, selectores ausentes y pasos rotos del flujo.

¿Listo para aplicar esto en una página real?

Convierte la próxima página importante en un resultado guardado, una referencia aprobada o una comprobación recurrente en vez de dejarla como un problema puntual.