Diseñar matrices de pruebas del navegador por plataforma y versión
Crea una matriz de compatibilidad manejable y basada en riesgos para recorridos compatibles, plataformas y versiones.
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.
Una matriz de navegador es una decisión de cobertura, no una lista de todos los navegadores. Conecta plataformas y versiones compatibles con recorridos de usuario y concentra pruebas donde un fallo dañaría el producto. Debe ser reproducible, explicable y mantenible. El artículo explica selección de entornos, riesgo de recorridos, equilibrio de versiones y deriva de la matriz.
Elegir entornos compatibles
Empieza por el contrato de soporte: sistemas operativos, familias, rango de versiones, viewports, entradas y redes prometidas. Cada celda necesita una razón y una persona responsable. Web Platform Tests aporta fixtures de conformidad; MDN Browser Compatibility Data aporta metadatos. Ninguna fuente sustituye la prueba de la aplicación.
const cell = {
platform: 'linux',
browser: 'chromium',
release: '154',
viewport: 'desktop',
input: 'keyboard-and-pointer',
network: 'stable',
};
const journeys = ['sign-in', 'checkout', 'download'];
for (const journey of journeys)
await runJourney({ cell, journey, evidenceId: `${cell.browser}-${cell.release}-${journey}` });
Las etiquetas describen condiciones; no infieren la máquina de una persona. Conserva perfil, ruta, locale, datos y permisos junto a la celda. Si un recorrido necesita otra configuración, crea otra celda explícita.
| Decisión | Evidencia | Acción |
|---|---|---|
| Celda crítica | soporte e impacto | probar cada candidato |
| Celda representativa | tráfico o cobertura | prueba programada |
| Celda exploratoria | plataforma futura | limitar y no bloquear |
| Celda retirada | sin usuarios compatibles | quitar con aprobación |
| Celda desconocida | sin dueño | no declararla compatible |
Priorizar recorridos
Ordena por impacto, cambios, complejidad y recuperación. Inicio de sesión, pago, carga, exportación y teclado pueden ser críticos. Una página informativa puede necesitar solo un smoke check. Escribe la razón junto a la prioridad.
Una tarjeta de recorrido incluye precondiciones, acción, resultado visible, limpieza y evidencia. Separa funcionalidad, visual, accesibilidad y rendimiento. Una navegación correcta no prueba foco, error accesible ni layout estrecho.
Equilibrar plataforma y versión
La plataforma cubre sistema, entrada, gráficos y fuentes; la versión cubre cambios del motor. Elige baseline, actual, candidata y una antigua si el contrato lo pide. No multipliques cada patch sin motivo.
Relaciona recorridos de alto riesgo con celdas que exponen su fallo: teclado con entradas, media con gráficos, descargas con política de archivos y responsive con viewports. Mantén separadas etiquetas de navegador, perfil y build.
BotBrowser puede repetir recorridos autorizados con perfil, plataforma, versión, viewport y red declarados; esa es su capacidad. No elige la política de soporte, no sustituye WPT o investigación de compatibilidad, no garantiza cada versión ni autoriza pruebas contra servicios de terceros; esa es su limitación.
Revisar deriva
La deriva aparece cuando cambia el soporte, sale una versión, cambia un recorrido o una celda deja de representar riesgo. Revisa después de releases, rutas y cambios de política. Guarda dueño, fecha, evidencia y motivo de retiro.
Al fallar una celda, clasifica defecto de aplicación, regresión del navegador, configuración, datos o alternativa. Repite el fixture mínimo y compara una celda conocida. Añade cobertura solo si cambia una decisión.
Decidir releases
Define bloqueos antes de probar. Un fallo crítico puede detener el release; una celda exploratoria puede crear seguimiento. Registra versión de matriz, labels, build, resultados, límites, dueño y rollback. Un pass no prueba servidor, autorización ni negocio.
Para contexto, consulta la lista de validación de releases y la guía de optimización.
La revisión debe indicar la siguiente acción y su propietario.
La pregunta de soporte se escribe antes de elegir celdas.
La línea base permanece inmutable durante la comparación.
Cada recorrido conserva sus precondiciones y limpieza.
Las diferencias funcionales y visuales se registran por separado.
La accesibilidad forma parte del resultado del recorrido.
Los cambios de perfil y versión se comparan por separado.
Una celda fallida se compara con una celda conocida.
El coste de la matriz se revisa junto con su cobertura.
Una excepción tiene dueño y fecha de vencimiento.
La evidencia negativa se conserva para la siguiente revisión.
Un camino de descarga necesita una limpieza verificable.
Una ruta visual necesita estado y viewport declarados.
WPT y los datos de compatibilidad son contexto, no garantía.
La política de soporte define cuándo retirar una versión.
El resultado de una celda es pass, block, follow-up o retire.
Los labels describen condiciones de prueba, no personas.
El siguiente fixture cambia una variable significativa.
Fuentes públicas
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.