Bonjour, citoyens Habrovsk!
J'ai décidé d'écrire un article sur le processus d'interaction entre nos testeurs et analystes et sur les bonus que la société SuperJob reçoit de ce processus.
Le travail des testeurs avec des exigences comprend trois étapes: FT Review, FT Coverage, Case Review.
Revue FT
Les exigences sont gérées par les analystes d'Enterprise Architect, puis copiées dans Confluence. Après avoir rédigé les exigences, elles sont envoyées pour examen aux testeurs.
Bien que cette interaction soit effectuée via Google Sheets, il existe:
- Nom FT
- Lien vers FT
- Responsable de FT Analyst
- Statuts des analystes
- Testeur responsable
- Statuts des testeurs
L'analyste met le statut «En révision» dans le paragraphe correspondant du tableau:
À ce stade, dans le cadre de Confluence, des questions sont posées sur certains points des exigences, car la fonctionnalité vous permet d'ajouter des commentaires à des parties arbitraires du texte. Dans les commentaires, des discussions sont en cours, à la suite desquelles le FT est mis à jour.
Une fois les exigences ajoutées et mises à jour, elles sont transférées au développement et aux tests.
Couverture FT
Les cas de test sont écrits dans TestRail; l'architecture de stockage des cas de test répète complètement l'architecture de stockage des exigences. Ceci est nécessaire pour faciliter la recherche, et afin de ne pas réinventer votre vélo, il est plus facile de le prendre chez un analyste voisin.
Les tests couvrent les exigences - chaque élément des exigences, chaque offre est couverte.
Chaque élément des exigences est numéroté; il existe une trace de cas de test pour les éléments des exigences. Séparément, je tiens à noter que dans chaque cas, il existe une version du FT sur laquelle ce cas a été écrit - les exigences peuvent changer et les points en eux aussi, si vous ne tenez pas compte de la version du FT, alors vous ne pouvez pas trouver les fins.
De cette façon:
- Il est facile de vérifier la qualité de la couverture des cas. Devant mes yeux n'est pas une feuille de 50 cas et la même feuille FT à proximité, mais vous sélectionnez un point d'exigences et puis vous voyez quels cas couvrent ce point particulier;
- En cas de modification des exigences, vous pouvez immédiatement voir quels cas vous devez corriger.
Les cas sont écrits en trois versions:
- En-têtes de cas (la plupart d'entre eux). Lorsque l'affaire n'a qu'un titre, par lequel il est clair ce qui doit être fait. Ils sont plus rapides à écrire que les cas de test détaillés et en même temps une couverture transparente:
- Cas de test. Un cas de test détaillé avec des étapes quand il y a beaucoup de nuances dans le cas et toutes ne peuvent pas être mises dans l'en-tête;
- Cas, listes de contrôle. Lorsqu'un cas se compose d'une liste de contrôle pour vérifier une direction de la fonctionnalité. Pour mettre en évidence de tels cas, utilisez dans l'en-tête (cas):
Dans les sections du FT, où il y a des maquettes, le scénario de test «Réconciliation avec la disposition M ...» est créé. Il sert simplement à rappeler qu'il existe une disposition et que sa mise en œuvre doit être vérifiée. Ce cas sans description interne - la liste de contrôle pour la réconciliation avec la mise en page que nous avons décrite dans le règlement.
Examen des cas
Après avoir écrit des cas, le statut de «Revue de cas» est mis dans le tableau général, c'est un signe qu'un autre testeur peut prendre ce FT et effectuer une revue de cas. Cela est nécessaire pour que les cas soient également clairs pour tous les testeurs et afin de parcourir les exigences avec un nouveau look.
En cas d'échec de l'examen, par exemple, de nouvelles questions sont apparues dans le FT ou la couverture est insuffisante - l'exigence est transférée au statut de «Finaliser». Il n'y a pas assez de commentaires dans TestRail pour décrire tous vos souhaits - alors que cela se produit par écrit dans Slack, ce qui n'est pas très pratique pour le suivi.
Si l'examen est réussi, le FT est dans le statut «Terminer».
Dans de rares cas, lorsque les exigences ont été mises à jour après avoir écrit des cas de test sur celles-ci, le FT est transféré au statut «Mis à jour». De plus, le testeur couvrant le FT s'abonne aux mises à jour de la page Confluence. Si les exigences ont beaucoup changé, une tâche est créée pour que le testeur mette à jour les cas.
Conclusion
Qu'est-ce qui nous donne cette approche?
- Tout d'abord, des exigences éprouvées entrent dans le développement. Cela fait gagner du temps aux développeurs, auxquels les illogicalités, les lacunes et les montants de FT n'atteignent tout simplement pas;
- Deuxièmement, les testeurs se préparent pour les tests en parallèle avec le développement, nous réduisons donc le temps nécessaire pour publier les fonctionnalités. Les testeurs peuvent aborder calmement et de manière responsable le processus d'écriture des cas, et non dans le format «Ahhh, une fonctionnalité énorme est tombée, vous devez la verser ce soir. Essayons plus vite! »
- Troisièmement, il s'agit d'une augmentation de la qualité des tests due à l'examen des cas. Dites «non!» un regard flou.
Qu'est-ce que vous n'aimez pas?
- Il y a un écart de temps assez important entre l'écriture de cas et leur exécution sur une fonctionnalité - bien que les cas soient prêts et qu'ils ne puissent être vérifiés, le testeur tombe néanmoins hors contexte;
- Comme je l’ai écrit plus tôt - dans TestRail, il n’y a pas assez de commentaires, comme dans Confluence - vous ne pouvez pas simplement prendre et marquer le problème, en laissant un commentaire.
C'est tout pour l'instant. Merci de votre attention!
Et comment est le processus de travail avec vos besoins?