Kazidomi

Défi

Kazidomi a fait appel à QAwerk pour renforcer et élargir son équipe de livraison avec des ingénieurs QA professionnels et des ingénieurs en automatisation de tests. Avant notre collaboration, ils s’appuyaient sur des rapports de bugs de leurs agents du service client, qui manquaient souvent des détails nécessaires pour que les développeurs comprennent rapidement la cause profonde du problème.

Le partenariat avec QAwerk visait à atteindre les résultats suivants :

• Correction des bugs plus rapide. Notre mission consistait à compléter les rapports rédigés par l’équipe interne avec des préconditions, des étapes de reproduction du bug et d’autres détails pour économiser le temps des développeurs Kazidomi et rendre parfaitement clair ce qui s’était mal passé et dans quelles circonstances exactes.
• Tests automatisés. Nous devions introduire l’automatisation des tests afin de réduire le temps consacré aux tests fonctionnels, UI et de régression, ce qui permet à son tour une livraison plus rapide et plus fluide des nouvelles fonctionnalités aux utilisateurs.
• Amélioration de la conversion. QAwerk était responsable d’accorder la plus grande attention aux fonctionnalités ayant un impact direct sur les conversions. Notre objectif était de détecter tous les obstacles potentiels à la conversion et de s’assurer que l’utilisateur ne rencontre aucun problème tout au long de son parcours.

La création et la maintenance de la documentation de test font partie intégrante du processus d’assurance qualité, et c’est ce que nous avons fait pour Kazidomi également. Chaque fonctionnalité prête à être testée nécessitait la rédaction de nouveaux cas de test ou la mise à jour des cas existants.

Solution

Nous sommes convaincus que des tests rigoureux sont mieux assurés par la combinaison de tests manuels et automatisés. Grâce à l’automatisation des tests, nous avons augmenté la vitesse de test et obtenu une plus grande couverture. En même temps, les tests manuels nous ont permis d’apporter cette touche humaine et d’explorer la plateforme du point de vue de l’utilisateur.

Pour une solution web comme Kazidomi, ces types de tests étaient essentiels :

• Tests fonctionnels. Nous avons mis un effort maximal dans le test des actions utilisateurs les plus courantes, telles que l’authentification, l’ajout de produits au panier, la modification du contenu du panier, l’application de codes de réduction, entre autres. Nous avons veillé à ce que chaque bouton, lien et filtre remplisse sa fonction et aide l’utilisateur à prendre une décision.
• Tests d’intégration. Les bugs sur une page de facturation sont l’un des obstacles à la conversion les plus répandus. Nos ingénieurs QA ont testé l’intégration avec des systèmes de paiement tels que PayPal et Adyen pour s’assurer que le processus de paiement se déroule avec succès et sans stress.
• Tests cross-browser. Les plateformes d’e-commerce multinationales comme Kazidomi ont des clients utilisant différents navigateurs sur différents appareils. Nous avons veillé à ce que l’expérience utilisateur reste de haute qualité, quel que soit le navigateur ou l’appareil utilisé. Les tests automatisés se concentraient uniquement sur Chrome.
• Tests UI. Une interface utilisateur soignée n’est pas moins importante que des performances applicatives irréprochables, car elle contribue à la première impression et à la confiance envers la marque. Notre équipe QA a vérifié si l’implémentation du design correspond aux spécifications des exigences.
• Tests de régression. Étant donné que Kazidomi publie fréquemment des mises à jour, la nécessité d’automatiser les tests de régression était évidente. Avec la régression automatisée en place, les bugs étaient signalés en temps opportun, permettant aux développeurs Kazidomi de corriger les problèmes les plus critiques avant le jour de la mise en production et de respecter leur plan de livraison.

Nous avons rédigé 587 cas de test de toutes pièces, dont 284 ont été automatisés.

Automatisation des tests

Tous les tests ont été exécutés sur un serveur avec une nouvelle base de données sans utilisateurs ni données de test précréés. Les données étaient automatiquement créées pour chaque cas de test juste avant l’exécution du test. Cette approche a permis de maintenir la stabilité des autotests et de les exécuter dans n’importe quel ordre car il n’y avait aucune interdépendance entre les données de test. Par exemple, si deux cas de test s’appuient sur le même élément de données de test et que le premier test le supprime lors de l’une de ses étapes, le second test échouera, générant un faux positif.

Nos autotests contenaient également des post-conditions pour le nettoyage des données. Lorsque de nouvelles données sont générées pour chaque petit cas de test, la taille de la source de données croît très rapidement, imposant une charge inutile au serveur. Par conséquent, chaque autotest supprimait les données de test qu’il avait précédemment créées après une exécution réussie.

Comme vous pouvez l’imaginer, exécuter 284 autotests simultanément prend un certain temps — environ 6 heures, pour être précis. Pour accélérer les choses, nous avons divisé tous les tests en groupes, en isolant le groupe de tests de fumée contenant environ 30 autotests pour les fonctionnalités principales du produit. Les autres groupes ont été étiquetés en fonction de la fonctionnalité qu’ils vérifiaient, par exemple « login », « add to cart » et « create account ».

Ces tests étaient exécutés en continu après chaque commit dans le dépôt GitLab. Si nécessaire, il était également possible de lancer manuellement ou d’ignorer des autotests pour un groupe spécifique.