Par où commencer avec l'automatisation des tests pour un site Web existant?

Andrew demande:

J'ai récemment rejoint une entreprise basée sur le Web en tant que premier membre de l'assurance qualité. Le site Web a été développé au cours des cinq dernières années et pendant ce temps, les développeurs et les autres membres de l'équipe effectuaient les tests.

Il n'y a pas de processus formel d'AQ ou de test en place, donc tous les tests ont été en grande partie ad hoc.


Maintenant, mon responsable, qui est en charge de la livraison de logiciels, veut que je crée un pack de test de régression automatisé que l'équipe peut exécuter chaque fois qu'elle développe de nouvelles fonctionnalités.

Ma question est: par où commencer avec l'automatisation des tests pour créer ce pack de régression pour un site Web qui fonctionne depuis plus de cinq ans?


Toutes les idées / suggestions seraient très appréciées.

Ma réponse:

Une fois qu'un site Web fonctionne et sert des clients en direct depuis un certain nombre d'années, il est dans un état mature. Par mature, je veux dire qu'il n'y a (espérons-le) pas de bogues sérieux évidents dans le système et, le cas échéant, ce seront des problèmes de cas subtils ou de pointe qui ne sont pas facilement repérables par tout le monde.

Ce que nous ne devrait pas faire, est d'essayer d'écrire rétrospectivement des tests pour toutes les histoires qui ont déjà été développées et sont devenues une partie du système. Cependant, ce que nous voulons, c’est un ensemble de scénarios clés qui exercent le système de bout en bout pour garantir que les développements futurs ne mettent pas en péril les fonctionnalités existantes.


Les étapes ci-dessous sont quelques lignes directrices qui peuvent être utilisées pour un site Web existant et déjà établi afin de trouver les scénarios clés et une méthode pour les développer pour créer un pack de régression fonctionnel.

En rapport:

1. Explorer

Vous devez d'abord vous familiariser avec le site Web et ses fonctionnalités. Commencez par explorer le site et découvrez son comportement. Ce faisant, vous pouvez également créer une carte mentale de la structure du site Web, des pages et des fonctionnalités de chaque page.

Les cartes mentales sont un excellent moyen d'obtenir un instantané de haut niveau et une vue d'ensemble de l'ensemble du site Web. Nous pouvons toujours nous référer aux cartes mentales pour comprendre comment les pages sont connectées.


2. Rassembler des métriques

Rassemblez les métriques d'utilisation du site auprès de l'équipe marketing et / ou analytique. La plupart des entreprises intègrent des «balises de suivi» telles que Google Analytics sur leur site Web pour pouvoir suivre la façon dont les utilisateurs utilisent le site. Il existe une mine d'informations sur le comportement de l'utilisateur et les parcours utilisateurs qui peuvent être récupérés à partir de ces systèmes de suivi.

La raison pour laquelle nous devons collecter ces informations est d'être en mesure de hiérarchiser les scénarios de test à automatiser en premier afin que nous obtenions le plus de valeur dans les plus brefs délais.

3. Scénarios clés

Commencez par automatiser les principaux scénarios de bout en bout via l'application Web. Cela constituera la base de notre «pack de régression de fumée». Par exemple, pour une application Web de commerce électronique classique, le scénario de base de bout en bout est:

Page d'accueil -> Résultats de la recherche -> Détails du produit -> Connexion client / Inscription -> Détails du paiement -> Confirmation de commande


Il est important de noter que, pour commencer, nous devons simplement nous assurer que nous pouvons parcourir les pages, en commençant par la page d'accueil et en atteignant la page de confirmation de commande. L'objectif est de vérifier que le flux d'achat n'est pas interrompu, plutôt que de vérifier en détail la fonctionnalité de chaque page.

Une fois que nous avons couvert le flux d'utilisateurs le plus simple et le plus courant, nous pouvons alors examiner d'autres variantes. Malgré les nombreuses combinaisons de fonctionnalités et de pages, on remarquera qu'il n'y a en réalité qu'une poignée de parcours utilisateur à travers le système qui doivent être pris en compte.

En examinant les données analytiques, vous constaterez probablement que 80% des utilisateurs emprunteraient les mêmes chemins mais avec des données différentes. Par conséquent, notre pack de régression de fumée doit être construit sur la base de ces scénarios.

4. Augmenter la couverture

Une note sur la couverture, ici je ne parle pas de la couverture de test; l'accent est mis sur couverture des fonctionnalités .


Développez le pack de régression de fumée pour créer un pack de régression de fonctions plus complet en utilisant les cartes mentales et en appliquant une technique de test de transition d'état pour créer les scénarios.

Points d'entrée - Pour commencer, nous devons d'abord trouver les points d'entrée dans le système. Ces points d'entrée peuvent être un utilisateur qui atterrit sur la page d'accueil, une page de détails du produit ou un SEM (Marketing sur les moteurs de recherche) page spécifique.

Une fois que nous identifions une page de destination particulière, nous devons voir quelles sont les fonctionnalités de cette page avec lesquelles l'utilisateur peut interagir. C'est là que les cartes mentales deviennent très utiles. Nous avons un aperçu de haut niveau de la page et de ses fonctionnalités.

Ici, la signification de la fonctionnalité est soit un composant unique comme une liste déroulante d'options de tri, soit le remplissage d'un formulaire de détails utilisateur ou aussi simple que de cliquer sur un lien.

Etat initial - Lorsque nous atterrirons pour la première fois sur un point d'entrée dans l'application, un état sera associé à cette page. Nous enregistrons cela comme l'état initial de l'application. Chaque fois que nous interagissons avec l'une des fonctionnalités de cette page, nous allons probablement modifier son état initial.

Déclencheur - Certaines fonctionnalités, lorsqu'elles interagissent avec, chargeront la même page (par exemple, les options de tri conserveront la même page, mais les données seront triées) ou passeront à une autre page (par exemple, en soumettant des informations d'identification d'utilisateur valides). L'élément qui provoque cette transition, soit vers la même page, soit vers une autre page, est appelé le déclencheur, comme le bouton d'envoi.

Assertions - Ensuite, il y a les affirmations. Chaque fois que l'état de l'application est modifié, en interagissant avec une fonctionnalité, nous devons faire des assertions pour vérifier l'état du nouvel état. Par exemple, lorsque nous soumettons un formulaire de connexion avec des données utilisateur valides, nous devons affirmer que l'utilisateur est maintenant connecté.

Nous pouvons continuer de la même manière sur la nouvelle transition, ou revenir à l'état initial et interagir avec une autre fonctionnalité jusqu'à ce que nous couvrions toutes les fonctionnalités importantes des cartes mentales.

Au fil du temps, le niveau de confiance dans le déploiement du nouveau code augmente à mesure que de plus en plus de scénarios sont automatisés et exécutés régulièrement.