Comment réussir à automatiser les tests d'interface utilisateur

Lorsqu'il s'agit de choisir les bons outils pour vous aider à réussir les tests d'interface utilisateur automatisés, voici ce que vous devez comprendre.

L'utilisation efficace des tests d'interface utilisateur automatisés ne concerne pas les outils que vous utilisez. Cependant, ne vous méprenez pas: vous allez avoir besoin des bons outils. C'est juste que vous allez avoir besoin du bon ensemble d'outils pour vous .

Pourquoi vous ne pouvez plus ignorer les tests d'interface utilisateur automatisés

Si vous faites partie de ceux qui ont été sceptique quant aux tests automatisés de l'interface utilisateur dans le passé, vous n'êtes ni seul… ni tort. Alors que les outils de test automatisés orientés code sont devenus plus courants, la plupart des ateliers de développement ont ignoré les tests d'interface utilisateur automatisés.

La raison principale en est le coût de maintenance d'une suite de tests d'interface utilisateur. Avec la plupart / tous les outils de test d'interface utilisateur, pratiquement toute modification apportée à l'interface utilisateur d'une application a amené les outils de test d'interface utilisateur à signaler toute l'application comme étant défectueuse. En conséquence, une grande partie du cours de la pratique de développement logiciel moderne a été organisée autour de la séparation précise de l'interface utilisateur du code afin que le code puisse être testé sans toucher à l'interface utilisateur. Et il y a le problème.

La réalité est que vos utilisateurs n'interagissent pas avec votre code: vos utilisateurs interagissent avec votre interface utilisateur. Du point de vue de vos utilisateurs, votre interface utilisateur est votre application. La pratique actuelle consistant à prouver que votre code fonctionne tout en ignorant délibérément l'interface utilisateur manque le point. Contrairement à la pratique actuelle, les tests d'interface utilisateur font une affirmation simple: pour prouver que votre application est «prête pour la production», vous devez prouver que votre interface utilisateur fonctionne et conduit votre application à faire ce qu'il faut.

C'est une affirmation difficile.

Au fur et à mesure que DevOps et la demande de tests d'acceptation par les utilisateurs ont augmenté, cette affirmation est devenue plus importante. Le résultat a été une évolution des outils de test d'interface utilisateur qui rend l'obtention du bon ensemble d'outils à la fois plus difficile et plus facile. Plus difficile car il y a plus de choix; plus facile, car il est plus probable qu'il y ait un outil qui vous convient. Par exemple, lorsque vous examinez les tests d'interface utilisateur, vous pouvez choisir entre des outils sans code et basés sur du code.

Les outils sans code permettent aux testeurs de créer un test d'interface utilisateur en interagissant avec l'application tandis que l'outil génère un script de test en «observant» à la fois le les interactions de l'utilisateur et la réponse de l'application. Ces outils tirent parti du paradigme «L'interface utilisateur est l'application» et n'exigent pas que le testeur en sache plus que l'application (et ses exigences métier associées).

Les outils basés sur le code, par contre, exigent que le testeur écrive un script qui manipule l'interface utilisateur via du code (c'est-à-dire trouver des boutons sur la page, puis extraire les données des éléments de l'interface utilisateur). Ces outils peuvent cependant rechercher des «effets secondaires» qui n'apparaissent pas nécessairement dans une interface utilisateur (ou «toute interface utilisateur accessible dans le cadre du test») et peuvent gérer une plus grande variété de réponses. Les outils basés sur le code exigent que les testeurs sachent coder (pas de surprise là-bas).

Il est évident qu’il n’y a pas une seule bonne réponse ici. Les outils sans code sortent les développeurs du chemin critique des tests et permettent aux utilisateurs de créer des tests qui ont une validité pour eux; les outils basés sur le code prennent en charge des sondes plus approfondies et plus approfondies et gèrent une plus grande variété de réponses, réduisant le nombre de faux négatifs (rapports d'échec lorsque, en fait, l'application fonctionne correctement).

Et, à ce stade, vous pouvez Voyez que cet article, qui a commencé à ressembler à une discussion potentiellement utile, est sur le point de dévier dans un tas de handwaving et de territoire «Tout dépend…»

What Matters

Encore une fois, vous n'avez pas tort. Tous les outils que vous utiliserez devront s'intégrer à vos processus sans vous empêcher de fournir des applications… et le faire tout en atteignant vos objectifs, ceux de votre organisation et de vos utilisateurs. Cela signifie répondre à quelques questions clés.

La première est: Avez-vous besoin de tests d'interface utilisateur automatisés? Il ne faut pas oublier que le but des tests est de transférer les coûts de défaillance de l'environnement de production vers l'environnement de développement. Si votre organisation est à l'aise avec le niveau actuel des échecs de production et ne souhaite pas modifier les pratiques de développement, vous n'aurez peut-être pas besoin de tests d'interface utilisateur automatisés. Comment les tests automatisés de l'interface utilisateur cadrent-ils avec les objectifs stratégiques de votre organisation?

Cette première question chevauche la seconde: Comment les tests automatisés s'intègrent-ils dans la culture de votre organisation? Votre organisation apprécie-t-elle de fournir de nouvelles fonctionnalités aussi rapidement et dès que possible à une communauté d'utilisateurs qui est prête à faire face à un taux de changement élevé, même si cela signifie quelques problèmes? Ou votre organisation valorise-t-elle des applications hautement fiables qui sont stables dans le temps et, par conséquent, peuvent répondre à des normes rigoureuses (peut-être même réglementaires)?

Et cette question, à son tour, recoupe la troisième: Comment les tests automatisés de l'interface utilisateur s'intègreront-ils dans vos processus? Cette réponse commence par où et quand les utilisateurs peuvent faire des tests d'acceptation (peut-être: pas du tout). Une stratégie de test d'interface utilisateur qui exploite vos utilisateurs peut ne pas avoir de sens si, par exemple, il existe une longue histoire d'utilisateurs qui ne sont pas impliqués dans le processus de développement. Cependant, dans votre organisation, si les «tests d'interface utilisateur pilotés par le codeur» sont un oxymore (c'est-à-dire que seuls les utilisateurs finaux peuvent dire si l'interface utilisateur est «correcte»), alors une approche basée sur le codeur ne correspondra pas à votre façon de faire les choses.

Enfin, dernière question: Quels types de compétences et d'outils existants pouvez-vous exploiter? Les tests sans code, par exemple, n'ont de sens que si vous avez un groupe d'utilisateurs qui ne se contentent pas «d'utiliser» une demande, mais sont compétents pour savoir ce qui compte comme une réponse «correcte» ou «incorrecte» à un test. Du côté des développeurs, vous souhaitez examiner la chaîne d’outils utilisée pour fournir votre application. L’exploitation de l’expérience de votre équipe avec cette chaîne d’outils et son intégration présentent de réels avantages pour vous. Il est intéressant de noter que les outils de développement que vous utilisez pour créer vos applications ne sont pas particulièrement critiques lors du choix d'un outil de test d'interface utilisateur, en particulier pour les applications Web.

Suite Success

Cela signifie que vous êtes plus susceptible d'être à la recherche d'une suite de tests pouvant être configurée pour répondre à vos besoins particuliers plutôt qu'un seul «outil de test d'interface utilisateur». Il se peut que vous finissiez par créer vous-même une suite «de premier ordre» qui répond à vos besoins spécifiques, mais il serait évidemment plus pratique d’obtenir une solution complète à partir d’une seule source.

Il n’est donc pas surprenant que les fournisseurs de le domaine des tests d'interface utilisateur automatisés valorise à la fois la flexibilité et la prise en charge de l'intégration avec d'autres outils. Telerik Test Studio par exemple, prend en charge les tests sans code, mais prend également en charge la conversion de ces tests sans code en tests codés, combinant des étapes codées avec des tests sans code et s'intégrant à des bibliothèques tierces pour des besoins particuliers.

La capacité créer des tests sans code signifie que les non-programmeurs (par exemple l'équipe d'assurance qualité ou les utilisateurs finaux) peuvent créer des tests qui démontrent que le système fait ce que les utilisateurs veulent que le système fasse. La possibilité de combiner de manière transparente ces tests sans code avec des tests codés signifie que lorsque des non-programmeurs rencontrent des obstacles, les développeurs peuvent étendre ces tests pour gérer des scénarios «difficiles à automatiser». Les utilisateurs créent les tests qui ont du sens pour eux, et les programmeurs sont sortis du chemin critique, sauf quand ils sont nécessaires.

Mais ne manquez pas le point: il ne s'agit toujours pas des outils – c'est de savoir si ces outils soutenez vos objectifs, vos processus et vos compétences / chaînes d'outils existantes. Si vous comprenez bien de quoi il s'agit, vous êtes en mesure d'obtenir les outils qui vous permettront de réussir les tests d'interface utilisateur automatisés.