Motor del navegador frente a comparación del producto
Separa el comportamiento definido por los estándares de la experiencia de producto que debe entregar un navegador.
BotBrowser Team
Quieres la documentación estructurada de Plataforma?
Este artículo forma parte de la biblioteca editorial. Para pasos de configuración, material de referencia y actualizaciones continuas, entra en la sección de docs.
BotBrowser puede repetir una prueba autorizada en contextos controlados. No hace equivalentes dos motores, no certifica conformidad con estándares ni convierte un resultado en una clasificación universal.
Dos preguntas distintas
El motor implementa análisis, renderizado, planificación y APIs de la plataforma web. WHATWG y W3C definen interfaces y reglas; MDN Web APIs y sus tablas de compatibilidad describen soporte público. Eso responde qué comportamiento se define y bajo qué condiciones existe.
Un producto incluye motor, interfaz, permisos, perfil, sistema anfitrión, gráficos, red, accesibilidad y servidor. La comparación de producto pregunta si un recorrido autorizado alcanza su estado visible y accesible. No se deduce del soporte de una API.
Separa las evidencias
| Capa | Pregunta observable | No demuestra |
|---|---|---|
| Estándar | ¿Qué interfaz o regla está definida? | Que todo producto la exponga. |
| Motor | ¿La API existe y produce el resultado primitivo? | Permisos, servidor, accesibilidad o datos iguales. |
| Producto | ¿El recorrido llega al estado requerido? | Igualdad en otro host, versión o sitio. |
Usa una sola prueba, datos sintéticos, permisos declarados y un criterio explícito. Cambia una variable cada vez y clasifica: compatible bajo condiciones, condicional, diferencia de producto, diferencia de entorno o desconocido. No publiques un “mejor navegador” con una puntuación sin audiencia ni pesos.
Hoja de decisión de cinco filas
| Fila de evidencia | Registra esta observación | Acción y límite |
|---|---|---|
| Declaración del estándar | Enlaza la interfaz o regla normativa y anota su versión. | Trátala como definición, no como prueba de implementación, identidad, privacidad ni corrección empresarial. Comprueba el tiempo de ejecución. |
| Observación del motor | Registra la presencia de la API y el resultado primitivo con permisos declarados. | Compara la misma versión y prueba. No demuestra el resultado completo del producto, la identidad, la privacidad ni la accesibilidad. |
| Resultado del producto | Registra el estado visible y accesible, incluido el recurso alternativo y la recuperación. | Decide el soporte solo para ese recorrido. No demuestra que otro sitio, cliente, dispositivo o transacción funcione. |
| Diferencia del entorno | Registra el host, pantalla, red, respuesta del servidor, perfil o tecnología de asistencia que cambió. | Restaura la base y repite antes de culpar al motor. No prueba identidad, privacidad ni defecto del producto. |
| Desconocido o recurso alternativo | Registra la evidencia ausente, el fallo y el recurso alternativo utilizable. | Conserva “desconocido”, asigna responsable y prueba el recurso alternativo. No infieras identidad, privacidad ni corrección empresarial. |
Límites de BotBrowser
La documentación de funciones avanzadas describe contextos controlados y superficies de perfil para repetir recorridos autorizados. BotBrowser no implementa estándares, decide el soporte del producto ni controla servidor, hardware, pantalla, tecnología de asistencia, proxy o interpretación de terceros. Una prueba positiva no prueba privacidad, accesibilidad, identidad ni corrección universal.
BotBrowser puede repetir recorridos autorizados con contextos declarados y comparar estados visibles. No puede implementar los estándares, decidir qué debe soportar tu producto ni garantizar igualdad entre hosts, dispositivos, pantallas o tecnologías de asistencia. La prueba debe aportar el fixture y el criterio; BotBrowser solo aporta una ejecución controlada.
Empieza por el resultado que necesita la persona usuaria y define el estado inicial, los datos sintéticos y los permisos. El nombre del motor no sustituye un contrato observable.
Indica también las exclusiones: una confirmación no demuestra autorización de pago, retención del proveedor ni una decisión de riesgo.
Los estándares definen reglas, MDN aporta condiciones de soporte y el recorrido del producto comprueba la experiencia completa. Ninguna fuente certifica por sí sola a todos los usuarios.
Declara versión, perfil, host, ventana, idioma, zona horaria, red, permisos y revisión del fixture. Cambia una sola variable o marca el resultado como desconocido.
Usa un oráculo revisable, como un nombre accesible, un estado DOM o un archivo sintético. Una captura no prueba el foco ni un anuncio de lector de pantalla.
Interpretar las diferencias
Conserva rechazos, cancelaciones, APIs ausentes, respuestas del servidor y tiempos agotados. Cada caso necesita una alternativa observable.
Clasifica la diferencia como estándar, motor, producto o entorno. Un cambio de fuentes, gráficos, proxy o servidor no demuestra por sí solo un defecto del motor.
La accesibilidad pertenece al recorrido: comprueba foco, teclado, nombres, estados y preferencias. Si no pruebas tecnología de asistencia, dilo.
Minimiza los datos. Un perfil repite una ejecución autorizada, pero su identificador no describe a una persona ni demuestra borrado remoto.
Decisión y revisión
Convierte el resultado en una acción reversible con propietario y disparador de repetición. Prueba la alternativa como un recorrido separado.
Revisa el informe con producto, ingeniería, accesibilidad y privacidad. Cada afirmación necesita fuente u observación, y cada desconocido un responsable.
Define la audiencia y el estado final antes de comparar.
Usa datos sintéticos y permisos declarados.
Registra el resultado visible y la condición que lo produjo.
Conserva los casos desconocidos para una prueba posterior.
Una API disponible no garantiza una experiencia accesible.
Un servidor puede cambiar el resultado sin cambiar el motor.
El host y la pantalla pueden explicar una diferencia visual.
Repite el fixture cuando cambie la versión o el servidor.
No conviertas un resultado local en una promesa universal.
El equipo de producto mantiene la decisión y su fecha de revisión.
Registro acotado
Anota fuente normativa, versión, condiciones del host, fixture, estado esperado, resultado y límite. Conserva los fallos de preparación y los casos desconocidos. Repite cuando cambie el motor, el producto, el host, el servidor o la promesa de accesibilidad.
Fuentes públicas
Consulta también metodología de comparación y compatibilidad de APIs y alternativas.
Artículos Relacionados
Lleva BotBrowser de la investigación a producción
Usa estas guías para entender el modelo y después avanzar hacia validación multiplataforma, contextos aislados y despliegue de navegador preparado para escalar.