¿Qué es el cross browser testing? Tres motores, no veinte navegadores

El cross browser testing consiste en comprobar que tu sitio funciona en los navegadores que tus visitantes usan de verdad, y no en el que tienes sobre la mesa. Esa definición es poco vistosa y está completa, y casi todos los artículos sobre el tema te entregan a continuación una tabla con treinta combinaciones de navegador y versión, que es justo donde la práctica empieza a torcerse.

Empieza por los motores. Hay tres que importan: Blink, que es Chrome, Edge, Opera, Brave y casi todo lo demás; WebKit, que es Safari en todas partes y cualquier navegador en iOS sea cual sea el nombre que lleve; y Gecko, que es Firefox. Que Chrome y Edge discrepen sobre tu maquetación es raro, porque son el mismo motor de renderizado con distinta carcasa alrededor. Que discrepen Chrome y Safari es lo corriente.

Probar treinta navegadores es, en su mayor parte, probar Blink treinta veces.

Qué se diferencia ahora de verdad

La era de los prefijos de fabricante terminó, y las diferencias que quedan son de otra naturaleza. Cuatro categorías cubren casi todas ellas.

• Códecs y medios. La categoría más cara, porque falla del todo en lugar de fallar en lo estético. Un vídeo que el navegador no puede decodificar no es un vídeo degradado; es un mensaje de error.
• APIs que un motor no ha publicado. La detección de características es la respuesta, y el modo de fallo es una función que no hace nada en silencio, en vez de una página que se ve mal.
• Casos límite de maquetación. Menos que antes, pero los que quedan suelen estar en las partes más nuevas de la especificación, exactamente donde uno echa mano de lo nuevo.
• Ritmo de publicación. El motor de Safari se actualiza junto con el sistema operativo, así que “el último Safari” es una afirmación sobre cuándo actualizó alguien su Mac o su teléfono.

Vale la pena nombrar las categorías porque necesitan respuestas distintas. Los códecs necesitan un plan alternativo servido en la página. Las APIs que faltan necesitan detección. La maquetación necesita que la mires. El ritmo necesita tus analíticas.

Un ejemplo trabajado, y fue el nuestro

Nuestra extensión graba vídeo en VP9 dentro de un contenedor WebM. Safari no tiene decodificador de VP9. La página compartida le entregaba al navegador una única fuente construida a partir del propio tipo del archivo guardado, y un elemento de vídeo HTML al que le das una sola fuente que no puede reproducir no se degrada: falla.

Así que durante un tiempo, un enlace enviado a alguien con un Mac le mostraba la palabra Error. Toda la promesa del producto es un enlace que otra persona pueda abrir, y para un motor esa promesa estaba rota.

Tres cosas sobre cómo aquello pasó inadvertido son típicas de la categoría, y por eso vale la pena escribirlo en lugar de arreglarlo en silencio.

Lo que teníamos

Pruebas automatizadas, todas en verde, todas ejecutándose en Chrome. Nada registró un error, porque desde el punto de vista del servidor nada había fallado: se sirvió un archivo, y el navegador no pudo usarlo

Lo que lo habría detectado

Abrir una grabación compartida en Safari, una vez. Sin herramientas, y sin que hubiera hecho falta que existiera ninguna suite

Quien se enteró fue el destinatario. Quien envió el enlace no lo supo nunca, porque nada te dice que la página que compartiste no funcionó para la persona con la que la compartiste. Esa es la propiedad que define a los fallos entre motores: son invisibles desde donde tú estás.

El arreglo consistió en codificar una copia en H.264 junto a cada subida y ofrecer ambas fuentes, y después grabar directamente en MP4 allí donde el navegador lo permite.

Por dónde empezar, que no es una matriz

Dos datos deciden tu lista, y ninguno de los dos es una suposición.

Tus analíticas. No la cuota de mercado mundial. Los navegadores que usan tus visitantes, en tus países, en tus páginas. Una herramienta B2B en Alemania y un sitio de consumo en Brasil dan respuestas distintas, y ambas difieren de las cifras mundiales que cita cualquier artículo comparativo.

Tu seguimiento de errores. Los errores agrupados por navegador te dirán dónde se está rompiendo ya algo, que es mejor priorización que cualquier suposición sobre dónde podría romperse.

De ahí sale una forma que funciona: haz un smoke test en los tres motores y prueba a fondo en tus dos principales. El smoke test es la misma idea que en cualquier otro sitio - ¿carga la página, puedes iniciar sesión, puedes completar el flujo que importa? - y hacerlo en Safari y Firefox atrapa en minutos toda la categoría de códecs y APIs que faltan.

Di la matriz en voz alta en tu plan de pruebas, incluyendo lo que queda fuera del alcance. “No probamos Firefox en Android” es una decisión cuando está escrito y un descuido cuando no.

Lo que las herramientas cubren y lo que no

Los servicios comerciales te alquilan máquinas con navegadores instalados, lo que resuelve el problema real de que no puedes ejecutar Safari en Linux ni tener todas las versiones de iOS sobre tu mesa. Eso merece pagarse cuando lo necesitas.

Lo que no resuelven es saber qué mirar. Una captura de tu página en doce navegadores son doce capturas que alguien tiene que comparar, que es el problema que las pruebas de regresión visual existen para automatizar - y esa suite tiene el mismo punto ciego, porque solo comprueba los navegadores de los que le hablaste.

La automatización de cualquier tipo también se lleva mal con el fallo que más importa aquí. Un vídeo que no se reproduce, una fuente que no carga, un campo de fecha que se dibuja como una caja de texto en un motor: todo eso pasa cualquier aserción sobre el DOM, porque el DOM está bien. Es el renderizado el que no lo está.

Los informes son la otra mitad

Por buena que sea la matriz, algún motor, alguna versión, algún dispositivo que no probaste producirá un fallo para una persona real. La pregunta es si te enteras.

Ese es el argumento para poner fácil informar desde donde esté cada cual, y para que el informe lleve el navegador y la versión sin pedirle a quien informa que los sepa. “No funciona en mi móvil” cuesta un día. “Safari 26.1 en iOS, en la grabación el área de vídeo sale en blanco, la consola dice que la fuente no está soportada” cuesta una tarde, y la diferencia está por completo en lo que llevaba el informe, no en lo que sabía quien informó.

Que es el límite honesto de este artículo: el cross browser testing estrecha la brecha, y los informes que llegan desde los navegadores que no cubriste son cómo averiguas dónde sigue estando la brecha. Ninguno sustituye al otro, y un equipo que solo hace uno de los dos tiene media foto.