Catégories
Start-up et applications

Revenez à la partie amusante des tests

Dans un monde idéal, les tests logiciels consistent à mettre en lumière des informations vitales afin que nos équipes puissent fournir des produits incroyables qui développent l'entreprise (pour paraphraser James Bach). L'enquête et l'exploration sont au cœur des tests. L'obsession de découvrir les défauts critiques avant qu'ils ne se transforment en problèmes commerciaux est ce qui nous prend sous la peau et nous donne envie de répondre à toutes ces questions «et si…» avant d'envoyer chaque version dans le monde.

Mais avant que l'exploration puisse commencer, un certain travail est nécessaire. Si vous traquez des insectes littéraux dans la nature sauvage, vous ne ressentirez aucune satisfaction tant que vous n'aurez pas vérifié les prévisions météorologiques, étudié vos cartes et guides de terrain, vous être équipé, enduit de crème solaire et de répulsif contre les moustiques, et le faire. sur le terrain. Si vos terrains de chasse métaphoriques sont en fait des applications logicielles, ces tâches banales sont appelées «vérification». Cela inclut à la fois le travail par cœur de s'assurer que rien ne s'est cassé lors de la dernière modification du code (test de régression) et que les principes de base de l'exigence sont réellement satisfaits (test de progression).

CONTENU CONNEXE: Tester dans un monde numérique complexe

Ce travail est rarement décrit comme «amusant». Ce n’est pas ce qui nous pousse à traverser ces chasses aux insectes de fin de soirée (avec des pizzas et des boissons de choix). Alors que faisons-nous? Nous l'automatisons! Maintenant, nous parlons… Il y a toujours une joie primordiale à créer quelque chose, et l'automatisation n'est pas différente. La précipitation que vous obtenez lorsque votre curseur se déplace, la demande est envoyée, l'API est appelée… tout cela sans que vous bougiez un doigt… peut vous faire sentir satisfait. Puissant, même. Pendant un instant, l'application est votre univers et vous en êtes le maître.

Vous poussez maintenant un soupir de soulagement et vous relevez les pieds, satisfaits de vos efforts. Demain est désormais clair pour être consacré à l'exploration. Retour à la chasse aux insectes! Le lendemain, vous ouvrez votre ordinateur portable, prêt à retrousser vos manches et à plonger dans les choses amusantes. Mais qu'est-ce que c'est? Échec de construction? Impressionnant! Votre travail porte déjà ses fruits. Vos contrôles automatisés ont déjà révélé certains problèmes… ou les ont-ils?

Non, pas vraiment. C'était juste un changement XPath. Aucun problème; tu ne feras pas cette erreur à nouveau. Vous corrigez le problème et relancez les tests. Attendez, cet élément a un ID dynamique? Depuis quand? Ok ok ok… très bien! Vous prononcez l'incantation et invoquez le pouvoir arcanique de Regex, priant silencieusement que vous n'ayez plus jamais à déboguer cette partie de votre test. À un moment donné, vous jetez un coup d'œil à l'horloge. Un autre jour s'est écoulé sans temps pour une véritable exploration. Ce travail n'était pas amusant. C'était frustrant. Vous n'êtes plus le maître de cet univers, mais un éternel serviteur au gré d'une liste toujours croissante de tests floconneux et capricieux.

Il s’avère que le truc pour surmonter tout le travail époustouflant n’est pas de déjouer l’automatisation traditionnelle des tests de l’interface utilisateur basée sur des scripts que tout le monde lutte depuis des années. Il fait appel à une automatisation intrinsèquement plus intelligente – une automatisation qui comprend ce que vous en avez besoin pour vous concentrer sur ce que vous voulez réellement faire: explorer!

Avec la dernière génération d'automatisation de test basée sur l'IA basée sur la reconnaissance optique, vous pouvez déléguer toute la logistique de l'automatisation à une machine, afin que vous puissiez vous concentrer sur les aspects créatifs qui font réellement le succès d'un produit. (Divulgation complète: plusieurs entreprises proposent une automatisation des tests d'interface utilisateur basée sur l'IA basée sur la reconnaissance optique … et je dirige le développement de cette technologie chez l'une d'entre elles.)

L'idée derrière cette approche est d'exploiter un moteur capable de comprendre et de piloter l'interface utilisateur comme le ferait un humain. Ce comportement humain est simulé à l'aide de diverses stratégies d'IA et d'apprentissage automatique (par exemple, des réseaux de neurones à convolution profonde combinés à des heuristiques avancées) pour fournir une automatisation de l'interface utilisateur stable, auto-réparatrice et indépendante de la plate-forme.

Du point de vue du testeur, vous fournissez une description en langage naturel des actions à effectuer, et le moteur traduit cela en interactions d'interface utilisateur appropriées. Les éléments de l'interface utilisateur sont identifiés en fonction de leur apparence plutôt que de leurs propriétés techniques. Si un élément de l'interface utilisateur est repensé ou si l'application entière est réimplémentée à l'aide d'une nouvelle technologie, cela n'a aucune importance. Comme un humain, l'automatisation le comprendra simplement et s'adaptera.

S'assurer que cela fonctionne avec la vitesse et la précision nécessaires pour toutes les technologies que vous devez tester est la partie la plus difficile, mais c'est notre travail, pas votre problème. Vous pouvez simplement retrousser vos manches, lui dire ce que vous voulez tester et laisser l'automatisation s'occuper du reste. Ensuite, le plaisir peut commencer.

Voici deux façons principales par lesquelles cette approche «d'automatisation des tests d'interface utilisateur basée sur l'IA» vous aide à revenir à la partie amusante des tests …

Automatisation sans aggravation
Je ne suis pas étranger à l’automatisation. Je travaille dans l’automatisation depuis plus d’une décennie, en gérant des équipes d’automatisation, en mettant en œuvre l’automatisation et même en travaillant sur le projet Selenium. Construire une automatisation stable au niveau technique est invariablement fastidieux, peu importe ce que vous automatisez. Et mis à part certains principes directeurs de très haut niveau tels que la séparation des préoccupations, l'abstraction des données et les modèles de conception, votre maîtrise de l'automatisation d'une technologie ne se traduit pas vraiment lorsqu'il est temps d'en automatiser une autre.

Piloter automatiquement un navigateur ou une interface mobile est très différent de «piloter» une application de bureau, un mainframe ou une application personnalisée / packagée hautement spécialisée. Des technologies telles que l'automatisation des tests basés sur des modèles éliminent la complexité, en ajoutant une couche d'abstraction qui vous permet de travailler au niveau de la couche métier plutôt que de la couche technique. Cependant, il n’est pas toujours possible d’appliquer des approches basées sur des modèles à des applications extrêmement anciennes, des applications exécutées sur des environnements distants (par exemple, accessibles via Citrix), des applications hautement spécialisées pour votre entreprise / secteur, etc.

Avec l'automatisation des tests basés sur l'image, la technologie sous-jacente n'est pas pertinente. Si vous pouvez exercer l'application via une interface utilisateur, vous pouvez créer une automatisation pour celle-ci. Pas de script. Pas de courbe d'apprentissage. Il suffit de l'exercer naturellement – comme vous le faites probablement déjà lorsque vous vérifiez chaque nouvelle user story – et vous pouvez obtenir toute la répétabilité et l'évolutivité de l'automatisation sans aucun travail ni tracas.

Syndrome de Stockholm technologique
À l’époque où j’étais étudiant à l’université, j’ai «appris» que rien ne serait jamais développé qui ne soit un gros client lourd en C. On a parlé de clients légers, mais bien sûr, cela ne durerait pas. Après avoir obtenu mon diplôme, tout le monde se démenait pour réécrire ses gros clients en utilisant la nouvelle architecture brillante orientée services. Puis vint le mobile. Et la conteneurisation et Kubernetes.

À ce moment-là, j’ai compris que j’avais un problème: appelons cela le syndrome de Stockholm technologique. J'ai été captivé par le paysage en constante évolution de la technologie. Et ce qui est étrange, c'est que j'aimais ça parce que cet ensemble de poteaux de but en constante évolution était tellement amusant.

C’est un bon problème pour garantir la valeur et la viabilité continues des applications de votre organisation. Vous voulez que vos équipes de développement restent au fait des dernières tendances et tirent parti des nouvelles approches qui améliorent la flexibilité, la fiabilité, la sécurité et la vitesse des applications. Mais si vous êtes responsable de la construction et de la maintenance de l'automatisation des tests, chaque changement peut être une torture. Dans la plupart des cas, un changement technique signifie que vous devez abandonner l’automatisation des tests existante (ce qui représente probablement un investissement important en temps et en ressources) et recommencer en reconstruisant ce qui est essentiellement la même chose à partir de zéro. Pas drôle.

De plus, ce n'est plus vraiment nécessaire. Vous seriez surpris du peu de fondamental les modifications sont introduites dans l'interface utilisateur d'une application de génération en génération. (Vous ne le croyez pas? Il vous suffit de revenir dans l’historique Web sur La machine de retour et voyez par vous-même.)

Bien que l'implémentation sous-jacente et l'aspect spécifique puissent changer radicalement, la plupart des mêmes séquences de test de base s'appliquent généralement (par exemple, entrez maxmusterman en dessous de Nom d'utilisateur, entrer 12345 en dessous de mot de passe, et cliquez sur le s'identifier bouton). Si ces mêmes actions générales restent valides, alors l'automatisation de test basée sur l'image devrait toujours être en mesure d'identifier les éléments d'interface utilisateur appropriés et de terminer l'ensemble d'actions requis.

Vous vous souvenez du mantra de Java «écrire une fois, exécuter n'importe où»? » (Allez-y, insérez votre propre blague Java ici). Bien faite, cette approche de test devrait réellement tenir cette promesse. Bien sûr, vous voudrez probablement ajouter / étendre / élaguer certains tests au fur et à mesure que l'application évolue de génération en génération, mais vous n'avez certainement pas besoin de commencer avec une ardoise vierge chaque fois que l'application est optimisée ou restructurée.

Au fond, les tests sont vraiment amusants
L'automatisation des tests d'interface utilisateur est indéniablement un élément essentiel d'une stratégie de test d'entreprise mature. Mais lutter avec tous les petits morceaux et octets de celui-ci n’est amusant pour personne. Faites des recherches parmi les ingénieurs, les testeurs professionnels, les utilisateurs professionnels et toutes sortes d'autres parties prenantes du projet, et je vous garantis que vous ne trouverez pas n'importe qui avec un désir ardent de s'en occuper. Mais les tests en tant que discipline, en tant que processus créatif de résolution de problèmes, sont vraiment amusants.

Décollez les couches de scripts, de flocons et d'échecs constants, et vous pouvez (re) vous concentrer sur l'expérimentation, l'exploration, le questionnement, la modélisation… tout ce qui le rend amusant et épanouissant.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *