Il est rare de trouver un projet dont vous êtes tombé amoureux lors de l'entretien et dont vous êtes fier lorsqu'il conquiert de nouveaux marchés. C'est d'autant plus agréable lorsque le professionnalisme des collègues est à son meilleur, et que dans votre équipe vous vous sentez en famille. J'ai eu la chance non seulement de trouver un tel projet, mais aussi il y a quelque temps de commencer à influencer le processus de test. Je vais vous dire ce qui est inclus dans notre compréhension du processus optimal; comment nous en sommes arrivés aux versions mensuelles et comment elles fonctionnent pour nous; et comment nous nous sommes adaptés aux conditions de la quarantaine.
Notre projet est un système d'apprentissage à distance (LMS, Learning Management System), qui est utilisé par plus de 7 millions de personnes dans différents pays du monde. Le système contient plus de 1000 pages Web et environ 10 000 cas de test.
Aujourd'hui, le projet emploie environ 15 équipes de développement - du côté du client en Norvège et du côté d'Arcadie en Russie. J'ai rejoint le projet il y a 8 ans en tant que QA; Depuis 2 ans, je travaille en tant que responsable QA, participant à l'optimisation du processus de test.
Ce qui est inclus dans le concept d'un processus optimal
Notre tâche principale est de répondre aux besoins des utilisateurs finaux, ce qui inclut la création de nouvelles fonctionnalités et la prise en charge du système. Une attention particulière est portée à la vitesse du système et à la stabilité du travail dans des conditions de forte charge.
Le processus de développement doit principalement permettre la réalisation durable des objectifs commerciaux, tels que le travail effectué à temps et avec un niveau de qualité convenu. Mais le processus doit également être confortable pour l'équipe de développement, afin que toutes les personnes impliquées dans le processus soient satisfaites. Dans nos équipes, nous avons établi pour nous un processus optimal, et voici les moyens par lesquels cela est réalisé.
Processus de développement en général:
a) Une approche de développement qui répond aux besoins de l'équipe
Nous travaillons avec Scrum et des sprints d'une durée de 3 semaines. Avant le sprint, une présentation de ses objectifs a lieu et un ensemble d'exigences pour ce sprint est formé. Vient ensuite la planification, dans laquelle nous évaluons toutes les tâches et déterminons l'ensemble des tâches qui seront incluses dans le sprint. À la fin du sprint, une revue de sprint a lieu, où nous démontrons toutes les tâches terminées et annonçons les objectifs atteints. Cette approche est optimale pour nous: dans un sprint, nous parvenons à créer une quantité suffisante de nouvelles fonctionnalités et en même temps à corriger et tester un certain nombre de bogues des utilisateurs finaux - 10% du temps de sprint est alloué pour ces bogues.
S'aligner: chef d'équipe, développeurs, testeurs. Le ratio développeurs / testeurs dans nos équipes est de 3: 1. Ce ratio permet d'atteindre l'objectif du sprint de manière uniforme - il n'y a pas de périodes où l'un des participants au processus est inactif: pendant que les développeurs apportent un changement, les testeurs créent ou mettent à jour des cas de test liés à ce changement; Une fois le développement terminé, les testeurs vérifient les modifications et les développeurs passent aux tâches suivantes du sprint ou participent aux tests (cela est nécessaire lors du test de modifications à grande échelle).
Le Product Owner définit les objectifs et les exigences au début de chaque sprint et les accepte à la fin. De plus, chaque équipe dispose d'un Scrum Master pour aider à résoudre les problèmes émergents.
Afin que l'équipe ait l'opportunité de réaliser diverses activités qui ne sont pas directement liées aux tâches du sprint, ainsi que de prendre en compte divers risques, le temps calculé pour accomplir les tâches du sprint est de 80% du temps de travail total de l'équipe. Autrement dit, 2 heures par jour pendant un sprint régulier sont réservées aux communications, aux diverses réunions et séminaires, ainsi qu'à la correction des bugs trouvés dans le sprint.
b) Exigences claires et bonne planification
Afin de garantir que la planification ne traîne pas et que le sprint ne devienne pas un échec en raison de détails auparavant inconnus et de modifications supplémentaires laborieuses déjà ajoutées dans le processus de sprint, nous essayons de ne prendre en compte dans le sprint que les changements avec des exigences suffisamment claires et précises. Si la zone de projet qui concerne les changements est inconnue de l'équipe, ou lors de la planification de nombreuses questions se posent auxquelles le Product Owner ne peut pas répondre, l'équipe peut sprinter une tâche pour étudier cette zone ou une tâche de recherche, ce qui se traduit par des exigences claires voire une sorte de prototype.
c) Rétrospectives
La correction des bogues est également importante. Cela s'applique aux sprints et aux versions. Il arrive que nous n'ayons pas le temps pour quelque chose, ou que nous devions faire des heures supplémentaires pour être à l'heure - par exemple, s'il est nécessaire de pré-tester une version (et ce sont des coûts supplémentaires que l'entreprise aimerait éviter à l'avenir). Par conséquent, nous menons des rétrospectives où nous discutons de ce qui était bon et mauvais dans un sprint ou une version, et développons des mesures pour éviter de telles erreurs à l'avenir.
d) Aide à la gestion
Parfois, des questions ou des situations surgissent qui ne peuvent pas être résolues au niveau de l'équipe - vous devez changer le processus ou impliquer la direction de l'entreprise dans la décision. Il est très important de voir qu'ils veulent vous aider et sont prêts à vous soutenir dans une telle situation. Dans notre entreprise, tout va bien avec cela - cela s'applique à la fois à Arcadia et à la gestion du client. Toutes les questions sont discutées et une solution est toujours trouvée qui satisfait toutes les parties.
e) Et, à mon avis, le fondamental est une bonne communication. Et ce que nous avons dans l'entreprise, pour moi, c'est l'un des principaux avantages d'un travail confortable: la bienveillance, le désir de compromis.
Cela s'applique à tout le monde: chaque membre de l'équipe, le Product Owner, le Scrum Master, la direction de l'entreprise et de nombreux autres participants au processus. Tout le monde est ouvert aux questions et aux discussions, les développeurs consultent les testeurs sur les exigences et décident ensemble de la meilleure façon (à la fois du point de vue du développement et du point de vue du test) de faire tel ou tel changement. Le Product Owner, à son tour, est constamment en contact avec l'équipe, résout rapidement tous les problèmes et essaie toujours de se rencontrer à mi-chemin pour atteindre les objectifs du sprint. Le Scrum Master est toujours prêt à vous aider: trouver des ressources supplémentaires (testeurs / développeurs, si elles sont nécessaires pour le sprint ou pour la sortie) ou suggérer la meilleure façon d'organiser le sprint dans le temps.
Processus de test:
a) Normes d'AQ (directives) liées à l'écriture de cas de test.
Dans notre projet, les cas de test sont la principale documentation détaillée sur les fonctionnalités du système, une grande attention leur est donc accordée. Pour chaque modification apportée par l'équipe, un nouveau cas de test est écrit ou un cas existant est mis à jour.
Auparavant, lorsque le système n'était pas encore aussi énorme, les cas de test étaient rédigés de manière assez détaillée, avec diverses étapes spécifiques, mais maintenant cette approche est devenue inacceptable - il faut beaucoup de temps pour mettre à jour de tels cas de test. Par conséquent, nous (responsables de l'assurance qualité) avons développé des normes, dont la principale exigence est d'écrire des scripts de test avec les résultats attendus au lieu d'étapes détaillées dans les cas de test.
b) Normes d'assurance qualité liées aux tests dans les sprints.
Des normes de test de sprint ont été développées pour garantir que chaque équipe effectue des changements de bonne qualité.
Ces normes sont basées sur une couverture de test maximale, qui comprend:
- Tester directement les modifications apportées par l'équipe (fonctionnalité et, si nécessaire, interface utilisateur);
- Tester le système après ce changement à l'aide d'une liste de contrôle: ce sont des vérifications obligatoires, qui incluent le test de l'accessibilité pour les personnes handicapées, la vérification des traductions, la vérification des données existantes, le test à l'aide de caractères spéciaux, les contrôles de sécurité, le test des modifications dans une application mobile et d'autres contrôles ...
c) Normes d'assurance qualité liées aux tests de libération.
Le processus de publication et les normes qui y sont utilisées sont discutés plus en détail ci-dessous.
d) Utilisation de tests de régression automatisés.
La création de tests automatisés pour les tests de régression a rendu la vie des équipes beaucoup plus facile - maintenant, si vous devez vérifier une zone après des changements de commande, vous pouvez simplement exécuter des tests automatiques de régression pour la zone souhaitée du système (si cette zone est couverte par des tests automatiques). De plus, si une partie du système a été interrompue par des changements d'équipe, les autotests de régression le détecteront.
e) Assistance mutuelle des testeurs, assistance des développeurs.
Nous n'avons pas beaucoup de testeurs (en moyenne 1 testeur pour 3 développeurs), en plus, de temps en temps, ils sont distraits des tâches de sprint pour tester les versions, et il peut ne pas y avoir assez de temps pour tout.
Dans ce cas, il y a toujours quelqu'un des testeurs d'autres équipes avec moins de charge de travail pour le moment qui peut vous aider. Le responsable QA ou Scrum Master aide à trouver un tel testeur. De plus, les développeurs peuvent aider à tester les modifications dans le sprint si des cas de test ont déjà été écrits pour eux.
f) Communication entre testeurs.
Pour la communication, un chat dans Microsoft Teams est utilisé, dans lequel tout le monde peut poser des questions et obtenir des réponses rapidement, tandis que le reste des testeurs trouvera les dernières informations. Nous avons également des réunions mensuelles d'AQ, où les testeurs partagent entre eux les tâches actuelles de leur équipe et peuvent discuter de tout problème - l'approche des tests et / ou l'emplacement des cas de test liés à une zone inconnue du testeur; questions sur la version (composition de la future équipe de publication, modification du calendrier des tests); vérifications obligatoires supplémentaires ajoutées après avoir manqué un bogue critique dans la version, etc.).
Les approches ci-dessus vous permettent de garantir des tests de bonne qualité dans un mode de fonctionnement silencieux.
:
Nous avions l'habitude de publier des publications trimestrielles . Avec un tel calendrier, de nombreux changements ont été apportés par les équipes pour chaque version. Cette quantité de changement nécessitait certainement une régression avant la publication, il y avait donc un délai distinct pour la régression et toutes les équipes y étaient connectées. Cela prenait généralement environ 2 semaines, et les testeurs et les développeurs de l'équipe ont participé à la régression.
Après un certain temps, les autotests ont commencé à être utilisés pour la régression dans le processus de test des versions. Tous les tests de régression n'ont pas été couverts par des tests automatiques, certains ont été testés manuellement. Dans l'ensemble, cela a réduit le temps de test de régression, mais en raison de la taille du système, la régression complète prenait encore du temps.
L'ensemble du cycle de développement ressemblait à ceci:
Il est devenu évident que cette approche des versions n'est pas optimale, demande beaucoup de travail et ne permet pas une satisfaction rapide et flexible des demandes des utilisateurs finaux. L'approche du processus de publication nécessitait des changements et il a été décidé de publier plus souvent - une fois par mois.
Lorsque nous sommes passés aux versions mensuelles , il est devenu clair qu'il n'y avait pas de temps pour exécuter une régression pendant la phase de test de publication, même avec des tests de régression partiellement automatisés. Désormais, la période totale de préparation de la sortie ne prend que 2 semaines. Par conséquent, maintenant la régression est effectuée dans les sprints et uniquement lorsque cela est nécessaire (si les développeurs signalent qu'une régression d'une certaine partie du système est nécessaire).
Mais comme au stade du test de la version, il est nécessaire de vérifier non seulement la nouvelle fonctionnalité, mais également l'état général du système, nous avons commencé à utiliser la stabilisation au lieu de la régression.
La stabilisation comprend:
a) le test des nouvelles fonctionnalités incluses dans cette version par chaque équipe;
b) Le test des zones critiques est un test de la fonctionnalité de base des zones principales du système (ce qui prend évidemment beaucoup moins de temps qu'un cycle de régression complet);
c) tester les bogues trouvés dans les changements d'équipe pour cette version.
Le cycle de développement entier ressemble maintenant à ceci:
Examinons ce qui est nécessaire pour préparer la sortie.
Lorsque la stabilisation est terminée et que le package de lancement est de bonne qualité, avant de le déployer en production, la configuration est testée dans l'environnement de pré-production. Ainsi, les opérations s'exercent à mettre à jour l'environnement et les testeurs vérifient la configuration avec le package de version actuel avant la version réelle.
Vous pourriez penser que 2 semaines de préparation pour la sortie sont trop longues et qu'il reste peu de temps pour les tests dans le sprint. Mais généralement, il faut 4 à 6 jours à un testeur pour se préparer à une sortie. Cela dépend de:
- la complexité et l'étendue des fonctionnalités que son équipe va publier,
- participation du testeur à l'équipe de publication de la version actuelle.
Tous les testeurs du projet (y compris l'équipe de publication) participent aux tests de stabilisation; le test de la configuration et de la version elle-même est effectué uniquement par l'équipe de publication.
Le calendrier de test de la version générale ressemble à ceci:
Étant donné que les zones critiques et la configuration contiennent des tests constants, nous avons partiellement automatisé ces cas de test. Cela a considérablement réduit le temps de test en préparation de la sortie, donc à l'avenir, nous prévoyons d'étendre l'utilisation des autotests.
Du point de vue de l'organisation des tests, un coordinateur QA (quelqu'un des responsables QA) est sélectionné pour chaque version. Le délai de mise en production est généralement planifié pour un coordinateur QA plus que pour les testeurs réguliers, car le coordinateur QA a plus de responsabilités. Ceux-ci inclus:
- définir l'équipe de publication et vérifier la disponibilité de tous ses membres au moment de la sortie;
- préparation des plans de test pour la sortie;
- lancer des autotests au stade de la stabilisation et des tests de configuration;
- coordination du travail des testeurs lors des tests de version;
- aider les testeurs à résoudre toutes sortes de problèmes liés à la publication;
- le contrôle de la mise en œuvre des tests et, si nécessaire, la redistribution de la charge pour aider à tester les équipes surchargées (il peut s'agir de testeurs d'autres équipes qui ont déjà terminé les tests de version, ou de développeurs d'équipe, ou du coordinateur QA lui-même).
Et bien sûr, aucune version n'est complète sans problèmes. Nous les résolvons et élaborons un plan sur la manière de les éviter à l'avenir. En voici quelques-uns que nous avons rencontrés ces derniers temps:
- : , - , , - .
: . - : pre-production . — .
: . - : , .
:
a) - ( , ),
b) ,
c) ,
d) , . , , .
Solution: dans de tels cas, nous essayons d'avoir le temps de tester tout ce qui est nécessaire à la sortie, même si cela nécessite une participation à la sortie pour les 2 semaines ou des heures supplémentaires, puisque la publication est une tâche plus prioritaire que les tâches de sprint.
Mais quels que soient les problèmes, nous pouvons toujours les résoudre par les forces de l'équipe de publication ou en impliquant des personnes compétentes dans un domaine particulier - l'essentiel est que ce soit toujours un travail d'équipe bien coordonné menant à un bon résultat.
Travailler en quarantaine: comment assurer le travail des testeurs
Dans notre projet, le travail depuis le bureau est une condition préalable. Ceci est fait pour que n'importe quel participant au processus puisse être trouvé pendant les heures de travail - s'il ne répond pas soudainement dans les chats, les personnes qui travaillent avec lui peuvent l'informer que certains de ses collègues ont besoin de lui. C'est pertinent, car certaines des équipes sont en Norvège et d'autres à Saint-Pétersbourg.
Pendant la pandémie, lorsque la Norvège et la Russie ont envoyé la majorité de la population à l'auto-isolement, nous avons dû passer au travail à distance.
Nous avons continué à travailler comme d'habitude: les équipes terminaient toujours les sprints avec une bonne productivité de sprint, et les versions étaient publiées à temps.
La communication restait encore à un bon niveau - l'application Teams couvrait tous les besoins: il y avait des conversations actives dans le chat, les réunions se sont déroulées sans problème; s'il y avait des questions à discuter d'urgence, ils ont appelé n'importe quel participant au projet.
Du point de vue de l'organisation des tests, il n'y a pas eu de problèmes: pendant les heures de bureau, tous les testeurs ont répondu dans des chats et ont rapidement participé au test de la version. Au cas où nous aurions besoin de trouver quelqu'un, mais qu'il ne répond pas dans le chat, nous avons préparé une liste de numéros de téléphone portable, mais nous n'avons jamais eu à l'utiliser.
Le seul problème auquel nous avons été confrontés lorsque nous étions assis à la maison à un travail à distance - en raison des particularités du VPN, il était impossible de tester le système dans un environnement d'équipe à partir de téléphones / tablettes. Mais ce problème a été contourné - grâce au chef de projet et au service informatique, qui ont trouvé une solution. Nous avons commencé à utiliser des proxies lors de la connexion sur un réseau domestique, et nous pouvons maintenant tester sur des appareils mobiles depuis la maison.
Aujourd'hui, nous retournons partiellement au travail au bureau, mais une partie de l'entreprise continue de travailler à domicile. Et même en étant dans différentes parties de la ville, nous restons une seule entreprise très unie qui continue de travailler dans des moments aussi difficiles, avec de telles conditions de non-travail, lorsque les enfants et les animaux domestiques exigent de l'attention, Internet ralentit et disparaît périodiquement, les lumières s'éteignent et il y a tellement de distractions. des facteurs que vous ne comprenez pas du tout, comment avez-vous réussi à travailler à nouveau?!
Mais ensemble, nous survivrons à tout cela et, enfin, revenant à une vie de bureau à part entière, nous nous sourirons encore plus largement que d'habitude.
Conclusion
Pour résumer ce qui précède, je voudrais noter quelques points:
- , , . — .
- , , .
- , , , — . , .