Qu'est-ce que le test de navigateur sans tête, quand (et pourquoi) l'utiliser

Les tests de navigateur sans tête améliorent à la fois l'efficacité et l'efficience de votre processus de test tout en intégrant l'assurance qualité à la livraison de logiciels.

En fin de compte, les seuls tests qui comptent sont les tests de bout en bout basés sur l'interface utilisateur . Ce sont les tests qui commencent et se terminent par les interfaces de l'application et prouvent que l'application – avec tous ses événements, files d'attente et microservices – permet aux parties prenantes d'atteindre tous leurs objectifs.

Mais il existe des problèmes inhérents à l'interface utilisateur. tests pilotés. La stabilité en est une: même lorsque l'application fonctionne correctement, les tests pilotés par l'interface utilisateur échouent parfois lors de l'interaction avec le navigateur. L'autre problème est la performance: les tests basés sur l'interface utilisateur sont sloooooooowwww par rapport à d'autres types de tests automatisés.

Qu'est-ce que le test de navigateur sans tête?

Il existe une solution: le test de navigateur sans tête. L'automatisation du navigateur Headless utilise un navigateur Web pour les tests de bout en bout, mais ignore le chargement de l'interface utilisateur des navigateurs. Cela signifie que la page HTML testée n'est pas rendue (donc tout s'exécute plus rapidement) et que vos tests évitent d'interagir avec la page pour manipuler le navigateur plus directement (en éliminant les échecs dus aux interactions liées à l'interface utilisateur). Vos tests de bout en bout sont à la fois plus efficaces et plus fiables. Si les performances ou la stabilité sont les raisons pour lesquelles vous avez évité les tests de bout en bout basés sur l'interface utilisateur, l'automatisation du navigateur sans tête peut vous permettre d'ajouter des tests de bout en bout à votre processus de test.

Mais les tests de navigateur sans tête ne doivent pas être considérés comme un simple remplacement des tests basés sur l'interface utilisateur. Les tests de navigateur sans tête créent de nouvelles opportunités en vous permettant d'adopter une réflexion de conception «shift-gauche» et de passer à l'intégration de l'assurance qualité (QA) dans votre processus de livraison de logiciels (ce que l'on appelle «QAOps»). L'effet net est que le «test de navigateur sans tête» rend non seulement vos tests plus efficaces, mais aussi plus efficace.

Et, au fait, le «test de navigateur sans tête» est une bouchée. Utilisons simplement les «tests sans tête».

Les opportunités

Les problèmes de stabilité et de performances associés aux tests de bout en bout basés sur l'interface utilisateur signifient que les tests de bout en bout sont généralement effectués moins fréquemment que les autres tests— souvent seulement à la fin du processus de développement, juste avant la publication dans le cadre du processus d'assurance qualité. Cela a, au moins, deux résultats malheureux: tous les problèmes découverts par les tests de bout en bout sont découverts très tard dans le processus de test, et une division est créée entre la livraison du logiciel et les processus d'assurance qualité.

Voici où les étapes des tests sans tête en. En n'invoquant pas le moteur de rendu du navigateur, un test de navigateur headless peut s'exécuter de deux à dix fois plus rapidement que le test équivalent piloté par l'interface utilisateur. Cette amélioration de la vitesse vous permet de déplacer les tests de bout en bout vers la gauche, de les sortir des tests de pré-publication et de les faire passer aux tests nocturnes. Vos tests deviennent plus efficaces en permettant aux développeurs d'identifier et de résoudre les problèmes plus tôt. Si vous effectuez déjà des tests de bout en bout dans le cadre de vos tests nocturnes, vous avez la possibilité de libérer des ressources actuellement absorbées par les tests pilotés par l'interface utilisateur – vos tests deviennent plus efficaces.

Bien que plus rapide, c'est mieux. , ce mouvement n'est possible que parce que les tests headless, en contournant l'interface utilisateur du navigateur, améliorent également la stabilité du test. Cette stabilité compte: bien que les tests de pré-publication soient assez rares pour permettre une certaine instabilité, c'est un axiome que rien (répéter: rien ) ne peut perturber la construction nocturne.

Déplacement des tests de bout en bout à vos exécutions nocturnes signifie que ce qui faisait autrefois partie du processus de contrôle qualité de la pré-version a maintenant été intégré dans le processus de livraison du logiciel. Le résultat est de réduire la division entre les deux équipes et de commencer à créer une mentalité QAOps.

Les coûts

Il y a cependant des coûts de conversion. L'un des avantages des tests pilotés par l'interface utilisateur est la création de scripts utilisateur: les utilisateurs peuvent générer des tests qui sont significatifs pour eux en interagissant avec l'application pour créer des scripts de test (y compris la validation des résultats) sans nécessairement s'appuyer sur les frameworks de test . Une assistance pour les développeurs reste cependant nécessaire, car il s’agit d’un environnement inhabituel dans lequel les scripts de l’utilisateur final gèrent tous les tests requis.

Autre bonne nouvelle: les tests de navigateur Headless peuvent utiliser vos scripts générés par l’utilisateur final. Cependant, tous les tests générés par les développeurs qui font partie de vos tests de bout en bout devront être réécrits pour fonctionner dans l'environnement «headless». Les développeurs qui écrivent des tests pour l'environnement headless devront développer de nouvelles compétences.

Ce serait également une erreur de penser que les tests headless vous permettront d'abandonner les tests pilotés par l'interface utilisateur. Comme le stratège de la modernisation Jim Holmes l'a reconnu en 2013, «Le démarrage d'une session de navigateur ralentit en effet les tests… mais [headless tests] ne remplace pas les tests fonctionnels basés sur le navigateur. Le but des tests d'interface utilisateur fonctionnelle est de s'assurer que votre application fonctionne dans les différents navigateurs avec toutes leurs bizarreries et «  personnalités '' uniques. Les tests sans tête sont un excellent test de niveau d'intégration rapide, mais vous ne devez pas ignorer les tests de navigateur complets. . ”

Beaucoup de choses se sont passées depuis lors, y compris l'adoption de Chromium comme base pour de nombreux navigateurs, mais le point de Jim tient toujours. En fait, des produits tels que Telerik Test Studio font toujours de ce message une priorité – les tests pilotés par l'interface utilisateur et les tests de navigateur sans tête sont importants et devraient aller de pair – et Test Studio prendra en charge les deux tests avec capacités pour les utilisateurs techniques et moins techniques à partir de la version R1 2021.

Étant donné que les tests pilotés par l'interface utilisateur et les tests de navigateur sans tête sont des tests de bout en bout, il y aura presque certainement un chevauchement des tests entre les deux ensembles de des tests. En soi, ce n’est pas nécessairement une mauvaise chose. Le coût le plus élevé étant les tests redondants lorsque les deux ensembles de tests sont exécutés ensemble. Si cette inefficacité vous dérange, vous pouvez y remédier en sautant les tests sans tête pendant le processus de pré-publication (après tout, le code a réussi vos tests sans tête la nuit dernière). Cela ajoute une certaine complexité à la gestion des tests si vous utilisez actuellement le même processus pour vos tests nocturnes et préliminaires.

Les tests de navigateur sans tête offrent des gains d'efficacité qui vous permettent à la fois d'appliquer une réflexion de décalage à gauche et de commencer à implémenter QAOps . En déplaçant les tests de bout en bout plus tôt dans votre processus de développement, vous rendez les tests plus utiles, ce qui est évidemment une bonne chose.

Mais, pour utiliser une phrase qui traîne depuis les années 1930, "Il n'y a pas rien de tel qu'un déjeuner gratuit »: vous devrez engager les ressources du développeur dans la création des tests non scriptés nécessaires et engager les ressources de gestion des tests pour élaborer les processus appropriés pour votre organisation. Heureusement, l'intégration de l'assurance qualité au développement logiciel via QAOps peut aider à fournir les ressources nécessaires.