Tests automatisés pour le processus de paiement de la boutique en ligne

Notre boutique est mise à jour presque chaque semaine, et après presque chaque mise à jour, quelque chose se casse discrètement en cours de commande. Un code promo cesse de s'appliquer, le coût de livraison disparaît du total, l'étape de paiement renvoie le client à un panier vide. Nous en prenons connaissance par les acheteurs qui écrivent au support — ce qui est la manière la plus coûteuse d'apprendre que le processus de paiement est cassé, car pour chaque personne qui écrit, il y en a plusieurs qui partent simplement. Une vérification manuelle après chaque changement n'est pas réaliste : personne dans l'équipe n'a une heure de libre pour cela, et après la troisième version consécutive, la personne qui vérifie cesse de regarder attentivement.

Ce que je veux, c'est un ensemble de scénarios automatisés qui suivent le même chemin qu'un client réel. De la fiche produit à une commande payée : ajout au panier, changement de quantité et suppression d'un article, application et annulation d'un code promo, choix entre les méthodes de livraison et voir le total se recalculer, enregistrement et connexion avec un mot de passe incorrect parmi les cas, et le compte personnel par la suite — historique des commandes, adresses enregistrées, répétition d'une commande précédente. La mise en page mobile a besoin de ses propres scénarios, pas d'une copie redimensionnée de ceux de bureau : la plupart de nos commandes sont passées depuis des téléphones, et c'est exactement là que le panier se casse généralement en premier. Tout doit commencer de lui-même à chaque compilation, sans que personne n'ait à se souvenir d'appuyer sur un bouton.

Le rapport est aussi important que les tests. Un responsable doit pouvoir le lire sans demander à un ingénieur : quel scénario a échoué, à quelle étape, ce qui était à l'écran à ce moment-là, et à quoi ressemblait l'exécution — une capture d'écran du point d'échec et un enregistrement vidéo du test échoué. J'ai également besoin d'instructions écrites pour nos propres développeurs, afin que l'ajout d'un nouveau scénario plus tard soit une tâche normale et non un projet d'archéologie.

Conditions que j'énonce dès le départ : les tests s'exécutent dans l'environnement de staging avec une clé de paiement de test, aucun paiement réel n'est jamais effectué ; les commandes de test ne doivent pas atteindre la comptabilité et le reporting de la boutique ; un test qui échoue à chaque autre exécution est soit corrigé, soit supprimé — un test peu fiable est pire que pas de test du tout, car les gens cessent de le lire.

Ce que j'attends de recevoir :
— scénarios de bout en bout de la fiche produit à la commande payée, y compris les codes promo et les options de livraison ;
— scénarios d'enregistrement, de connexion et de compte personnel ;
— un ensemble distinct de scénarios pour la mise en page mobile ;
— démarrage automatique de l'ensemble de la suite à chaque compilation, avec un résultat clair de réussite ou d'échec ;
— un rapport qu'un non-ingénieur peut lire, avec une capture d'écran de l'étape échouée ;
— enregistrement vidéo de chaque exécution échouée, conservé suffisamment longtemps pour l'examiner ;
— instructions écrites pour nos développeurs sur l'ajout et la maintenance des scénarios ;
— une courte session de passation afin que l'équipe puisse exécuter et étendre la suite par elle-même.