Section 4.1: Automatisation assistée

Cette section "Automatisation assistée" se concentre sur l'utilisation et l'application du Deep Learning dans le domaine de l'ingénierie de la qualité.

En dépit des efforts continus du "shift left", certains affirment que l'automatisation des tests d'interface est restée une chimère. L'automatisation des tests fonctionnels doivent être mis en œuvre en cours de sprint dans ce petit laps de temps entre le moment où les développeurs terminent le code final de l'interface utilisateur (avec un build réussi) et le moment où le sprint est censé être terminé. Devinez quoi ? Cela arrive rarement. Au cours du sprint, les équipes peuvent certainement s'attaquer aux tests exploratoires, mais les tests fonctionnels automatisés  ? Ils sont souvent reportés à un sprint ultérieur... et malheureusement souvent abandonnés.

Le test UI est vraiment le type de test le plus intuitif que l'on puisse imaginer. Il suffit de trouver quelqu'un qui peut représenter l'utilisateur cible et de le laisser fouiller dans l'interface qu'il utilise pour son travail quotidien : l'UI. C'est naturel. C'est intuitif. Et c'est encore aujourd'hui la méthode prédominante utilisée pour tester la plupart des versions de logiciels.

Ces tests basés sur l'humain ne doivent jamais cesser. Il est absolument essentiel que des testeurs intelligents explorent l'interface utilisateur en faisant appel à leur esprit créatif et analytique pour découvrir les problèmes qui perturbent l'expérience utilisateur. Mais il est également essentiel d'effectuer un certain nombre de vérifications de routine à chaque changement pour s'assurer que les modifications n'introduisent pas d'effets secondaires étranges. Effectuer ces vérifications fastidieuses à la fréquence et à la vitesse requises serait une torture pour les testeurs humains. D'où l'intérêt de l'automatisation des tests.

On pourrait donc penser que le point de départ naturel de l'automatisation des tests serait d'automatiser tous les tests d'interaction avec l'interface. Ce n'est pas le cas. L'automatisation des tests de l'interface utilisateur est en fait l'une des approches d'automatisation des tests les plus difficiles.

Les tests automatisés au niveau de l'interface utilisateur ont historiquement leur lot de problèmes. Ils sont relativement lents à exécuter. Ils ont une forte propension à ne plus fonctionner. Ils sont quelque peu techniques et fastidieux à créer, même pour les technologies modernes courantes comme le web et le mobile. Ils sont beaucoup plus difficiles à créer lorsque vous devez traiter des applications de bureau personnalisées, des applications packagées, des technologies extrêmement anciennes, des technologies extrêmement nouvelles ou des applications Citrix/à distance. Et la création de tests automatisés de l'interface utilisateur nécessite généralement une interface utilisateur entièrement mise en œuvre et stable.

Il est clair que l'automatisation des tests d'interface utilisateur pose de nombreux problèmes. Mais si vous réfléchissez vraiment à ces problèmes, tout se résume à une chose : l'automatisation des tests ne pense pas comme un humain :

• Un humain peut interagir avec l'interface utilisateur d'une application assez rapidement (l'œil humain peut traiter 24 images par seconde).

• Un humain n'est pas dérangé par les changements d'interface. Quelque chose comme un menu déroulant réimplémenté ou une nouvelle façon d'afficher les résultats ne perturbera pas du tout un testeur humain.

• Un cerveau humain peut interagir avec des technologies extrêmement anciennes (comme les mainframes et les applications basées sur COBOL) et avec n'importe quelle nouvelle technologie qui sortira demain. Et si votre application passe d'une architecture monolithique à une architecture microservices, le cerveau du même testeur peut toujours tester son interface utilisateur exactement de la même manière.

• Un testeur humain peut même ne pas faire la différence si l'application est installée sur sa machine ou si elle est accessible via la virtualisation du bureau (Citrix). Il peut tester l'interface utilisateur de la même manière.

• Un humain n'a pas vraiment besoin d'attendre une implémentation de l'interface utilisateur complètement implémentée (et stable). Il peut commencer à travailler sur ses tests dès qu'un prototype grossier est disponible. Et il peut commencer à effectuer des tests dès que l'interface utilisateur est au moins à peu près prête. Si l'implémentation technique sous-jacente est encore un peu instable, ce n'est pas nécessairement un obstacle.

Donc, si les principaux problèmes liés à l'automatisation des tests de l'interface utilisateur proviennent du fait que l'intelligence humaine est plus adaptable que l'automatisation des tests, pourquoi ne pas essayer de résoudre ces problèmes avec ce qui se fait de mieux : l'intelligence artificielle. En exploitant la puissance de l'IA, nous pouvons obtenir une automatisation des tests de l'interface utilisateur qui soit aussi intelligente et résiliente qu'un humain, mais aussi efficace et évolutive qu'une machine.

Pour que cela fonctionne, la technologie doit apprendre à comprendre et à naviguer dans les interfaces utilisateur de la même manière qu'un humain. Par exemple, elle doit savoir qu'un menu déroulant est un menu déroulant simplement en le "regardant". Cela étant fait, vous - ou tout autre humain, en fait - pouvez définir l'automatisation des tests en fournissant simplement une explication en langage naturel du processus métier à tester (par exemple, "Entrez 10 000 dans la zone de saisie du prix de la liste, cliquez sur le bouton de confirmation, puis..."). L'automatisation des tests pilotée par l'IA peut prendre le relais. Il n'est pas nécessaire de s'occuper des DOM fantômes, des assemblages web, etc. Les tableaux émulés sur SAP peuvent être automatisés sans aucune personnalisation particulière. Il n'y aura pas d'échec la prochaine fois qu'une modification mineure sera apportée à l'interface utilisateur, et vous n'aurez pas à reconstruire vos tests si l'application est réimplémentée dans une nouvelle technologie.

En ce qui concerne le shift left (repositionnement des tests avec le développement), vous pouvez commencer à mettre en œuvre vos tests d'interface utilisateur dès que l'équipe ébauche un prototype ou une maquette. Les conceptions UX avancées comme celle-ci constituent un excellent point de départ :

Mais vous pouvez vraiment commencer n'importe où. Même des esquisses plus rudimentaires sur un tableau blanc ou une serviette de table vous permettraient de commencer l'automatisation des tests de l'interface utilisateur sans attendre l'implémentation réelle. Cela signifie moins de temps d'attente à chaque version et élimine finalement l'effet d'entraînement des retards de test, des histoires inachevées et des "sprints de durcissement". Et cela permet une variante intéressante de TDD : commencer à exécuter ces tests d'interface utilisateur automatisés avant le début de la mise en œuvre, puis demander aux développeurs d'écrire le code qui les fait passer.

Le problème ? Il n'est pas si facile de rendre l'automatisation des tests d'interface utilisateur si simple. Il faut faire attention à deux choses : la précision et la vitesse. Pour que cela fonctionne, la technologie doit être capable de reconnaître avec précision et d'interagir avec des contrôles d'interface utilisateur qu'elle n'a jamais vus auparavant. Cela nécessite une détection visuelle des objets ainsi qu'une reconnaissance optique des caractères (OCR). Et c'est la partie facile ; la partie difficile est de le faire rapidement.

Depuis un certain temps déjà, les solutions d'automatisation basées sur l'IA ont du mal à se rapprocher de la vitesse de traitement humaine. En moyenne, les outils traitent 1,8 image par seconde, alors que les humains peuvent en traiter 25. Il ne faut pas que l'automatisation imite la vitesse humaine, mais qu'elle la dépasse. Si vous voulez que les tests de l'interface utilisateur s'exécutent dans le cadre de vos tests continus en tant que partie intégrante de votre processus CI/CD, ils doivent dépasser de loin la vitesse de l'œil et du cerveau humains.

Depuis sa création dans les années 1950, il s'agit d'une technologie extrêmement coûteuse et sophistiquée. Le domaine de la vision par ordinateur est né de recherches menées dans trois domaines d'étude indépendants, par ordre croissant de complexité : la reproduction de l'œil, la reproduction du cortex visuel et la reproduction du reste du cerveau.

L'objectif de la vision par ordinateur est d'apprendre aux ordinateurs à voir, comprendre et interpréter le contenu et la signification des images numériques, de la même manière - sinon mieux - que les humains. Comme l'explique Adobe dans cet article de 2020, la vision par ordinateur surpasse déjà les performances des humains dans des environnements contrôlés pour des tâches telles que l'imagerie médicale, l'inspection des circuits imprimés et la reconnaissance faciale.

Recréer la vision humaine est un ensemble de problèmes, dont chacun dépend des autres. Plus précisément, la vision par ordinateur est le processus d'extraction, d'analyse et de compréhension automatiques d'informations exploitables à partir d'une image unique ou d'une séquence d'images.

À la fin de cette section, vous aurez une meilleure compréhension de la façon dont la vision par ordinateur peut nous aider à relever les défis de l'automatisation des tests.