Un développement logiciel rapide et efficace est aujourd'hui impensable sans workflows bien rodés: chaque composant est transféré à l'assemblage au moment de l'installation, le produit ne reste pas inactif. Il y a deux ans, avec M.Video, nous avons commencé à introduire une telle approche dans le processus de développement chez le détaillant et aujourd'hui nous continuons à la développer. Quels sont les sous-totaux? Le résultat a été payant: grâce aux changements mis en œuvre, il a été possible d'accélérer la publication des versions de 20 à 30%. Vous voulez des détails? Bienvenue dans nos coulisses.

De Scrum à Kanban

Tout d'abord, un changement de méthodologie a été mis en place - la transition de Scrum, c'est-à-dire le modèle de sprint, à Kanban. Auparavant, le processus de développement ressemblait à ceci:



Il y a une branche de développement, il y a des sprints pour cinq équipes. Ils codent dans leurs propres branches de développement, les sprints se terminent le même jour et toutes les équipes combinent les résultats de leur travail avec la branche principale le même jour. Après cela, des tests de régression sont exécutés pendant cinq jours, puis la branche est donnée à l'environnement pilote et ensuite à l'environnement productif. Mais, avant de commencer les tests de régression, il a fallu 2-3 jours pour stabiliser la branche principale, supprimant les conflits après la fusion avec les branches de commande.

Quel est l'avantage de Kanban? Les équipes n'attendent pas la fin du sprint, mais combinent leurs modifications locales avec la branche principale à la fin de la tâche, vérifiant à chaque fois les conflits de collision. Le jour fixé, toutes les associations avec le maître sont bloquées et les tests de régression sont lancés.



En conséquence, nous avons réussi à nous débarrasser des décalages constants des termes vers la droite, des régressions
pas retardé, la libération du candidat est expédiée à temps.

Automatisation omniprésente

Bien sûr, il ne suffisait pas de changer la méthodologie. La deuxième étape, nous, avec le détaillant, les tests automatisés. Au total, environ 900 scénarios sont testés, répartis en groupes par priorité.

Environ 100 scénarios sont les soi-disant bloqueurs. Ils devraient travailler sur le site - la boutique en ligne M.Video - même pendant une guerre atomique. Si l'un des bloqueurs ne fonctionne pas, il y a de gros problèmes sur le site. Par exemple, les bloqueurs incluent un mécanisme pour acheter des marchandises, appliquer des remises, des autorisations, enregistrer des utilisateurs, passer une commande de crédit, etc.

Environ 300 scénarios supplémentaires sont essentiels. Ceux-ci incluent, par exemple, la possibilité de sélectionner des produits à l'aide de filtres. Si cette fonctionnalité se casse, il est peu probable que les utilisateurs achètent des marchandises, même si les mécanismes d'achat et de recherche directe dans le catalogue fonctionnent.

D'autres scénarios sont majeurs et mineurs. S'ils ne fonctionnent pas, les gens acquerront une expérience négative en utilisant le site. Cela comprend de nombreux problèmes d'importance et de visibilité variables pour l'utilisateur. Par exemple, la mise en page (majeure) est allée, la description du stock (mineur) n'est pas affichée, l'auto-suggestion de mots de passe dans le compte personnel (mineur) ne fonctionne pas, la récupération (majeure) ne fonctionne pas.

Avec M.Video, nous avons automatisé le test des bloqueurs à 95%, des scénarios restants - à environ 50%. Pourquoi la moitié n'est-elle pas automatisée? Il y a plusieurs raisons et différentes. Il existe a priori des scénarios qui ne se prêtent pas à l'automatisation. Il existe des cas d'intégration complexes, dont la préparation nécessite un travail manuel, par exemple, appeler la banque et annuler une demande de prêt, contacter le service commercial et annuler des commandes dans un environnement productif.
L'automatisation des tests de régression a réduit leur durée. Mais nous sommes allés plus loin et avons automatisé les tests de fumée pour les bloqueurs après chaque fusion des branches de commande avec la branche principale.

Après avoir automatisé les tests, nous avons finalement éliminé les retards après avoir terminé les associations avec la branche maître.

Cornichon à la rescousse

Pour consolider le succès, notre équipe a retravaillé les tests eux-mêmes. Auparavant, il s'agissait de tableaux: action → résultat attendu → résultat réel. Par exemple, je me suis connecté au site avec un tel nom d'utilisateur et mot de passe; résultat attendu: tout est en ordre; le résultat réel est également correct, je vais sur d'autres pages. Ces scénarios étaient lourds.

Nous les avons traduits en notation Gherkin et automatisé certaines étapes. Prenons la même autorisation sur le site, le script est maintenant formulé comme suit: "en tant qu'utilisateur du site, je me suis connecté avec les données d'autorisation, et la procédure a réussi ." De plus, «l' utilisateur du site » et « connecté avec les données d'autorisation » sont répertoriés dans des tableaux séparés. Nous pouvons désormais exécuter rapidement des cas de test, quelles que soient les données.

Quelle est la valeur de cette étape? Disons qu'un testeur est engagé dans le test d'un projet. Il ne se soucie pas de la façon dont il écrit les tests, il peut faire des vérifications même sous la forme d'une liste de contrôle: "l'autorisation est vérifiée, l'inscription est vérifiée, l'achat est vérifié par carte, l'achat par Yandex. L'argent est vérifié - je suis beau". Une nouvelle personne vient et demande: vous êtes-vous connecté par e-mail ou via Facebook? En conséquence, la liste de contrôle se transforme en script.

Cinq équipes travaillent dans le projet, et chaque équipe a au moins deux testeurs. Auparavant, chacun d'eux a écrit des tests à sa guise, et en conséquence, les tests ne pouvaient être pris en charge que par leurs auteurs. Avec l'automatisation, tout était ennuyeux: soit vous devez recruter des ingénieurs d'automatisation séparés qui traduisent l'ensemble du zoo de tests dans un langage de script, soit oublier l'automatisation en tant que phénomène. Gherkin a aidé à tout changer: à l'aide de ce langage de script, nous avons créé des «cubes» - autorisation, panier, paiement, etc. - à partir desquels les testeurs collectent désormais divers scripts. Lorsque vous devez créer un nouveau script, une personne ne l'écrit pas à partir de zéro, mais tire simplement les blocs nécessaires sous la forme d'autotests. Les notations Gherkin ont formé tous les testeurs fonctionnels et peuvent désormais interagir indépendamment avec l'automatisation, prendre en charge les scripts et analyser les résultats.

Nous ne nous sommes pas arrêtés là.

Blocs fonctionnels

Disons que la version 1 est la fonctionnalité qui existe déjà sur le site. Dans la version 2, nous voulions apporter des modifications aux scénarios utilisateur et métier, et en conséquence, une partie des tests a cessé de fonctionner car la fonctionnalité a changé.

Nous avons structuré le système de stockage de test: nous l'avons divisé en blocs fonctionnels, par exemple, «compte personnel», «achat», etc. Désormais, lorsqu'un nouveau script utilisateur est introduit, les blocs fonctionnels nécessaires sont déjà marqués de graduations.

Grâce à cela, après avoir combiné avec la branche master, les développeurs peuvent vérifier non seulement le travail des bloqueurs, mais également les scripts liés au domaine concerné par les modifications apportées.

La deuxième conséquence est qu'il est devenu beaucoup plus facile de maintenir les tests eux-mêmes. Par exemple, si quelque chose a changé dans votre compte personnel, en passant une commande et une livraison, nous n'avons pas besoin de secouer l'ensemble du modèle de régression, car les blocs fonctionnels qui sont modifiés sont immédiatement visibles. Autrement dit, la mise à jour de la suite de tests est devenue plus rapide, et donc moins chère.

Le problème avec les stands

Personne n'avait l'habitude de tester les performances des stands avant les tests d'acceptation. Par exemple, ils nous donnent un banc de test, nous y exécutons des tests de régression pendant plusieurs heures. Ils tombent, comprennent, réparent, exécutent à nouveau des tests. Autrement dit, nous perdons du temps sur le débogage et les exécutions répétées.

Le problème a été résolu simplement: ils ont écrit un total de 15 tests API qui vérifient la configuration des stands, qui ne sont en aucun cas liés à la fonctionnalité. Les tests sont indépendants de la version de construction; ils vérifient uniquement tous les points d'intégration critiques pour la transmission de scripts.

Cela a permis de gagner beaucoup de temps. En effet, avant l'automatisation, nous avions 14 testeurs, les contrôles étaient lourds et longs, il y avait des scripts pour presque toute la journée de travail, composée de 150 étapes. Et ici, vous testez, et quelque part à la 30–40–110ème étape, vous vous rendez compte que le support ne fonctionne pas. Nous multiplions le temps de travail perdu par 14 personnes et sommes horrifiés. Et après l'introduction de l'automatisation et des tests des stands, nous avons réussi à réduire de moitié le nombre de testeurs et à nous débarrasser des temps d'arrêt, ce qui a apporté beaucoup de joie au chef comptable.

Cerises sur le gâteau

La première cerise est bugflow. Formellement, c'est le cycle de vie de tout bug, mais en fait de toute entité. Par exemple, nous opérons sur ce concept à Jira. Un statut supplémentaire nous a permis d'accélérer les versions.

En général, le processus ressemble à ceci: ils ont trouvé un incident, l'ont mis au travail, l'ont terminé, l'ont remis aux tests, l'ont testé et l'ont fermé.



Nous comprenons que le défaut a disparu, le problème a été résolu. Et ils ont ajouté un autre statut: «pour les tests de régression». Cela signifie qu'après l'analyse, des scénarios qui détectent des bogues critiques sont ajoutés à l'ensemble de régression de 900 scénarios. S'ils n'étaient pas là, ou s'ils avaient des détails insuffisants, alors nous avons un retour instantané sur l'état du productif ou du pilote.



Autrement dit, nous comprenons qu'il y a un problème et, pour une raison quelconque, nous ne l'avons pas pris en compte. Et maintenant, l'ajout d'un script de vérification des bogues fait gagner beaucoup de temps.

Nous avons également introduit une rétrospective au niveau des tests. Cela ressemble à ceci: ils ont compilé une tablette «numéro de version, nombre de bogues, nombre de bloqueurs et autres scripts, et nombre de résolutions». Dans le même temps, nous avons estimé le nombre de résolutions invalides. Par exemple, si vous obtenez 15 bogues invalides sur 40 bogues, alors c'est un très mauvais indicateur, les testeurs perdent non seulement leur temps, mais aussi le temps des développeurs qui travaillent sur ces bogues. Les gars ont commencé à réfléchir, à gérer cela, à introduire la procédure de révision des bogues par des testeurs plus expérimentés avant de les envoyer au développement. Et ils l'ont très bien fait.

Ainsi, il y a une réflexion constante et un travail pour améliorer la qualité. Tous les bogues du produit sont analysés: un test est créé pour chaque bogue, qui est immédiatement inclus dans l'ensemble de régression. Si possible, ce test est automatisé et s'exécute régulièrement.

Résultats

Initialement, il était prévu d'augmenter la fréquence des versions et de réduire le nombre d'erreurs, mais le résultat a quelque peu dépassé les attentes. Un processus d'automatisation raisonnablement construit a permis d'augmenter le nombre de tests automatisés en peu de temps, et l'analyse des bogues manqués a permis à l'équipe de développement et de test de hiérarchiser de manière optimale les scripts et de se concentrer sur les plus importants.

Résultats d'automatisation:

• jusqu'à 4 jours (au lieu des 10 précédents) ont réduit la durée des tests de régression;
• l'équipe de tests manuels a diminué de 50%;
• de 30 à 35 jours, la durée de mise sur le marché a été réduite - à partir du moment où une fonctionnalité est entrée dans l'arriéré de l'équipe jusqu'à ce qu'elle entre dans le pilote.

Équipe d'automatisation des tests, Jet Infosystems