Comment fermer des tâches dans le traqueur de bogues

J'ai écrit cet article dans confluence de travail en 2013. Et au moment d'écrire ces lignes (2019), c'était toujours d'actualité.

Au départ, j'ai écrit la liste de contrôle pour rappel, y compris pour moi-même. Parce que vous devez retourner aux tâches, y compris aux personnes qui ne les ont PAS vérifiées. Par exemple, lors d'une régression, il est nécessaire de vérifier au moins une fonction de base.

Et donc vous ouvrez la tâche, faites défiler jusqu'au dernier commentaire pour voir quelle documentation, ce qui fonctionne, et là ... Elle est vide. Ou le modeste "Tout est vérifié, tout va bien." Où est la documentation? Je ne suis pas dans le sujet de la tâche, je veux en savoir plus!

Ou si le client écrit que quelque chose ne fonctionne pas pour lui et que vous souhaitez vérifier si la situation est couverte par des auto-tests. Vous allez à la tâche et il n'y a pas de lien vers les autotests. Ils n'ont pas écrit du tout? Ou tout simplement pas donné le lien? Je dois découvrir ...


Ainsi, la liste de contrôle pour la fermeture de la tâche est apparue:

1. Vérifiez la tâche (hello cap). Utilisez des listes de contrôle prêtes à l'emploi pour les tâches typiques + évitez les erreurs typiques dans les autotests.
2. Écrivez la documentation à ce sujet (min - utilisateur, max - utilisateur et "pour les collègues").
3. Dans JIRA, laissez un commentaire "J'ai vérifié le noyau de montage ***, client ***, j'ai regardé ceci, ceci et cela, le voici."
4. Attachez des données de test à la tâche si quelque chose a été vérifié manuellement.

C'est un peu "à propos de nous", mais en fait universel. Eh bien, sauf que dans votre entreprise, le testeur n'écrit pas de documentation, alors nous changeons le deuxième paragraphe pour "vérifier que toute la documentation nécessaire est écrite ou mise à jour".

Nous analyserons chaque élément séparément.

La documentation

S'il n'y a pas de documentation pour la tâche (peu importe s'il s'agit d'un bogue ou d'une amélioration), elle est redécouverte.

S'il existe de la documentation, mais dans JIRA il n'y a pas de lien vers celle-ci dans le dernier commentaire, la tâche est redécouverte. (temps difficiles, mesures dures)

Besoin minimum d'écrire / corriger les besoins des utilisateurs.

S'il y a eu des modifications dans les configurations du projet, vous devez vérifier qu'il existe une documentation technique pour une telle modification. Si ce n'est pas le cas, écrivez.

Si des tâches de migration ont été ajoutées, écrivez immédiatement une instruction générale pour mettre à jour la version.

Commentaire

Si vous devez revenir à la tâche plus tard, il est parfois utile de savoir quelle version le testeur a testée et ce qu'il a vérifié (en bref).

Nous écrivons les versions de mercurial, donnons un lien vers la documentation et une brève description: je l'ai vérifié manuellement via l'interface / SOAP / buffer.

Données de test

Si la tâche a été vérifiée manuellement, assurez-vous d'y attacher des données de test (si elles ne pèsent pas 3 To)

Oui, ces données peuvent être obtenues à partir du référentiel partagé, mais elles peuvent déjà être modifiées ou même supprimées. (Nous avons un référentiel commun de données de test, mais tous les fichiers sont stockés sur le disque. Nous l'avons essayé dans le système de contrôle de version, je ne l'aimais pas, personne ne s'y engage du tout, mais ils l'ont mis sur le disque d'une manière ou d'une autre)

Parfois, il semble que ce ne soit que des ordures, ils ont créé une contrepartie ou collecté des sélections par vue.

Mais si, dans six mois, un problème survient chez le client et que les anciennes tâches de lecture sont soulevées, ces fichiers aideront beaucoup, vérifiés plusieurs fois. Mais les données réelles du stockage sont déjà obsolètes.

N'oubliez pas - cela prendra 1 minute pour prendre une requête SQL prête et vérifier par rapport à la base de données. Et encore une fois de s'asseoir et de faire cette demande - cela peut prendre une heure, sinon plus. Économisez votre temps!

Par conséquent:

1. Création d'une base de données à partir de dbStart - pièce jointe dbStart (Excel, dans lequel une tranche de la base de données pour les tests est enregistrée).
2. Nous avons téléchargé les données de test à partir du stockage - nous joignons le fichier téléchargé.
3. Nous les avons téléchargés ailleurs - nous les ajoutons au référentiel et les attachons à la tâche.

Voir aussi:

Comment créer rapidement une base de données de modèles dans Maven? - sur la façon dont nous faisons dbStart pour les tests.

Les commentaires sur les tests, les documents et les données doivent être définitifs. Et pas tant que «j'ai écrit tel ou tel test, trouvé tel ou tel problème» puis la correspondance avec le développeur pour 20 commentaires, et votre «final» s'est perdu quelque part au milieu. Si vous vous perdez - dupliquez (l'ancien peut être supprimé).

Des exemples

Lorsque nous avons recruté de nouveaux testeurs, cet article n'était pas suffisant. Parce que j'ai redécouvert les tâches des juniors et expliqué comment corriger le commentaire final pour qu'il soit compréhensible. Et à leur tour, ils ont demandé des exemples de «comment faire».

Ainsi, dans l'article, un autre bloc est apparu - «Exemples». Il est important de fournir des liens vers des tâches réelles dans la jira de travail + quelques articles supplémentaires en confluence. Les exemples devraient être différents: à la fois pour les commentaires énormes lorsque 200 autotests ont été écrits sur une tâche, et pour les petites tâches auxquelles les gars seront confrontés chaque jour.

Je ne donnerai pas de liens, mais le sens, j'espère, est clair. La section ressemble à ceci:

Exemples de grandes tâches où il y a de nombreux quais et tests:

• TEST-679 - Améliorations de JMS
• TEST-760 - Retour du flux vers différentes sources JMS

Exemples de petites tâches: TEST-816 - extension du modèle de consentement.

Lorsque vous testez «ajouter des fonctionnalités à la démo», portez une attention particulière à la refactorisation - soumettez la documentation au noyau, tous les tests de la démo, et le reste par inclusion, etc. Exemple: TEST-4519 - Ajoutez une réconciliation croisée de FL-IP à la démo.

Exemples de commentaires utiles "comment ai-je testé cela" auxquels vous revenez (il vaut mieux les mettre dans le HOWTO, mais vous devriez les laisser dans la tâche): TEST-812 - Rendre la reconstruction de l'index non bloquante (où mettre le break * pour vérifier)

* Bryak: Breakpoint (argot) - le point d'arrêt du code. C'est lorsque vous exécutez le code source en mode débogage, ces points aident à suivre les paramètres, à localiser l'erreur.

PS - voir d'autres articles de test dans mon blog