Guías de RenderLog
Estas guías ayudan a decidir qué capturar, qué vigilar con frecuencia y cuándo añadir referencias, avisos o más historial. Cada artículo parte de una tarea real con páginas, no de una lista genérica de pruebas.
Empieza aquí
Elige la ruta más cercana a la página que necesitas proteger o renderizar.
Salida API
Elige esto cuando un producto, tarea de backend o revisión de cliente necesite capturas, PDF, HTML, Markdown o archivos guardados.
Revisiones recurrentes
Úsalo cuando la misma URL, vista y estado de página deban revisarse de nuevo con historial y revisión.
Páginas de precios
Empieza aquí cuando tarjetas de precio, descuentos, enlaces de pago o precios localizados puedan desviarse tras cambios de producto.
Los problemas SEO y las regresiones de interfaz suelen parecer sanos para los checks de uptime. Las paginas publicas necesitan pruebas que vean la pagina renderizada.
Úsalo cuando: Confirmar que las paginas indexables devuelven 200 y no estan bloqueadas por robots tags.
Empiece por los estados que el equipo ya revisa a mano: un precio, un formulario de registro, una página de documentación o un estado de componente que no debe cambiar tras una publicación.
Úsalo cuando: Página de precios: el precio y la llamada a la acción siguen viéndose bien.
Las páginas de precios cambian a menudo y se rompen sin ruido. RenderLog vigila la página completa, la compara con un estado aprobado y guarda contexto para la siguiente decisión de precio.
Úsalo cuando: Llamada a la acción equivocada después de actualizar una campaña.
Usa avisos inmediatos para páginas rotas y resúmenes diarios para historial visual estable que no debe interrumpir al equipo tras cada ejecución.
Úsalo cuando: Alertas inmediatas para fallos urgentes y estados bloqueados.
El historial base cubre el trabajo reciente. La retención de un año es para equipos que necesitan encontrar archivos de resultado antiguos, referencias y contexto de revisión.
Úsalo cuando: Historial reciente para QA actual y revisión de lanzamientos.
Las reglas de fallo mantienen las capturas malas fuera de revisión para que el equipo revise cambios reales.
Úsalo cuando: Muro de login en lugar de la página esperada.
Empieza con GET para una salida rápida. Pasa a POST cuando haya secretos, entradas largas, almacenamiento o pasos repetibles.
Úsalo cuando: GET: llamada rápida con una URL y unos pocos parámetros.
Una captura solo se convierte en material útil de revisión cuando el equipo sabe qué está aprobado, qué ha cambiado y quién debe actuar después.
Úsalo cuando: Aprobar la página después de un release o un cambio de diseño deliberado.
Programa una página cuando alguien responde por el resultado y la misma configuración de captura debe ejecutarse otra vez.
Úsalo cuando: Revisiones tras despliegue para páginas de precios o registro.
Empieza manualmente cuando una página necesita una respuesta visual rápida. Guarda la misma configuración para automatizar solo si la revisión se repite.
Úsalo cuando: Validar un problema de diseño reportado sin esperar a una programación.
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.
