Pruebas de navegador cruzado de alto impacto y esfuerzo mínimo

Las pruebas entre navegadores requieren mucho tiempo y son laboriosas. Sin embargo, los desarrolladores son perezosos por naturaleza: se adhieren al principio DRY, escriben scripts para automatizar cosas que de otro modo tendríamos que hacer a mano, hacen uso de bibliotecas de terceros; ser perezoso es lo que nos hace buenos desarrolladores .

El enfoque tradicional para las pruebas entre navegadores "adecuadamente" es probar en todos los principales navegadores utilizados por su audiencia, moviéndose gradualmente a los navegadores más antiguos o más oscuros para decir que los ha probado. O, si el tiempo y los recursos son escasos, probar un pequeño subconjunto de navegadores ad hoc y esperar que la ausencia de un error le dé confianza en la integridad de la aplicación. El primer enfoque encarna un 'buen' desarrollo pero es ineficiente, mientras que el segundo encarna la pereza pero no es confiable.

Lectura adicional en SmashingMag:

• La transición de Noah a las pruebas de usabilidad móvil
• Los fundamentos de la automatización de pruebas para aplicaciones, juegos y la web móvil
• Cómo crear su propio plan de prueba de sitio web front-end
• ¿Dónde están los mejores laboratorios de dispositivos abiertos del mundo?

En los próximos quince minutos, espero ahorrarle horas de esfuerzo desperdiciado al describir una estrategia de prueba que no solo requiere menos mano de obra , sino que también es más efectiva para detectar errores. Quiero documentar una estrategia de prueba realista más relevante y valiosa que simplemente "¡probar TODAS las cosas!", basándome en mi experiencia como desarrollador de prueba en BBC Visual Journalism.

Contexto

Aparte, vale la pena señalar que hacemos más que solo pruebas manuales en nuestro equipo. Las pruebas entre navegadores no reemplazan las pruebas unitarias (Jasmine/QUnit), las pruebas funcionales (Cucumber) y, cuando corresponda, las pruebas de regresión visual automatizadas (Wraith). De hecho, las pruebas automatizadas son más baratas a largo plazo y son esenciales cuando su aplicación alcanza un cierto tamaño.

Sin embargo, algunos errores solo se manifiestan en ciertos navegadores, y la automatización de pruebas aún no ha ingresado de manera confiable al dominio de las pruebas entre navegadores. ¿Cómo puede saber una computadora que su evento de desplazamiento automatizado acaba de oscurecer la mitad del título cuando se ve en un iPhone 4? ¿Cómo sabría que es un problema? Hasta que la inteligencia artificial crezca hasta un punto en el que las computadoras entiendan lo que has construido y aprecien la narrativa y el arte que intentas demostrar, siempre habrá una necesidad de pruebas manuales. Como algo que debe realizarse manualmente, nos debemos a nosotros mismos hacer que el proceso de prueba entre navegadores sea lo más eficiente posible.

¿Cuál es tu objetivo?

Antes de sumergirse a ciegas en las pruebas entre navegadores, decida qué espera obtener de ellas. Las pruebas entre navegadores se pueden resumir en dos objetivos principales:

1. Descubrir errores Esto implica tratar de romper su aplicación para encontrar errores para corregir.
2. Comprobación de cordura Esto implica verificar que la mayoría de su audiencia recibe la experiencia esperada.

Lo primero que quiero que sepas de este artículo es que estos dos objetivos entran en conflicto entre sí .

Por un lado, sé que puedo verificar la experiencia de casi el 50 % de nuestra audiencia del Reino Unido con solo probar en Chrome (escritorio), Chrome (Android) y Safari (iOS 9). Por otro lado, si mi objetivo es encontrar errores, entonces querré lanzar mi aplicación web a los navegadores más problemáticos que tenemos que admitir activamente: en nuestro caso, IE8 y Android Browser 2 nativo.

Los usuarios de estos dos navegadores representan un porcentaje cada vez menor de nuestra audiencia (actualmente alrededor del 1,5 %), lo que hace que probar en estos navegadores sea un mal uso de nuestro tiempo si nuestro objetivo es verificar la cordura. Pero son excelentes navegadores para probar si desea ver cuán destrozada puede quedar su aplicación bien diseñada cuando se lanza a un motor de renderizado oscuro.

Es comprensible que las estrategias de prueba tradicionales pongan más énfasis en las pruebas en navegadores populares. Sin embargo, existe una cantidad desproporcionada de errores solo en los navegadores más oscuros, que según el modelo de prueba tradicional no saldrán a la luz hasta el final de la prueba. Entonces te enfrentas a un dilema...

¿Qué hace cuando encuentra un error al final de la fase de prueba de cola larga?

1. Ignora el error.
2. Soluciona el error y espera que no hayas roto nada.
3. Solucione el error y vuelva a probar en todos los navegadores probados anteriormente.

En un mundo ideal, la última opción es la mejor, ya que es la única forma de estar realmente seguro de que todos los navegadores siguen funcionando como se espera. Sin embargo, también es monstruosamente ineficiente, y es algo que probablemente tendrías que hacer varias veces. Es el equivalente de prueba manual de una especie de burbuja.

Por lo tanto, nos encontramos en una situación Catch-22: para obtener la máxima eficiencia, queremos corregir todos los errores antes de comenzar las pruebas entre navegadores, pero no podemos saber qué errores existen hasta que comencemos las pruebas.

La respuesta es ser inteligente acerca de cómo probamos: cumplir nuestros objetivos de encontrar errores y verificar la cordura probando de forma incremental, en lo que me gusta llamar el ataque de tres fases .

Ataque Trifásico

Imagina que estás en una zona de guerra. Sabes que los malos están atrincherados en el cuartel general al otro lado de la ciudad. A tu disposición tienes un agente especial, un equipo de primera de guerrilleros curtidos en la batalla y un gran grupo de milicianos locales con armas ligeras. Lanzas un ataque de tres fases para recuperar la ciudad:

1. Reconocimiento Envía a tu espía al cuartel general enemigo para tener una idea de dónde se esconden los malos, cuántos hay y el estado general del campo de batalla.
2. Incursión Envía a tu equipo de élite directamente al corazón del enemigo, eliminando a la mayoría de los malos en un feroz ataque sorpresa.
3. Despeje Envíe a la milicia local para eliminar a los malos restantes y asegurar el área.

Puede llevar esa misma estrategia militar y disciplina a sus pruebas entre navegadores:

1. Reconocimiento Realice pruebas exploratorias en un navegador popular en una máquina de desarrollo. Obtenga una idea de dónde podrían estar escondidos los errores. Corrija cualquier error encontrado.
2. Raid Prueba manual en un pequeño puñado de navegadores problemáticos que probablemente muestren la mayoría de los errores. Corrija cualquier error encontrado.
3. Liquidación Sanity verifica que los navegadores más populares entre su audiencia estén limpios para obtener la experiencia esperada.

Ya sea que esté en el campo de batalla o esté probando dispositivos, las fases comienzan con un tiempo mínimo y crecen a medida que la operación se vuelve más estable. Solo hay un reconocimiento limitado que puede hacer: debería poder detectar algunos errores en muy poco tiempo. La incursión es más intensa y requiere más tiempo, pero ofrece resultados muy valiosos y estabiliza significativamente el campo de batalla. La fase de despeje es la más laboriosa de todas, y todavía tienes que mantener tu ingenio sobre ti en caso de que un malo no detectado surja de la nada y te cause daño, pero es un paso necesario para poder afirmar con confianza que el campo de batalla está listo. ahora a salvo.

Los primeros dos pasos en nuestro ataque de tres fases cumplen con nuestro primer objetivo: el descubrimiento de errores . Cuando esté seguro de que su aplicación es robusta, querrá pasar a la fase tres del ataque, probando en la cantidad mínima de navegadores que coincidan con la mayoría de los comportamientos de navegación de su audiencia, cumpliendo el objetivo número dos: verificar la cordura. Luego puede decir con confianza respaldada cuantitativamente que su aplicación funciona para el X% de su audiencia.

Configuración: conoce a tu enemigo

No entres en la guerra a la ligera. Antes de comenzar las pruebas, querrá averiguar cómo acceden los usuarios a su contenido.

Descubra las estadísticas de su audiencia (de Google Analytics, o cualquier herramienta que use) y obtenga los datos en una hoja de cálculo en un formato que pueda leer y comprender. Querrá poder ver cada combinación de navegador y sistema operativo con un porcentaje asociado de la cuota de mercado total.

Las estadísticas de uso del navegador solo son útiles si se pueden consumir fácilmente: no desea que se le presente una lista larga y abrumadora de combinaciones de navegador/SO/dispositivo para probar. Además, probar todas las combinaciones posibles es un esfuerzo inútil. Podemos usar nuestro conocimiento de desarrollador web para consolidar heurísticamente nuestras estadísticas.

Simplifique las estadísticas de uso de su navegador

Como desarrolladores web, no nos importa en particular en qué sistema operativo se ejecuta el navegador de escritorio; es muy raro que un error del navegador se aplique a un sistema operativo y no al otro, por lo que combinamos las estadísticas de los navegadores de escritorio en todos los sistemas operativos.

Tampoco nos importa especialmente si alguien está usando Firefox 40 o Firefox 39: las diferencias entre las versiones son insignificantes y la actualización de las versiones es gratuita y, a menudo, automática. Para facilitar nuestra comprensión de las estadísticas del navegador, fusionamos versiones de todos los navegadores de escritorio, excepto IE. Sabemos que las versiones anteriores de IE son problemáticas y están muy extendidas, por lo que debemos realizar un seguimiento de sus cifras de uso.

Un argumento similar se aplica a los navegadores de sistemas operativos portátiles. No nos importa especialmente la versión móvil de Chrome o Firefox, ya que estos se actualizan con regularidad y facilidad, por lo que fusionamos las versiones. Pero nuevamente, nos preocupamos por las diferentes versiones de IE, por lo que registramos sus versiones por separado.

La versión del sistema operativo de un dispositivo es irrelevante si hablamos de Android; lo importante es la versión del navegador nativo de Android utilizado, ya que este es un navegador notoriamente problemático. Por otro lado, qué versión de iOS está ejecutando un dispositivo es muy relevante ya que las versiones de Safari están intrínsecamente vinculadas al sistema operativo. Luego hay una gran cantidad de navegadores nativos para otros dispositivos: estos constituyen un porcentaje tan pequeño de nuestra audiencia general que también tienen sus números de versión fusionados.

Finalmente, tenemos una nueva ola de navegadores que crece rápidamente en popularidad: navegadores integrados en aplicaciones, implementados principalmente en plataformas de redes sociales. Este es todavía un terreno nuevo para nosotros, por lo que estamos interesados ​​​​en enumerar todas las plataformas de navegador en la aplicación y sus respectivos sistemas operativos.

Una vez que hemos utilizado nuestro conocimiento experto del dominio para fusionar estadísticas relacionadas, reducimos la lista aún más al eliminar todos los navegadores que representan menos del 0,05% de nuestra audiencia (siéntase libre de ajustar este umbral según sus propios requisitos).

Navegadores de escritorio

Navegadores portátiles

Navegadores en la aplicación

Cuando haya terminado, su hoja de cálculo debería parecerse un poco a esto (ignore la columna "Prioridad" por ahora; hablaremos de eso más adelante):

Así que ahora tiene su hoja de cálculo simplificada, que muestra los navegadores clave desde la perspectiva del desarrollador web, cada uno asociado con un porcentaje total de participación en el mercado. Tenga en cuenta que debe mantener esta hoja de cálculo actualizada; actualizar una vez al mes debería ser suficiente.

Ahora está listo para embarcarse en el ataque de tres fases.

1. Reconocimiento: encuentre errores independientes del navegador

Mucho antes de siquiera pensar en sacar un dispositivo para probarlo, haga lo más fácil que pueda: abra su aplicación web en su navegador favorito. A menos que seas un completo masoquista, es probable que sea Chrome o Firefox, los cuales son estables y admiten funciones modernas. El objetivo de esta primera etapa es encontrar errores independientes del navegador .

Los errores independientes del navegador son errores de implementación que no tienen nada que ver con el navegador o el hardware utilizado para acceder a su aplicación. Por ejemplo, supongamos que su página web se activa y comienza a recibir informes de errores oscuros de personas que se quejan de que su página se ve mal en su HTC One en modo horizontal. Pierde mucho tiempo determinando qué versión de qué navegador se usó, usando el modo de depuración USB de Android y buscando ayuda en StackOverflow, preguntándose cómo diablos va a solucionar esto. Sin que usted lo sepa, este error no tiene nada que ver con el dispositivo: más bien, su página se ve con errores en un cierto ancho de ventana gráfica, que resulta ser el ancho de pantalla del dispositivo en cuestión.

Este es un ejemplo de un error independiente del navegador que se ha manifestado falsamente como un error específico del navegador o del dispositivo. Ha sido conducido por un camino largo y derrochador, con informes de errores que actúan como ruido, ofuscando la causa raíz del problema. Hágase un favor y atrape este tipo de error desde el principio, con mucho menos esfuerzo y un poco más de previsión.

Al corregir los errores independientes del navegador incluso antes de que comencemos las pruebas entre navegadores, deberíamos enfrentarnos a menos errores en general. Me gusta llamar a esto el efecto iceberg que se derrite . Estamos derritiendo los insectos que se esconden bajo la superficie, salvándonos de estrellarnos y ahogarnos en el océano, y ni siquiera nos damos cuenta de que lo estamos haciendo.

A continuación se muestra una breve lista de cosas que puede hacer en su navegador de desarrollo para descubrir errores independientes del navegador:

• Intente cambiar el tamaño para ver la capacidad de respuesta. ¿Había un punto de quiebre funky en alguna parte?
• Acercar y alejar. ¿Se han torcido las posiciones de fondo de tu sprite de imagen?
• Vea cómo se comporta la aplicación con JavaScript desactivado. ¿Aún obtienes el contenido principal?
• Vea cómo se ve la aplicación con CSS desactivado. ¿Sigue teniendo sentido la semántica del marcado?
• Intente desactivar tanto JavaScript como CSS. ¿Estás teniendo una experiencia aceptable?
• Intente interactuar con la aplicación usando solo su teclado. ¿Es posible navegar y ver todo el contenido?
• Intente acelerar su conexión y vea qué tan rápido se carga la aplicación. ¿Qué tan pesada es la carga de la página?

Antes de pasar a la fase 2, debe corregir los errores que ha encontrado. Si no solucionamos los errores independientes del navegador, solo terminaremos informando muchos errores falsos específicos del navegador más adelante.

Ser perezoso. Solucione los errores independientes del navegador. Entonces podemos pasar a la segunda fase del ataque.

2. Raid: prueba primero en navegadores de alto riesgo

Cuando arreglamos errores, debemos tener cuidado de que nuestras correcciones no introduzcan más errores. Ajustar nuestro CSS para corregir el relleno en Safari podría romper el relleno en Firefox. Optimizar ese bit de JavaScript para que funcione sin problemas en Chrome podría romperlo por completo en IE. Cada cambio que hacemos conlleva un riesgo.

Para estar verdaderamente seguros de que los nuevos cambios no han afectado la experiencia en ninguno de los navegadores en los que ya hemos probado, tenemos que regresar y probar en esos mismos navegadores nuevamente. Por lo tanto, para minimizar la duplicación de esfuerzos, debemos ser inteligentes acerca de cómo probamos.

Análisis estadístico de la distribución de errores.

Considere la siguiente tabla, donde el icono de cruz significa que el navegador tiene el error.

Digamos que vamos a probar nuestro contenido en orden ascendente de riesgo: navegador de riesgo bajo, navegador de riesgo medio, navegador de riesgo alto. Si le ayuda a visualizar esto, estos navegadores pueden asignarse a Google Chrome, IE 9 e IE 6 respectivamente.

Probando primero el navegador de bajo riesgo (Chrome), encontraríamos y corregiríamos el error n.º 2. Cuando pasamos al navegador de riesgo medio, el error n.º 2 ya está solucionado, pero descubrimos un nuevo error: el n.º 4. Cambiamos nuestro código para corregir el error, pero ¿cómo podemos estar seguros de que no hemos roto algo en el navegador de bajo riesgo? No podemos estar completamente seguros, por lo que tenemos que volver y probar en ese navegador nuevamente para verificar que todo sigue funcionando como se esperaba.

Ahora pasamos al navegador de alto riesgo y encontramos los errores n. ° 1, n. ° 3 y n. ° 5, que requieren una revisión significativa para solucionarlos. Una vez solucionados estos, ¿qué tenemos que hacer? Regrese y pruebe nuevamente los navegadores de riesgo medio y bajo. Esto es mucha duplicación de esfuerzos. Hemos tenido que probar nuestros tres navegadores un total de seis veces.

Ahora, consideremos qué habría sucedido si hubiéramos probado nuestro contenido en orden descendente de riesgo.

De inmediato, encontraríamos los errores n.º 1, n.º 3, n.º 4 y n.º 5 en el navegador de alto riesgo. Después de corregir esos errores, pasaríamos directamente al navegador de riesgo medio y descubriríamos el error n.º 2. Como antes, esta solución puede haber roto algo indirectamente, por lo que es necesario volver al navegador de alto riesgo y volver a realizar la prueba. Finalmente, probamos en el navegador de bajo riesgo y no descubrimos nuevos errores. En este caso, hemos probado nuestros tres navegadores en un total de cuatro ocasiones diferentes, lo que representa una gran reducción en la cantidad de tiempo necesario para descubrir y corregir de manera efectiva la misma cantidad de errores y validar el comportamiento de la misma cantidad de navegadores. .

Puede haber una presión sobre los desarrolladores para probar primero en los navegadores más populares, avanzando hacia los navegadores menos utilizados hacia el final de nuestras pruebas. Sin embargo, es probable que los navegadores populares sean navegadores de bajo riesgo.

Usted sabe que tiene que ser compatible con un navegador de alto riesgo determinado, así que elimine ese navegador desde el principio. No desperdicie el esfuerzo probando navegadores que tienen menos probabilidades de generar errores, porque cuando cambia a navegadores que generan más errores, solo tendrá que regresar y mirar esos navegadores de bajo riesgo nuevamente.

La corrección de errores en los malos navegadores hace que su código sea más resistente en los buenos navegadores

A menudo encontrará que los errores que surgen en estos navegadores problemáticos son el resultado inesperado de un código deficiente de su parte. Es posible que haya diseñado un div de manera extraña para que parezca un botón, o que haya pirateado un setTimeout antes de desencadenar un comportamiento arbitrario; existen mejores soluciones para ambos problemas. Al corregir los errores que son los síntomas de un código incorrecto, es probable que corrija errores en otros navegadores incluso antes de verlos. Ahí está ese efecto iceberg derritiéndose otra vez.

Al verificar el soporte de funciones, en lugar de asumir que un navegador admite algo, está solucionando ese error doloroso en IE8 pero también está haciendo que su código sea más robusto para otros entornos hostiles. Al proporcionar esa imagen de respaldo para Opera Mini, está fomentando el uso de la mejora progresiva y, como subproducto, está mejorando su producto incluso para los usuarios de navegadores que cortan la mostaza. Por ejemplo, un dispositivo móvil podría perder su conexión 3G con solo la mitad de los activos de su aplicación descargados: el usuario ahora obtiene una experiencia significativa que antes no tendría.

Sin embargo, tenga cuidado: si no tiene cuidado, corregir errores en navegadores oscuros puede empeorar su código. Resista la tentación de olfatear la cadena de agente de usuario para entregar contenido condicionalmente a navegadores específicos, por ejemplo. Eso podría solucionar el error, pero es una práctica completamente insostenible. No comprometa la integridad de un buen código para admitir navegadores complicados.

Identificación de navegadores problemáticos

Entonces, ¿qué es un navegador de alto riesgo? La respuesta es un poco confusa y depende de las características del navegador que utilice su aplicación. Si su JavaScript usa indexOf , podría romperse en IE 8. Si su aplicación usa position: fixed , querrá comprobarlo en Safari en iOS 7.

Can I Use es un recurso invaluable y un buen lugar para comenzar, pero esta es una de esas áreas que nuevamente proviene de la experiencia y la intuición del desarrollador. Si implementa aplicaciones web con regularidad, sabrá qué navegadores señalan problemas una y otra vez, y puede refinar su estrategia de prueba para adaptarse a esto.

Lo útil de los errores que encuentra en los navegadores problemáticos es que a menudo se propagarán. Si hay un error en IE9, es probable que el error también exista en IE8. Si algo se ve raro en Safari en iOS 7, probablemente se verá aún más pronunciado en iOS 6. ¿Ves un patrón aquí? Los navegadores más antiguos tienden a ser los problemáticos. Eso debería ayudarlo a crear una lista bastante buena de navegadores problemáticos.

Dicho esto , respalde esto con estadísticas de uso. Por ejemplo, IE 6 es un navegador muy problemático, pero no nos molestamos en probarlo porque su cuota de mercado total es demasiado baja. El tiempo dedicado a corregir errores específicos de IE6 no valdría la pena para el pequeño número de usuarios cuya experiencia mejoraría.

No siempre querrás probar los navegadores más antiguos en la fase de incursión. Por ejemplo, si tiene un proyecto de lienzo 3D WebGL experimental con respaldo de imagen, los navegadores más antiguos solo obtendrán la imagen de respaldo, por lo que es poco probable que encontremos muchos errores. Lo que nos gustaría hacer en su lugar es cambiar nuestra elección de navegador problemático en función de la aplicación en cuestión. En este caso, IE9 podría ser un buen navegador para probar porque es la primera versión de IE que admite lienzo.

Los navegadores proxy modernos (como Opera Mini) también pueden ser una buena opción para una prueba de incursión, si su aplicación utiliza funciones de CSS3, como gradientes o radio de borde. Un error común es representar texto blanco en un degradado no admitido, lo que da como resultado un texto blanco sobre blanco ilegible.

Al elegir sus navegadores problemáticos, use su intuición e intente anticiparse a dónde podrían estar escondidos los errores.

Diversifique sus navegadores problemáticos

Los navegadores y las versiones de los navegadores son solo una parte de la ecuación: el hardware también es una consideración importante. Querrá probar su aplicación en una variedad de tamaños de pantalla y diferentes densidades de píxeles, e intentar cambiar entre el modo vertical y horizontal.

Puede ser tentador agrupar navegadores relacionados porque se percibe un descuento en el costo del esfuerzo. Si ya tiene VirtualBox abierto para probar IE8, ahora puede parecer un buen momento para probar también en IE9, IE10 e IE11. Sin embargo, si está en las primeras etapas de prueba de su aplicación web, querrá luchar contra esta tentación y, en su lugar, elegir tres o cuatro combinaciones de navegador y hardware que sean marcadamente diferentes entre sí, para obtener la mayor cobertura sobre el total. error de espacio como le sea posible.

Aunque estos pueden variar de un proyecto a otro, aquí están mis navegadores problemáticos actuales de elección:

• IE 8 en una máquina virtual con Windows XP;
• Android Browser 2 nativo en una tableta Android de gama media;
• Safari en un iPhone 4 con iOS 6;
• Opera mini (realmente solo vale la pena probarlo con contenido que debería funcionar sin JavaScript, como imágenes de datos).

Ser perezoso. Encuentre tantos errores como sea posible lanzando su aplicación a sus navegadores y dispositivos compatibles más problemáticos. Con estos errores corregidos, puedes pasar a la fase final del ataque.

3. Liquidación: control de cordura

Ahora ha probado su aplicación en los navegadores más duros que tiene que admitir, con suerte detectando la mayoría de los errores. Pero su aplicación aún no está completamente libre de errores. Siempre me sorprende lo diferente que incluso las últimas versiones de Chrome y Firefox muestran el mismo contenido. Todavía tienes que hacer algunas pruebas más.

Es esa vieja regla 80:20. En sentido figurado, ha corregido el 80 % de los errores después de probar el 20 % de los navegadores. Ahora lo que quieres hacer es verificar la experiencia del 80% de tu audiencia probando un 20% diferente de navegadores.

Priorizar los navegadores

El enfoque simple y obvio ahora es volver a las pruebas 'tradicionales' entre navegadores, abordando cada navegador en orden descendente de participación de mercado. Si el escritorio de Chrome resulta ser la proporción más alta del uso compartido de navegadores de su audiencia, seguido de Safari en iOS 8, seguido de IE11, entonces tiene sentido probar en ese orden, ¿verdad?

Ese es un sistema en gran parte justo, y no quiero complicar demasiado este paso si sus recursos ya están estirados. Sin embargo, el hecho es que no todos los navegadores son iguales. En mi equipo, agrupamos los navegadores de acuerdo con un árbol de decisiones que tiene en cuenta el uso del navegador, la facilidad de actualización y si el navegador es o no el sistema operativo predeterminado.

Hasta ahora, su hoja de cálculo debería tener una columna para el navegador y una columna para su cuota de mercado; ahora necesita una tercera columna, que designe en qué prioridad cae el navegador. A decir verdad, este trabajo de priorización debería haberse realizado antes de lanzar el ataque de tres fases, pero a los efectos de este artículo tiene más sentido describirlo aquí, ya que las prioridades no son realmente necesarias hasta la fase de autorización.

Este es nuestro árbol de decisiones:

Hemos diseñado nuestro árbol de decisiones para que los navegadores P1 cubran aproximadamente el 70 % de nuestra audiencia. Los navegadores P1 y P2 combinados cubren aproximadamente el 90% de nuestra audiencia. Finalmente, los navegadores P1, P2 y P3 nos brindan una cobertura de audiencia casi completa. Nuestro objetivo es probar en todos los navegadores P1, seguido de P2, seguido de P3, en orden descendente de participación de mercado.

Como puede ver en la hoja de cálculo anterior en este artículo, solo tenemos un puñado de navegadores P1. El hecho de que podamos verificar la experiencia de más del 70 % de nuestra audiencia tan rápidamente significa que tenemos pocas excusas para no volver a probar en esos navegadores si el código base cambia. A medida que avanzamos hacia los navegadores P2 y P3, debemos realizar un esfuerzo cada vez mayor para verificar la experiencia de un tamaño de audiencia cada vez menor, por lo que debemos establecer ideales de prueba más realistas para los navegadores de menor prioridad. Como pauta:

• P1 . Debemos verificar la cordura en estos navegadores antes de cerrar sesión en la aplicación. Si hacemos pequeños cambios en nuestro código, entonces deberíamos verificar la cordura en estos navegadores nuevamente.
• P2 . Deberíamos verificar la cordura en estos navegadores antes de cerrar sesión en la aplicación. Si hacemos grandes cambios en nuestro código, entonces deberíamos verificar la cordura en estos navegadores nuevamente.
• P3 . Deberíamos verificar la cordura en estos navegadores una vez, pero solo si tenemos tiempo.

No olvide la necesidad de diversificar su hardware. Si puede probar en una multitud de tamaños de pantalla diferentes y en dispositivos con diferentes capacidades de hardware mientras sigue esta lista, hágalo.

Resumen: el ataque en tres fases

Una vez que haya hecho el esfuerzo de conocer a su enemigo ( simplificando las estadísticas de su audiencia y agrupando los navegadores en prioridades ), puede atacar en tres pasos:

1. Reconocimiento : pruebas exploratorias en su navegador favorito, para encontrar errores independientes del navegador .
2. Raid : prueba en los navegadores compatibles más problemáticos en una variedad de hardware, para encontrar la mayoría de los errores .
3. Liquidación : verificar la experiencia de su aplicación en los navegadores más utilizados y estratégicamente importantes, para decir con confianza respaldada cuantitativamente que su aplicación funciona .