Salut, Habr. Lors du dernier BackendConf, Anton Olievsky, notre chef du service de test et de contrôle de la qualité des logiciels, a parlé de la chose la plus importante, peut-être la plus importante - une attitude consciente à l'égard du travail.
Voici le truc. La rapidité de mise en œuvre des idées commerciales est devenue un facteur clé. Cette vitesse en SJ est estimée par le temps moyen nécessaire pour terminer la tâche. Dans l'entreprise, ce temps était égal à 65 jours. Oui, 2 mois entre la création d'une tâche et son envoi à l'utilisateur.
Anton dit qu'ils ont pu accélérer les processus de 3 fois grâce à des tests conscients. Maintenant, nous allons vous dire ce que c'est et comment exactement.
Comment c'était avant?
Le processus était comme ceci:
- 5 testeurs pour 40 développeurs;
- Chaque tâche est testée séparément;
- Les tâches terminées fusionnent dans la branche de publication;
- A la sortie, des tests d'acceptation sont effectués;
Puis l'intégration.
Si le résultat était satisfaisant, la version a été envoyée aux utilisateurs et 50 à 60 tâches en attente de test étaient constamment suspendues au tableau.
Comment avez-vous travaillé avec la tâche:
- Depuis le développement, la tâche est entrée dans les tests et s'est perdue dans la liste sans fond des autres en attente;
- Dans la liste, elle pouvait s'affaisser de quelques jours à un mois;
- Ensuite, la tâche a été vérifiée par le testeur, des bogues ont été créés et renvoyée au développement;
- Le programmeur a corrigé des bogues et renvoyé la tâche pour un test.
Le cycle a été répété et la tâche pourrait se bloquer au stade des tests pendant plusieurs mois. D'un point de vue technique, tout allait bien, seules les fonctionnalités étaient sorties lentement et l'entreprise était mécontente. Les testeurs ont constamment écouté le fait que le développement se déroule très lentement, les délais se brisent et les entreprises perdent de l'argent.
Comme tous les testeurs normaux, les gars lisent des livres intelligents sur les tests et pensent que l'essentiel est la qualité du produit. Comme, vous devez trouver autant de bugs que possible et certainement les corriger tous. Mais non.
Pourquoi pas?
Parce que nous n'avons pas besoin de corriger les bugs, mais d'aider l'entreprise, Anton s'est donc tourné vers le produit Dima pour faire face à la situation. Là, ils ont décidé que l'essentiel était la vitesse de sortie des fonctionnalités. Le fait est que les entreprises n'aiment pas perdre de l'argent pour développer et réparer des projets, ce qui n'est pas clair si cela apportera des avantages. Par conséquent, il est préférable de publier un projet imparfait et, en fonction des résultats de son succès, de décider de le porter à l'idéal ou de le minimiser. Les testeurs se sont réunis et ont essayé de comprendre comment augmenter la vitesse de libération. Il s'est avéré que tout est évident.
SJ a une acceptation (un ensemble de cas sur les principaux domaines de fonctionnalité pour vérifier le produit dans son ensemble, par exemple, l'autorisation de l'utilisateur, le placement, etc.), qui se compose de 150 cas et prend 1,5 jour du testeur. C'est trop long.
Sérieusement, cela représente environ 1,5 jour de vérifications manuelles 2 fois par semaine. Que faire avec des vérifications manuelles répétées? Automatisez.
Il s'est avéré automatiser 100 cas. Les cas non rentables pour le partage sur l'automatisation, l'envoi de lettres, la réception de SMS sont restés non rentables. Les testeurs étaient ravis, car les coûts de test des versions étaient moins réguliers - 3 heures au lieu de 1,5 jour. Deuxièmement, les autotests donnent un retour rapide sur l'opportunité de commencer à regarder une version du tout et permettent d'attraper des bogues avant même qu'une tâche n'entre dans une version.
Presque tout a été décidé, mais le CTO est venu.
Qu'est-ce qui ne va pas?
Il est venu et a dit que nous devons voir où va toujours la surdose d'heures de travail. Les gars se sont assis et ont réalisé que les actions répétitives étaient uniquement sur les versions - c'était l'acceptation et l'intégration.
Et l'intégration. En bref, il y a eu une situation où ils ont envoyé un communiqué et le produit de Dim est devenu indigné que la tâche qu'ils avaient promise ne soit pas venue au combat. Ils ont commencé à comprendre où elle était allée. Il s'est avéré que lors de la conservation des tâches dans la branche de publication, certaines validations étaient perdues et la tâche était visuellement perdue pour les utilisateurs.
Les développeurs ont commencé à corriger les scripts de construction et les testeurs ont revérifié les cas pour chaque tâche de la version pour s'assurer que tout allait bien et que toutes les tâches étaient en place. Il semble que ce soit difficile de vérifier les tâches qui ont déjà été examinées. Mais il s'est avéré qu'il y avait environ 5 tâches pour chaque testeur dans la version, et des cas complexes sont survenus, tels que changer quelque chose dans la base de données, exécuter un script, vérifier la lettre reçue. Cette étape entière a pris beaucoup de temps: de 2 à 10 heures de travail de tous les testeurs.
Les gars ont pris des statistiques sur plusieurs mois de cette pratique et il s'est avéré qu'il n'y avait plus de cas avec une mauvaise version de la version et à ce stade seulement quelques fois il y avait des bogues non critiques manqués lors du test des tâches. Pesé tous les avantages et les inconvénients et décidé d'abandonner cette étape.
Maintenant ok?
Pas ok. Dans le monde informatique, vous ne pouvez pas profiter du succès longtemps, car il y a toujours quelque chose à améliorer. Dans notre cas, il s'agissait de sorties 2 fois par semaine. Par exemple, les testeurs ont vérifié la tâche mercredi matin et l'ont envoyée pour publication, et elle ne parvient à l'utilisateur que mardi la semaine prochaine.
Quoi d'autre? Trop de correctifs de l'entreprise. L'entreprise avait prévu de publier une fonctionnalité pour une certaine date, l'a annoncée et a lancé une publicité, et les testeurs étaient: "Portée, gay, nous avons prévu des sorties ici et la tâche ne se déroulera que la semaine prochaine." Par conséquent, pour chacune de ces tâches, le produit Dima a eu recours à eux.
Et tout le monde sait que si Dima entre dans le développement, attendez l'urgence. Ces raids sont fatigués des développeurs et des testeurs. N'est-ce pas une raison pour retourner dans la salle de réunion?! Ils se sont tous enfermés ensemble et ont décidé que l'entreprise devait publier plus souvent, vous devez donc automatiser encore plus, vérifier la version en trois heures, automatiser la construction quotidienne de la version et configurer le lancement des autotests sur la version et procéder à l'acceptation tous les jours.
Ce fut une petite victoire, car les fonctionnalités débordent après avoir testé le maximum le lendemain. Il y avait moins de problèmes avec les correctifs, certains ont été envoyés à la version actuelle et certains attendaient la sortie de demain. Cela a permis aux testeurs de ne pas être distraits par ces contrôles et de libérer du temps pour tester de nouvelles tâches. Soit dit en passant, les statistiques sur les bogues manqués sont restées inchangées.
Ensuite, le testeur Julia est venu vers Anton et a dit qu'elle en avait marre. Comme, faites ce que vous voulez, mais elle ne peut plus effectuer une acceptation tous les jours, étant donné que, selon la fonctionnalité principale, rarement quelque chose change et qu'il ne trouve pas de bugs. Par conséquent, Julia a proposé de procéder à une acceptation une fois par semaine.
Eh bien, les gays.
Et comment c'est?
Gagnez du temps - 12 heures par semaine pour tester de nouvelles tâches, moins de démotivation sur les contrôles monotones. Parmi les inconvénients - les insectes peuvent vivre jusqu'à 5 jours à compter de la date d'apparition. Beaucoup a été fait avec succès pour accélérer, mais en même temps, les gars ont peu d'impact sur la chose la plus importante - le temps moyen nécessaire pour terminer une tâche sur la production.
Ils ont avancé vers le but, mais ne l'ont pas atteint. Oui, les testeurs pouvaient consacrer leur temps à de nouvelles tâches, mais pour la vitesse de passage, c'était une goutte dans le seau.
Anton est parti pour réfléchir aux tâches qui passent par les tests et a réalisé que presque tout. Et le flux est énorme, comme le Mariana Trench, il est donc impossible de tout traiter. Par conséquent, il a été décidé d'établir des priorités. À ce stade, le produit Dima a aidé, ce qui, avec Anton, a vérifié tout ce qui n'était pas important pour les affaires.
Seuls les points directement liés à l'argent et aux choses critiques pour les utilisateurs sont restés.
Bref, il n'en reste que 50 sur une liste de 300 articles.
Vous pouvez déjà travailler avec cela. Soit dit en passant, quels bonus le développement Web donne-t-il?
- La capacité de répondre rapidement aux bugs trouvés au combat;
- Surveillance en ligne des problèmes;
- Support technique en contact avec les utilisateurs.
Maintenant, la chose la plus importante. Oui, les livres de test vous apprennent à tout tester, mais toutes les circonstances ont dit à Anton que tout ne doit pas être testé. Selon Anton, ces trois jours de réflexion, il se sentait comme Hamlet avec sa question «Être ou ne pas être».
Rassemblant toute sa volonté dans un poing, il décida de ce qu'il allait être. Et il a refusé de tester des fonctionnalités sans importance. Les testeurs ont commencé à verser des tâches sur ces 250 points après le développement immédiatement dans la version. Sérieusement.
Toutes les entreprises n'accepteraient pas une telle étape, et presque tous les testeurs refusant de tester nuisent à la rumeur. Mais cette décision a permis de se concentrer sur le très important.
L'absence de test est une étape responsable et dangereuse.
Si vous souhaitez également le faire:- La liste des fonctionnalités critiques est accessible au public afin que les développeurs puissent y accéder;
- Pour évaluer la nouvelle approche, ajoutez à Jira la relation «générée dans => engendrée». Ainsi, vous pouvez suivre le nombre de bogues traversant des tâches non testables;
- Comme il n'est pas extrêmement stupide de tester la plupart des tâches, vérifiez-en quelques-uns, mais dans la version afin de ne pas ralentir le versement;
- Fonctionnalité critique à tester selon l'ancien schéma.
Qu'est-ce qui va changer?- La plupart des tâches cesseront de déraper pendant la phase de test;
- Les testeurs ne traiteront que les tâches critiques de l'entreprise;
- L'important est de tester plus rapidement, car ce qui est sans importance n'interfère plus sur la carte.
Qu'est-ce qui est si mauvais- Les vrais utilisateurs sont plus susceptibles de rencontrer des erreurs mineures;
- La charge sur le support technique augmente, car les bogues manqués commencent à venir des utilisateurs.
A-t-il été blessé?
Les gars ont accompli toutes les étapes décrites dans les six mois. Oui, ça faisait mal, mais la sortie était la suivante:
Le temps moyen nécessaire pour terminer une tâche a été réduit à 19 jours et il diminue constamment;
Le flux des tâches de test est réduit. Les testeurs ont commencé à se préparer à tester des fonctionnalités importantes en parallèle avec le développement;
Le produit Dima a complètement cessé d'aller chez Anton.
Au lieu de conclusions
N'utilisez pas notre approche en médecine ou en construction aéronautique. Dans des situations qui ne sont pas associées à un risque pour la vie - testez vos décisions et vos approches.
Ne croyez pas les livres et arrêtez de tester pour le plaisir de tester, simplement parce qu'il est écrit quelque part.
Demandez-vous si vous répondez aux attentes de l'entreprise et si chaque élément de votre liste de tâches est vraiment utile.
SuperJob était avec vous. Sensibilisation à tous!