Stratégie d'automatisation des tests pour les projets agiles

Cet exemple de stratégie d'automatisation des tests suppose un modèle de livraison continue avec plusieurs équipes agiles.

Dans les articles précédents, une Stratégie de test agile document ainsi que comment configurer une fonction d'assurance qualité à partir de zéro pour un projet agile et comment les tests automatisés sont l'un des éléments clés de la configuration initiale.

Dans cet exemple de stratégie d'automatisation des tests, j'énumère les points clés à prendre en compte pour tirer le meilleur parti de l'effort d'automatisation des tests.




Résumé

Les tests automatisés sont une activité principale de toute méthodologie de développement agile. Alors que nous nous dirigeons vers un déploiement continu, l'automatisation des tests devient de plus en plus importante en raison de la réponse rapide qu'elle fournit à l'équipe de développement sur la santé de l'application.

Afin d'obtenir ce retour d'information rapide, les tests automatisés doivent être exécutés en continu, doivent être rapides et les résultats des tests doivent être cohérents et fiables.


Pour y parvenir, la majorité des vérifications doivent être effectuées dans le cadre du développement de nouvelles fonctionnalités. En d’autres termes, le développement et les tests doivent être une activité cohérente, et la qualité doit être «intégrée» dès le départ en veillant à ce que ce qui est développé fonctionne et qu’il n’a pas brisé les fonctionnalités existantes.

Cela nécessite «d'inverser la pyramide d'automatisation des tests» en poussant vers le bas les tests d'interface graphique qui prennent beaucoup de temps à exécuter, à des niveaux inférieurs, par exemple. Couche API qui peut s'exécuter directement après les tests unitaires dans le cadre de la construction pour fournir le niveau de confiance initial.

En rapport:



Présentation de la stratégie d'automatisation des tests

Prévention plutôt que détection - alors que tous les efforts devraient être consacrés à la prévention de l'introduction de défauts dans l'application en premier lieu, les techniques et les méthodes pour cela sont en dehors de la portée de ce poste. Ici, les méthodologies sont définies pour permettre une détection rapide des bogues lorsqu'ils sont introduits dans le système et un retour au développement.


La qualité doit être privilégiée à la quantité. Dans la plupart des cas, il est préférable de sortir avec une fonctionnalité solide comme un roc plutôt que plusieurs fonctionnalités qui sont irrégulières. En tant que critère de publication minimum, aucune fonctionnalité nouvellement développée ne devrait avoir introduit de défauts de régression.

Comme déjà mentionné, un retour rapide sur la santé de l'application est d'une importance capitale pour soutenir la livraison continue, par conséquent, un processus et un mécanisme par lesquels nous pouvons obtenir rapidement des commentaires sont formulés.

Une façon d'obtenir des commentaires rapides consiste à augmenter le nombre de tests unitaires, de tests d'intégration et de tests d'API. Ces tests de bas niveau fourniront un filet de sécurité pour garantir que le code fonctionne comme prévu et aident à empêcher les défauts de s'échapper dans d'autres couches de test.

Les tests unitaires constituent la base de l'automatisation des tests à des niveaux plus élevés.


Le deuxième élément d'amélioration consiste à exécuter les tests de régression plus fréquemment et à les aligner sur le processus d'intégration continue, voir plus loin. Les tests d'automatisation ne doivent pas être considérés comme une tâche isolée, mais plutôt comme une activité cohérente intégrée dans le SDLC.



Définition des packs de régression

Les tests de régression automatisés sont au cœur de la stratégie d'automatisation des tests.

Pack de régression de fumée

Les packs de régression servent à vérifier que l'application peut être chargée et accessible. En outre, seuls quelques scénarios clés doivent également être exécutés pour s'assurer que l'application est toujours fonctionnelle.

Le but du pack de tests de fumée est de détecter les problèmes les plus évidents, tels que l'application ne se charge pas, ou un flux utilisateur commun ne peut pas être exécuté; pour cette raison, les tests de fumée ne devraient pas durer plus longtemps que 5 minutes pour donner une rétroaction rapide au cas où quelque chose d'important ne fonctionne pas.


Le pack de tests de fumée s'exécute à chaque déploiement et peut être un mélange de tests d'API et / ou d'interface graphique.

Packs de régression fonctionnelle , Qui vise à vérifier la fonctionnalité de l'application plus en détail que le test de fumée.

Des packs de régression multiples doivent exister à des fins différentes. S'il y a plusieurs équipes travaillant sur différentes sections de l'application, alors idéalement, il devrait y avoir différents packs de régression qui peuvent être concentrés sur la zone sur laquelle l'équipe travaille.

Ces packs doivent pouvoir s'exécuter dans n'importe quel environnement au fur et à mesure des besoins, à condition que le comportement des fonctionnalités reste cohérent dans tous les environnements. Ils sont exécutés plusieurs fois par jour et ne devraient pas durer plus de 15 à 30 minutes.


Comme ces tests fonctionnels sont plus détaillés, ils prendront plus de temps à s'exécuter, il est donc important d'avoir la majorité des tests fonctionnels au niveau de la couche API où les tests peuvent être exécutés plus rapidement afin que nous puissions être dans le 15 à 30 minutes limite de temps.

Pack de régression de bout en bout, qui teste l'ensemble de l'application dans son ensemble. Le but de ces tests est de s'assurer que les différentes parties de l'application qui se connectent à diverses bases de données et applications tierces fonctionnent correctement.

Les tests de bout en bout ne sont pas destinés à tester toutes les fonctionnalités car celles-ci sont déjà testées dans les packs de régression fonctionnelle, cependant, ces tests sont «légers» qui vérifient simplement les transitions d'un état à un autre et une poignée des scénarios ou parcours utilisateurs les plus importants.

Ces tests sont principalement exécutés via l'interface graphique, car ils vérifient comment les utilisateurs utiliseraient le système. Le temps nécessaire pour les exécuter peut varier d'une application à l'autre, mais ils sont généralement exécutés une fois par jour ou par nuit.



Stratégie d'automatisation des tests pour plusieurs équipes agiles

test_automation_strategy_agile

Tests unitaires automatisés

L'automatisation des tests démarre au niveau de l'unité. Les tests unitaires doivent être écrits par les développeurs pour toute nouvelle fonctionnalité développée. Ces tests unitaires constituent la base d'une pratique d'automatisation plus large qui s'étend jusqu'aux tests de l'interface graphique système.

Il est de la responsabilité des développeurs de s'assurer que pour chaque nouvelle fonctionnalité développée, un ensemble de tests unitaires cohérents et solides est écrit pour prouver que le code fonctionne comme prévu et répond aux exigences.

Les tests unitaires fournissent le meilleur retour sur investissement à l'équipe car ils sont très rapides à exécuter, faciles à maintenir et à modifier (car il n'y a pas de dépendances) et lorsqu'il y a des erreurs dans le code, ils sont rapidement renvoyés au développeur.

Les tests unitaires sont exécutés sur la machine du développeur ainsi que sur l'environnement CI.

Intégration / API ou tests de service automatisés

Alors que les tests unitaires sont basés sur le test des fonctions au sein d'une classe, les tests d'intégration constituent le niveau supérieur des tests unitaires pour tester les classes qui composent collectivement le composant pour fournir une fonctionnalité. Ces tests sont exécutés uniquement lorsque les tests unitaires sont exécutés et réussis.

Les tests de service sont naturellement exécutés au niveau de la couche API sans l'intervention de l'interface Web GUI; par conséquent, les tests seraient capables de vérifier la fonctionnalité sous une forme pure et comme les tests parlent directement aux composants, ils sont rapides à exécuter et feront partie de la construction.

Si nécessaire, des moqueries telles que wiremock sera utilisé pour éliminer la dépendance des 3 autresrdles systèmes du parti et lorsque les systèmes en aval ne sont pas disponibles pour fournir les données requises pour les tests.

Les tests d'intégration et / ou les tests de service peuvent également être exécutés sur la machine du développeur et faire partie de la construction, mais s'ils commencent à prendre du temps, il est préférable de s'exécuter sur l'environnement CI.

Des outils tels que SoapUI peuvent être utilisés pour les tests de service.

Test d'application

Une application de commerce électronique typique peut être divisée en différentes applications ou «applications» qui fournissent différentes fonctionnalités. Le concept de «test d'application» est celui où un groupe de tests qui testent la fonctionnalité d'une application sont organisés ensemble et exécutés par rapport à l'application souhaitée. Ce pack sera utile dans les cas où une équipe souhaite publier une application individuelle et souhaiterait savoir si elle fonctionne correctement.

Les tests d'application nécessitent généralement une interface pour interagir avec les différents composants, il est donc prévu que ces tests soient exécutés via un navigateur sur l'interface graphique.

Le but de App Testing est de s'assurer que les fonctionnalités de l'application sont fonctionnellement correctes. Étant donné que les tests sont organisés de manière à assurer la confiance dans la santé d'une application particulière, ces tests sont normalement appelés tests verticaux, car ils exécutent «down» une application particulière. Les tests sont très approfondis et la couverture est large.

Pilote Web Selenium pourrait être utilisé pour exécuter ces tests automatisés sur le navigateur. Cet outil est le plus populaire pour les tests d'automatisation du navigateur et fournit une API riche pour permettre des vérifications complexes.

Tests de scénario de bout en bout

Les tests automatisés GUI qui sont exécutés sur le système, servent de flux d'utilisateurs typiques, de voyages ou de scénarios de bout en bout. En raison de problèmes avec ce type de tests (discutés ci-dessous), ceux-ci seront réduits au minimum. Les scénarios de bout en bout sont inclus dans le pack de régression nocturne.



Inverser la pyramide d'automatisation des tests

Dans le cadre de la stratégie d'automatisation des tests, nous devons nous assurer de minimiser le nombre de tests automatisés exécutés au niveau de la couche GUI.

Bien que l'exécution de tests automatisés via l'interface graphique offre des tests efficaces et significatifs en termes de simulation de l'interaction d'un utilisateur avec l'application, elle est sujette à de nombreux problèmes, comme indiqué ci-dessous:

Fragile

Étant donné que les tests s'appuient sur les localisateurs HTML pour identifier les éléments Web avec lesquels interagir, dès qu'un identifiant est modifié, les tests échouent, ils supportent donc beaucoup de coûts de maintenabilité.

Essais limités

L'interface utilisateur graphique peut limiter la capacité du testeur à vérifier complètement une fonctionnalité car l'interface graphique peut ne pas contenir tous les détails de la réponse Web pour permettre la vérification.

Ralentir

Étant donné que les tests sont exécutés via l'interface graphique, les temps de chargement de la page peuvent augmenter considérablement le temps de test global et, par conséquent, les commentaires aux développeurs sont relativement lents.

Moins de retour sur investissement

En raison des problèmes mentionnés ci-dessus, les tests automatisés de l'interface graphique offrent le moins de retour sur investissement.

Les tests d'automatisation du navigateur seront réduits au minimum et seront utilisés pour simuler le comportement d'un utilisateur en incorporant des flux d'utilisateurs communs et des scénarios de bout en bout où le système dans son ensemble est exercé.