Tests multi-navigateurs à fort impact et à effort minimal

Les tests inter-navigateurs prennent du temps et sont laborieux. Cependant, les développeurs sont paresseux par nature : adhérer au principe DRY, écrire des scripts pour automatiser des choses que nous aurions autrement à faire à la main, utiliser des bibliothèques tierces ; être paresseux est ce qui fait de nous de bons développeurs .

L'approche traditionnelle des tests inter-navigateurs "correctement" consiste à tester dans tous les principaux navigateurs utilisés par votre public, en passant progressivement aux navigateurs les plus anciens ou les plus obscurs afin de dire que vous les avez testés. Ou, si le temps et les ressources sont limités, tester un petit sous-ensemble de navigateurs ad hoc et espérer que l'absence de bogue vous donne confiance dans l'intégrité de l'application. La première approche incarne le « bon » développement mais est inefficace, tandis que la seconde incarne la paresse mais n'est pas fiable.

Lectures complémentaires sur SmashingMag :

• La transition de Noah vers les tests d'utilisabilité mobile
• Les bases de l'automatisation des tests pour les applications, les jeux et le Web mobile
• Comment créer votre propre plan de test de site Web frontal
• Où sont les meilleurs laboratoires d'appareils ouverts au monde ?

Au cours des quinze prochaines minutes, j'espère vous épargner des heures d'efforts inutiles en décrivant une stratégie de test qui est non seulement moins exigeante en main-d'œuvre , mais aussi plus efficace pour détecter les bogues. Je souhaite documenter une stratégie de test réaliste plus pertinente et plus précieuse que simplement "tester TOUTES les choses !", en m'appuyant sur mon expérience en tant que développeur de tests dans le journalisme visuel de la BBC.

Le contexte

En passant, il convient de souligner que nous faisons plus que de simples tests manuels dans notre équipe. Les tests inter-navigateurs ne remplacent pas les tests unitaires (Jasmine/QUunit), les tests fonctionnels (Cucumber) et, le cas échéant, les tests de régression visuelle automatisés (Wraith). En effet, les tests automatisés sont moins chers sur le long terme et sont indispensables lorsque votre application atteint une certaine taille.

Cependant, certains bogues ne se manifestent que dans certains navigateurs et l'automatisation des tests n'est pas encore entrée de manière fiable dans le domaine des tests inter-navigateurs. Comment un ordinateur peut-il savoir que votre événement de défilement automatisé vient de masquer la moitié du titre lorsqu'il est visualisé sur un iPhone 4 ? Comment saurait-il que c'est un problème ? Jusqu'à ce que l'intelligence artificielle atteigne un point où les ordinateurs comprennent ce que vous avez construit et apprécient le récit et l'art que vous essayez de démontrer, il y aura toujours un besoin de tests manuels. Comme quelque chose qui doit être effectué manuellement, nous nous devons de rendre le processus de test inter-navigateurs aussi efficace que possible.

Quel est votre objectif ?

Avant de plonger aveuglément dans les tests inter-navigateurs, décidez ce que vous espérez en retirer. Les tests inter-navigateurs peuvent être résumés comme ayant deux objectifs principaux :

1. Découvrir des bogues Cela implique d'essayer de casser votre application pour trouver des bogues à corriger.
2. Vérification de l'intégrité Cela implique de vérifier que la majorité de votre public reçoit l'expérience attendue.

La première chose que je veux que vous reteniez de cet article est que ces deux objectifs s'opposent l'un à l'autre .

D'une part, je sais que je peux vérifier l'expérience de près de 50 % de notre public britannique simplement en testant dans Chrome (Desktop), Chrome (Android) et Safari (iOS 9). D'un autre côté, si mon objectif est de trouver des bogues, je souhaiterai lancer mon application Web sur les navigateurs les plus problématiques que nous devons activement prendre en charge : dans notre cas, IE8 et le navigateur natif Android 2.

Les utilisateurs de ces deux navigateurs représentent un pourcentage décroissant de notre audience (actuellement environ 1,5 %), ce qui fait des tests dans ces navigateurs une mauvaise utilisation de notre temps si notre objectif est de vérifier l'intégrité. Mais ce sont d'excellents navigateurs à tester si vous voulez voir à quel point votre application bien conçue peut devenir endommagée lorsqu'elle est lancée sur un moteur de rendu obscur.

Les stratégies de test traditionnelles mettent naturellement davantage l'accent sur les tests dans les navigateurs populaires. Cependant, un nombre disproportionné de bogues n'existent que dans les navigateurs les plus obscurs, qui, dans le cadre du modèle de test traditionnel, ne seront révélés que vers la fin des tests. Vous êtes alors face à un dilemme…

Que faites-vous lorsque vous trouvez un bogue tard dans la phase de test de longue traine ?

1. Ignorez le bogue.
2. Corrigez le bug et espérez que vous n'avez rien cassé.
3. Corrigez le bogue et refaites le test dans tous les navigateurs précédemment testés.

Dans un monde idéal, la dernière option est la meilleure car c'est le seul moyen d'être vraiment sûr que tous les navigateurs fonctionnent toujours comme prévu. Cependant, il est également monstrueusement inefficace - et c'est quelque chose que vous devrez probablement faire plusieurs fois. C'est l'équivalent d'un test manuel d'un tri à bulles.

Nous nous retrouvons donc dans une situation de catch-22 : pour une efficacité maximale, nous voulons corriger tous les bogues avant de commencer les tests inter-navigateurs, mais nous ne pouvons pas savoir quels bogues existent avant de commencer les tests.

La réponse est d'être intelligent sur la façon dont nous testons : remplir nos objectifs de recherche de bogues et de vérification de l'intégrité en testant de manière incrémentielle, dans ce que j'aime appeler l' attaque en trois phases .

Attaque en trois phases

Imaginez que vous êtes dans une zone de guerre. Vous savez que les méchants sont retranchés au QG de l'autre côté de la ville. À votre disposition, vous avez un agent spécial, une équipe d'élite de guérilleros endurcis au combat et un grand groupe de miliciens locaux légèrement armés. Vous lancez une attaque en trois phases pour reprendre la ville :

1. Reconnaissance Envoyez votre espion dans le QG ennemi pour avoir une idée de l'endroit où les méchants pourraient se cacher, de leur nombre et de l'état général du champ de bataille.
2. Raid Envoyez votre équipe d'élite au cœur de l'ennemi, en éliminant la majorité des méchants lors d'une attaque surprise féroce.
3. Dégagement Envoyez la milice locale pour éliminer les méchants restants et sécuriser la zone.

Vous pouvez apporter la même stratégie militaire et la même discipline à vos tests multi-navigateurs :

1. Reconnaissance Effectuez des tests exploratoires dans un navigateur populaire sur une machine de développement. Ayez une idée de l'endroit où les bogues pourraient se cacher. Corrigez les bugs rencontrés.
2. Raid Test manuel sur une petite poignée de navigateurs problématiques susceptibles de présenter le plus de bogues. Corrigez les bugs rencontrés.
3. Clearance Sanity vérifie que les navigateurs les plus populaires parmi votre public sont autorisés pour obtenir l'expérience attendue.

Que vous soyez sur le champ de bataille ou que vous testiez un appareil, les phases commencent avec un minimum de temps passé et se développent à mesure que l'opération devient plus stable. Il n'y a pas beaucoup de reconnaissance que vous pouvez faire – vous devriez être capable de repérer quelques bogues en très peu de temps. Le raid est plus intense et prend plus de temps, mais donne des résultats très intéressants et stabilise considérablement le champ de bataille. La phase de dégagement est la plus laborieuse de toutes, et vous devez toujours garder l'esprit vif au cas où un méchant non repéré sortirait de nulle part et vous ferait du mal - mais c'est une étape nécessaire pour pouvoir affirmer en toute confiance que le champ de bataille est maintenant en sécurité.

Les deux premières étapes de notre attaque en trois phases remplissent notre premier objectif : la découverte de bogues . Lorsque vous êtes convaincu que votre application est robuste, vous pouvez passer à la phase trois de l'attaque, en testant le nombre minimum de navigateurs qui correspondent à la majorité des comportements de navigation de votre public, en remplissant l'objectif numéro deux : la vérification de l'intégrité. Vous pouvez alors dire avec une confiance quantitativement soutenue que votre application fonctionne pour X % de votre public.

Configuration : Connaissez votre ennemi

N'entrez pas en guerre à la légère. Avant de commencer les tests, vous voudrez savoir comment les utilisateurs accèdent à votre contenu.

Découvrez vos statistiques d'audience (à partir de Google Analytics ou de tout autre outil que vous utilisez) et obtenez les données dans une feuille de calcul dans un format que vous pouvez lire et comprendre. Vous voudrez pouvoir voir chaque combinaison de navigateur et de système d'exploitation avec un pourcentage associé de la part de marché totale.

Les statistiques d'utilisation du navigateur ne sont utiles que si elles peuvent être consultées facilement : vous ne voulez pas vous voir présenter une longue liste intimidante de combinaisons navigateur/OS/appareil à tester. De plus, tester toutes les combinaisons possibles est un effort inutile. Nous pouvons utiliser nos connaissances de développeur web pour consolider nos statistiques de manière heuristique.

Simplifiez les statistiques d'utilisation de votre navigateur

En tant que développeurs Web, nous ne nous soucions pas particulièrement du système d'exploitation sur lequel le navigateur de bureau s'exécute - il est très rare qu'un bogue de navigateur s'applique à un système d'exploitation et pas à l'autre - nous fusionnons donc les statistiques des navigateurs de bureau sur tous les systèmes d'exploitation.

Peu nous importe également que quelqu'un utilise Firefox 40 ou Firefox 39 : les différences entre les versions sont négligeables et la mise à jour des versions est gratuite et souvent automatique. Pour faciliter notre compréhension des statistiques du navigateur, nous fusionnons les versions de tous les navigateurs de bureau, à l'exception d'IE. Nous savons que les anciennes versions d'IE sont à la fois problématiques et répandues, nous devons donc suivre leurs chiffres d'utilisation.

Un argument similaire s'applique aux navigateurs OS portables. Nous ne nous soucions pas particulièrement de la version de Chrome mobile ou de Firefox, car ceux-ci sont régulièrement et facilement mis à jour - nous fusionnons donc les versions. Mais encore une fois, nous nous soucions des différentes versions d'IE, nous enregistrons donc leurs versions séparément.

La version du système d'exploitation d'un appareil n'est pas pertinente si nous parlons d'Android ; ce qui est important, c'est la version du navigateur Android natif utilisé, car il s'agit d'un navigateur notoirement problématique. D'autre part, la version d'iOS qu'un appareil exécute est très pertinente car les versions de Safari sont intrinsèquement liées au système d'exploitation. Ensuite, il existe toute une série de navigateurs natifs pour d'autres appareils : ceux-ci représentent un si petit pourcentage de notre audience globale qu'ils voient également leurs numéros de version fusionnés.

Enfin, nous avons une nouvelle vague de navigateurs qui gagne rapidement en popularité : les navigateurs intégrés à l'application, principalement mis en œuvre sur les plateformes de médias sociaux. C'est encore un terrain nouveau pour nous, nous tenons donc à répertorier toutes les plates-formes de navigateur intégrées à l'application et leur système d'exploitation respectif.

Une fois que nous avons utilisé nos connaissances d'expert du domaine pour fusionner les statistiques associées, nous réduisons davantage la liste en supprimant tous les navigateurs qui représentent moins de 0,05 % de notre audience (n'hésitez pas à ajuster ce seuil en fonction de vos propres besoins).

Navigateurs de bureau

Navigateurs portables

Navigateurs intégrés à l'application

Lorsque vous avez terminé, votre feuille de calcul devrait ressembler un peu à ceci (ignorez la colonne "Priorité" pour l'instant - nous y reviendrons plus tard) :

Vous avez maintenant votre feuille de calcul simplifiée, montrant les principaux navigateurs du point de vue du développeur Web, chacun associé à un pourcentage de part de marché total. Veuillez noter que vous devez tenir cette feuille de calcul à jour ; la mise à jour une fois par mois devrait suffire.

Vous êtes maintenant prêt à vous lancer dans l'attaque en trois phases.

1. Reconnaissance : trouver des bogues indépendants du navigateur

Bien avant même de penser à sortir un appareil sur lequel tester, faites la chose la plus simple possible : ouvrez votre application Web dans votre navigateur préféré. À moins que vous ne soyez un masochiste complet, il s'agit probablement de Chrome ou de Firefox, qui sont tous deux stables et prennent en charge les fonctionnalités modernes. Le but de cette première étape est de trouver des bugs indépendants du navigateur .

Les bogues indépendants du navigateur sont des erreurs d'implémentation qui n'ont rien à voir avec le navigateur ou le matériel utilisé pour accéder à votre application. Par exemple, supposons que votre page Web soit mise en ligne et que vous commenciez à recevoir des rapports de bogues obscurs de la part de personnes se plaignant que votre page semble nulle sur leur HTC One en mode paysage. Vous perdez beaucoup de temps à déterminer quelle version de quel navigateur a été utilisée, à utiliser le mode de débogage USB d'Android et à rechercher de l'aide sur StackOverflow, en vous demandant comment diable vous allez résoudre ce problème. À votre insu, ce bogue n'a rien à voir avec l'appareil : votre page semble boguée à une certaine largeur de la fenêtre d'affichage, qui se trouve être la largeur de l'écran de l'appareil en question.

Il s'agit d'un exemple de bogue indépendant du navigateur qui s'est faussement manifesté comme un bogue spécifique au navigateur ou à l'appareil. Vous avez été entraîné sur un chemin long et inutile, avec des rapports de bogues agissant comme du bruit, obscurcissant la cause première du problème. Faites-vous une faveur et attrapez ce genre de bogue dès le début, avec beaucoup moins d'efforts et un peu plus de prévoyance.

En corrigeant les bogues indépendants du navigateur avant même de commencer les tests inter-navigateurs, nous devrions être confrontés à moins de bogues dans l'ensemble. J'aime appeler cela l' effet de fonte de l'iceberg . Nous faisons fondre les insectes cachés sous la surface, nous évitant de nous écraser et de nous noyer dans l'océan - et nous ne réalisons même pas que nous le faisons.

Vous trouverez ci-dessous une courte liste de choses que vous pouvez faire dans votre navigateur de développement pour découvrir les bogues indépendants du navigateur :

• Essayez de redimensionner pour voir la réactivité. Y avait-il un point d'arrêt génial quelque part?
• Zoom avant et arrière. Les positions d'arrière-plan de votre sprite d'image ont-elles été renversées ?
• Voyez comment l'application se comporte avec JavaScript désactivé. Recevez-vous toujours le contenu de base ?
• Voyez à quoi ressemble l'application avec CSS désactivé. La sémantique du balisage a-t-elle encore un sens ?
• Essayez de désactiver JavaScript ET CSS. Vivez-vous une expérience acceptable ?
• Essayez d'interagir avec l'application en utilisant uniquement votre clavier. Est-il possible de naviguer et de voir tout le contenu ?
• Essayez de limiter votre connexion et voyez à quelle vitesse l'application se charge. Quel est le poids du chargement de la page ?

Avant de passer à la phase 2, vous devez corriger les bugs que vous avez rencontrés. Si nous ne corrigeons pas les bogues indépendants du navigateur, nous ne ferons que signaler ultérieurement de nombreux faux bogues spécifiques au navigateur.

Être fainéant. Corrigez les bogues indépendants du navigateur. Ensuite, nous pouvons passer à la deuxième phase de l'attaque.

2. Raid : testez d'abord dans les navigateurs à haut risque

Lorsque nous corrigeons des bogues, nous devons veiller à ce que nos correctifs n'introduisent pas d'autres bogues. Ajuster notre CSS pour corriger le rembourrage dans Safari peut casser le rembourrage dans Firefox. L'optimisation de ce morceau de JavaScript pour qu'il s'exécute plus facilement dans Chrome pourrait le casser complètement dans IE. Chaque changement que nous apportons comporte des risques.

Pour être vraiment sûr que les nouveaux changements n'ont pas interrompu l'expérience dans l'un des navigateurs que nous avons déjà testés, nous devons revenir en arrière et tester à nouveau dans ces mêmes navigateurs. Par conséquent, pour minimiser la duplication des efforts, nous devons être intelligents dans la façon dont nous testons.

Analyse statistique de la distribution des bugs

Considérez le tableau suivant, où l'icône en forme de croix signifie que le navigateur a le bogue.

Disons que nous devons tester notre contenu par ordre croissant de risque : navigateur à faible risque, navigateur à risque moyen, navigateur à haut risque. Si cela vous aide à visualiser cela, ces navigateurs peuvent correspondre à Google Chrome, IE 9 et IE 6 respectivement.

En testant d'abord le navigateur à faible risque (Chrome), nous trouverions et corrigerions le bogue n°2. Lorsque nous passons au navigateur à risque moyen, le bogue #2 est déjà corrigé, mais nous découvrons un nouveau bogue : #4. Nous modifions notre code pour corriger le bogue - mais comment pouvons-nous être sûrs que nous n'avons pas cassé quelque chose dans le navigateur Low Risk ? Nous ne pouvons pas être complètement sûrs, nous devons donc revenir en arrière et tester à nouveau dans ce navigateur pour vérifier que tout fonctionne toujours comme prévu.

Passons maintenant au navigateur à haut risque et trouvons les bogues n° 1, n° 3 et n° 5, nécessitant une refonte importante pour être corrigés. Une fois ceux-ci corrigés, que devons-nous faire ? Revenez en arrière et testez à nouveau les navigateurs à risque moyen et faible. C'est beaucoup de duplication d'efforts. Nous avons dû tester nos trois navigateurs six fois au total.

Considérons maintenant ce qui se serait passé si nous avions testé notre contenu par ordre décroissant de risque.

Dès le départ, nous trouverions les bogues n° 1, n° 3, n° 4 et n° 5 dans le navigateur à haut risque. Après avoir corrigé ces bogues, nous passerions directement au navigateur à risque moyen et découvririons le bogue n ° 2. Comme auparavant, ce correctif peut avoir indirectement cassé quelque chose, il est donc nécessaire de revenir au navigateur à haut risque et de refaire le test. Enfin, nous testons dans le navigateur Low Risk et ne découvrons aucun nouveau bogue. Dans ce cas, nous avons testé nos trois navigateurs à quatre reprises au total, ce qui représente une grande réduction du temps nécessaire pour découvrir et corriger efficacement le même nombre de bogues et valider le comportement du même nombre de navigateurs . .

Il peut y avoir une pression sur les développeurs pour qu'ils testent d'abord dans les navigateurs les plus populaires, en descendant vers les navigateurs les moins utilisés vers la fin de nos tests. Cependant, les navigateurs populaires sont susceptibles d'être des navigateurs à faible risque.

Vous savez que vous devez prendre en charge un navigateur à haut risque donné, alors éliminez ce navigateur dès le début. Ne gaspillez pas vos efforts à tester les navigateurs qui sont moins susceptibles de générer des bogues, car lorsque vous passez à des navigateurs qui génèrent plus de bogues, vous n'aurez qu'à revenir en arrière et à revoir ces navigateurs à faible risque.

La correction des bogues dans les mauvais navigateurs rend votre code plus résistant dans les bons navigateurs

Souvent, vous constaterez que les bogues qui surviennent dans ces navigateurs problématiques sont le résultat inattendu d'un code médiocre de votre part. Vous avez peut-être maladroitement stylisé un div pour qu'il ressemble à un bouton, ou piraté un setTimeout avant de déclencher un comportement arbitraire ; de meilleures solutions existent pour ces deux problèmes. En corrigeant les bogues qui sont les symptômes d'un mauvais code, vous corrigerez probablement des bogues dans d'autres navigateurs avant même de les voir. Il y a encore cet effet d' iceberg qui fond .

En vérifiant la prise en charge des fonctionnalités, plutôt que de supposer qu'un navigateur prend en charge quelque chose, vous corrigez ce bogue douloureux dans IE8, mais vous rendez également votre code plus robuste pour d'autres environnements difficiles. En fournissant cette image de secours pour Opera Mini, vous encouragez l'utilisation de l'amélioration progressive et, en tant que sous-produit, vous améliorez votre produit même pour les utilisateurs de navigateurs qui coupent la moutarde. Par exemple, un appareil mobile peut perdre sa connexion 3G avec seulement la moitié des actifs de votre application téléchargés : l'utilisateur bénéficie désormais d'une expérience significative qu'il n'aurait pas eue auparavant.

Attention cependant : si vous ne faites pas attention, la correction de bogues dans des navigateurs obscurs peut aggraver votre code . Résistez à la tentation de renifler la chaîne de l'agent utilisateur pour fournir conditionnellement du contenu à des navigateurs spécifiques, par exemple. Cela pourrait résoudre le bogue, mais c'est une pratique totalement insoutenable. Ne compromettez pas l'intégrité d'un bon code pour prendre en charge les navigateurs maladroits.

Identification des navigateurs problématiques

Alors, qu'est - ce qu'un navigateur à haut risque ? La réponse est un peu floue et dépend des fonctionnalités du navigateur utilisées par votre application. Si votre JavaScript utilise indexOf , il peut se casser dans IE 8. Si votre application utilise position: fixed , vous voudrez le vérifier dans Safari sur iOS 7.

Puis-je utiliser est une ressource inestimable et un bon point de départ, mais c'est l'un de ces domaines qui vient encore une fois de l'expérience et de l'intuition des développeurs. Si vous déployez régulièrement des applications Web, vous saurez quels navigateurs signalent des problèmes à maintes reprises, et vous pourrez affiner votre stratégie de test en conséquence.

La chose utile à propos des bogues que vous trouvez dans les navigateurs problématiques est qu'ils se propagent souvent. S'il y a un bogue dans IE9, il y a de fortes chances que le bogue existe également dans IE8. Si quelque chose a l'air funky sur Safari sur iOS 7, il sera probablement encore plus prononcé sur iOS 6. Remarquez un modèle ici ? Les navigateurs plus anciens ont tendance à être ceux qui posent problème. Cela devrait vous aider à dresser une assez bonne liste de navigateurs problématiques.

Cela étant dit, sauvegardez - les avec des statistiques d'utilisation. Par exemple, IE 6 est un navigateur très problématique, mais nous ne prenons pas la peine de le tester car sa part de marché totale est trop faible. Le temps passé à corriger les bogues spécifiques à IE6 ne vaudrait pas la peine pour le petit nombre d'utilisateurs dont l'expérience serait améliorée.

Ce ne sont pas toujours les anciens navigateurs que vous voudrez tester lors de la phase de raid. Par exemple, si vous avez un projet de canevas WebGL 3D expérimental avec une image de secours, les anciens navigateurs n'obtiendront que l'image de secours, il est donc peu probable que nous rencontrions de nombreux bogues. Ce que nous voudrions faire à la place, c'est changer notre choix de navigateur problématique en fonction de l'application à portée de main. Dans ce cas, IE9 pourrait être un bon navigateur à tester car c'est la première version d'IE qui prend en charge canvas.

Les navigateurs proxy modernes (tels que Opera Mini) peuvent également être un bon choix pour un test de raid, si votre application utilise des fonctionnalités CSS3 telles que les dégradés ou le rayon de bordure. Une erreur courante consiste à afficher du texte blanc sur un dégradé non pris en charge, ce qui entraîne un texte blanc sur blanc illisible.

Lorsque vous choisissez vos navigateurs problématiques, utilisez votre intuition et essayez d'anticiper où les bogues pourraient se cacher.

Diversifiez vos navigateurs problématiques

Les navigateurs et les versions de navigateur ne sont qu'une partie de l'équation : le matériel est également une considération importante. Vous souhaiterez tester votre application sur différentes tailles d'écran et différentes densités de pixels, et essayer de basculer entre les modes portrait et paysage.

Il peut être tentant de regrouper les navigateurs associés car il y a une réduction perçue sur le coût de l'effort. Si vous avez déjà VirtualBox ouvert pour tester IE8, le moment peut sembler être le bon moment pour tester également IE9, IE10 et IE11. Cependant, si vous en êtes aux premiers stades du test de votre application Web, vous voudrez combattre cette tentation et choisir à la place trois ou quatre combinaisons navigateur-matériel qui sont nettement différentes les unes des autres, pour obtenir autant de couverture sur le total espace de bogue que vous le pouvez.

Bien que ceux-ci puissent varier d'un projet à l'autre, voici mes navigateurs problématiques actuels :

• IE 8 sur une machine virtuelle Windows XP ;
• navigateur natif Android 2 sur une tablette Android de milieu de gamme ;
• Safari sur un iPhone 4 exécutant iOS 6 ;
• Opera mini (ne vaut vraiment la peine d'être testé qu'avec du contenu qui devrait fonctionner sans JavaScript, comme les datapics).

Être fainéant. Trouvez autant de bogues que possible en lançant votre application sur vos navigateurs et appareils pris en charge les plus problématiques. Une fois ces bugs corrigés, vous pouvez alors passer à la phase finale de l'attaque.

3. Autorisation : vérification de la santé mentale

Vous avez maintenant testé votre application dans les navigateurs les plus difficiles que vous devez prendre en charge, en espérant attraper la majorité des bogues. Mais votre application n'est pas encore complètement exempte de bogues. Je suis constamment surpris de voir à quel point même les dernières versions de Chrome et de Firefox rendront le même contenu différent. Vous devez encore faire d'autres tests.

C'est cette vieille règle 80:20. Au sens figuré, vous avez corrigé 80 % des bogues après avoir testé 20 % des navigateurs. Maintenant, ce que vous voulez faire, c'est vérifier l'expérience de 80 % de votre public en testant 20 % de navigateurs différents.

Prioriser les navigateurs

L'approche simple et évidente consiste maintenant à revenir aux tests multi-navigateurs "traditionnels", en abordant chaque navigateur par ordre décroissant de part de marché. Si le bureau Chrome se trouve être la plus grande proportion de la part de navigateur de votre public, suivi de Safari sur iOS 8, suivi d'IE11, alors il est logique de tester dans cet ordre, n'est-ce pas ?

C'est un système largement équitable, et je ne veux pas trop compliquer cette étape si vos ressources sont déjà sollicitées. Cependant, le fait est que tous les navigateurs ne sont pas créés égaux. Dans mon équipe, nous regroupons les navigateurs selon un arbre de décision qui prend en compte l'utilisation du navigateur, la facilité de mise à niveau et si le navigateur est ou non le système d'exploitation par défaut.

Jusqu'à présent, votre feuille de calcul devait comporter une colonne pour le navigateur et une colonne pour sa part de marché ; vous avez maintenant besoin d'une troisième colonne, désignant la priorité à laquelle appartient le navigateur. À vrai dire, ce travail de priorisation aurait dû être fait avant de lancer l'attaque en trois phases, mais pour les besoins de cet article, il était plus logique de le décrire ici car les priorités ne sont pas vraiment nécessaires avant la phase de dégagement.

Voici notre arbre de décision :

Nous avons conçu notre arbre de décision de manière à ce que les navigateurs P1 couvrent environ 70 % de notre audience. Les navigateurs P1 et P2 combinés couvrent environ 90 % de notre audience. Enfin, les navigateurs P1, P2 et P3 nous offrent une couverture d'audience presque complète. Notre objectif est de tester dans tous les navigateurs P1, suivi de P2, suivi de P3, par ordre décroissant de part de marché.

Comme vous pouvez le voir dans la feuille de calcul plus haut dans cet article, nous n'avons qu'une poignée de navigateurs P1. Le fait que nous puissions vérifier si rapidement l'expérience de plus de 70 % de notre public signifie que nous n'avons aucune excuse pour ne pas re-tester dans ces navigateurs si la base de code change. Au fur et à mesure que nous passons aux navigateurs P2 et P3, nous devons déployer des efforts toujours croissants pour vérifier l'expérience d'une audience de plus en plus réduite, nous devons donc définir des idéaux de test plus réalistes pour les navigateurs de moindre priorité. À titre indicatif :

• P1 . Nous devons vérifier l'intégrité de ces navigateurs avant de nous déconnecter de l'application. Si nous apportons de petites modifications à notre code, nous devons alors vérifier à nouveau l'intégrité de ces navigateurs.
• P2 . Nous devrions vérifier l'intégrité de ces navigateurs avant de nous déconnecter de l'application. Si nous apportons des modifications importantes à notre code, nous devons alors vérifier à nouveau l'intégrité de ces navigateurs.
• P3 . Nous devrions vérifier l'intégrité de ces navigateurs une fois, mais seulement si nous avons le temps.

N'oubliez pas la nécessité de diversifier votre matériel. Si vous êtes en mesure de tester sur une multitude de tailles d'écran différentes et sur des appareils avec des capacités matérielles variables tout en suivant cette liste, faites-le.

Résumé : l'attaque en trois phases

Une fois que vous avez fait l'effort de connaître votre ennemi (en simplifiant vos statistiques d'audience et en regroupant les navigateurs par priorités ), vous pouvez attaquer en trois étapes :

1. Reconnaissance : tests exploratoires sur votre navigateur préféré, pour trouver des bugs indépendants du navigateur .
2. Raid : tests sur vos navigateurs pris en charge les plus problématiques sur une variété de matériels, pour trouver la majorité des bugs .
3. Autorisation : vérification de l'expérience de votre application sur les navigateurs les plus utilisés et stratégiquement importants, pour dire avec une confiance quantitativement soutenue que votre application fonctionne .