Le seul test qui compte: tester à travers les yeux de l'utilisateur

Les tests de bout en bout sont le seul moyen de s'assurer que les applications modernes, distribuées et faiblement couplées fonctionnent réellement. Et il le fait en adoptant une approche positive pour garantir la qualité des applications.

Maintenant que, grâce à Internet, nous sommes tous des utilisateurs finaux, nous sommes parvenus à une nouvelle prise de conscience concernant les tests: si nous, les utilisateurs finaux, avons pour lutter avec l'interface utilisateur, si nous n'obtenons pas les résultats que nous attendons, alors nous ne nous soucions pas de savoir si les tests unitaires, fonctionnels ou de charge ont réussi. Si les utilisateurs finaux disent que l'application ne fonctionne pas alors l'application ne fonctionne pas .

C'est la raison principale pour laquelle nous commençons maintenant à parler de bout en bout (E2E)

Si cela semble égocentrique, nous pouvons le dire autrement: si votre entreprise dépend des utilisateurs qui interagissent avec votre logiciel (et c'est le cas), alors toute faille dans l'interface utilisateur ou les résultats sont mauvais. Seuls les tests E2E le prouvent.

Pourquoi les tests E2E sont importants

Fondamentalement, E2E reflète une maturité croissante dans les tests. Au départ, nous nous inquiétions simplement de la stabilité du système, ce qui était essentiellement une approche négative: «Mon application n'explose-t-elle pas?»

Maintenant que le logiciel est essentiel au succès de notre organisation, nous adoptons une approche plus véritablement positive: "Mon application aide-t-elle nos utilisateurs à atteindre leurs objectifs?" C'est là qu'intervient E2E: les tests E2E prennent un ensemble typique d'interactions qu'un utilisateur suit afin d'atteindre les objectifs de l'utilisateur (le «parcours de l'utilisateur») et vérifie si les objectifs de l'utilisateur sont atteints.

E2E demande au seule question qui compte: "Le système, dans son ensemble, répond-il aux objectifs de l'utilisateur (et du propriétaire)?" Et la seule réponse qui compte vient des parties prenantes du système: l'utilisateur final et l'organisation propriétaire du système. Si l'interface utilisateur ne fonctionne pas comme prévu et ne produit pas les résultats escomptés, le système est en panne. Période.

Cependant, les tests E2E ne consistent pas seulement à obtenir l'approbation des parties prenantes. L'intérêt pour les tests E2E est également motivé par la conception d'applications moderne. Dans un monde qui se compose de plus en plus de clients et de services mal connectés, qui peuvent tous être construits par différentes équipes, prouver que les composants individuels du système fonctionnent n'est, au mieux, qu'une bonne première étape. Vous pouvez voir ce changement dans les explications qui sont déclenchées lorsqu'une application échoue. Dans le mauvais vieux temps, lorsqu'une application échouait, la réponse par défaut était "Eh bien, cela fonctionnait en test." Maintenant, c'est "Eh bien, la demande n'a pas été écrite dans la bonne file d'attente" ou "Le client n'a pas appelé l'API correctement."

Ce qui est différent

Parce qu'E2E change la question de test, il change également la façon dont ce test est fait. De toute évidence, E2E nécessite des tests pour interagir avec l'interface utilisateur d'une application, à la fois pour démarrer le test et pour vérifier les résultats. Pour être utiles, ces tests doivent être suffisamment robustes pour survivre après des changements d'interface utilisateur «typiques».

Mais E2E modifie également l'un des principes de base des tests unitaires: les tests unitaires dépendent de l'isolement du module ou du composant testé. Ce concept d'isolement des composants est si fondamental pour la plupart des tests automatisés qu'il existe même un acronyme à trois lettres: les modules isolés sont le «composant sous test» ou CUT.

E2E adopte l'approche inverse: le test dépend de pas isoler le «composant sous test» mais, au contraire, savoir si tout ce qui est déclenché par les interactions de l'utilisateur donne réellement les résultats.

Ce qui est requis

Cela signifie qu'E2E nécessite des outils qui fonctionnent différemment de votre test unitaire outils. Il y a cinq critères que vous devriez examiner dans votre système d'assistance E2E.

D'abord et avant tout: Vitesse. Celui-ci ne change pas des tests unitaires, mais il est plus difficile à réaliser avec les tests E2E. En production, cela peut prendre des heures (voire des jours) pour qu'une interaction fonctionne dans tout le système. Cependant, sans retour rapide, les tests cessent d'être utiles. Le scénario de test idéal est que, lorsque les développeurs terminent leur code, tous les tests pertinents sont déclenchés, et le développeur obtient des commentaires sur le code qu'il vient de terminer, avant de devoir passer à la tâche suivante (ou de s'ennuyer).

Deuxièmement: Une manière flexible de vérifier les résultats. Vous ne pouvez probablement pas avoir une copie complète du système mise de côté pour chaque équipe qui contribue au système. Les équipes doivent être en mesure de tester avec succès les interactions des utilisateurs qui les intéressent, même si une autre équipe teste un autre ensemble d'interactions.

Troisièmement: Prise en charge de toutes les façons dont les utilisateurs peuvent interagir avec le système. . En plus des clients que vous créez, votre système peut également avoir une interface API que les partenaires commerciaux et les clients peuvent utiliser à partir de leurs propres clients. La bonne nouvelle ici est que vous n'êtes pas obligé de tester les clients de vos partenaires commerciaux… mais vous devez créer les tests E2E qui garantissent que votre API fonctionne comme vous l'avez promis à vos partenaires.

Voici le mauvais news: Vous ne pouvez pas utiliser vos tests API en remplacement des clients que vous créez. Avec les tests E2E, vous ne pouvez pas simplement tester si les API appelées à partir de plates-formes mobiles font la bonne chose. Si vous voulez prouver que le système fonctionne comme les utilisateurs mobiles l'attendent… eh bien, vous devez être en mesure de lancer des tests E2E à partir des clients mobiles (ou quelque chose de très similaire).

Quatrième: Rapports intégrés. Les tests E2E ne signifient pas que vous pouvez sauter d’autres tests. Par exemple, vous devrez toujours effectuer des tests de charge pour vous assurer que votre système reste réactif à mesure que la demande augmente. Et il ne sert à rien de faire des tests E2E si les composants du système ne réussissent pas leurs tests unitaires. Vous devrez intégrer les résultats de tous vos tests dans une interface utilisateur qui rend compte de la qualité du système d'une manière utile à la fois aux développeurs et à la direction.

Si tout cela ressemble à un ensemble intimidant de demandes pour une boîte à outils… eh bien , c'est. Vous allez avoir besoin de plus qu'un simple «outil de test». En conséquence, les fournisseurs du domaine des tests se sont concentrés sur la création de suites de tests qui fournissent l'assistance dont vous avez besoin. Telerik Test Studio démontre cette approche, par exemple, non seulement en prenant en charge les tests E2E rapides et stables (y compris les tests programmés et l'intégration avec les chaînes d'outils DevOps) ainsi qu'un cadre robuste pour exercer les interfaces utilisateur, mais en "Tableau de bord exécutif" qui rassemble les résultats de tous vos tests (unité, charge, E2E, etc.).

Le cinquième (et dernier) critère: Quelle que soit l'infrastructure de test que vous assemblerez, vous devrez être bien adapté à la culture, aux outils, aux compétences et aux processus de votre organisation . Les tests ne sont pas une «chose que vous faites» à la fin du cycle de développement: c'est la partie de votre processus qui garantit que vous fournissez des logiciels que vos utilisateurs apprécient réellement. Et pourquoi voudriez-vous faire autre chose?