Équipes QA : signaler un défaut et suivre sa correction
Un testeur signale un défaut avec sa gravité, les étapes pour le reproduire et l'environnement concerné, y joint un enregistrement ou une capture d'écran, et marque la frame ou le pixel exact. Le pack de cycle de test passe par les étapes planifié, en cours, défauts ouverts, retest et validé. Un retest qui échoue à nouveau retourne à l'étape défauts ouverts via un chemin défini, de sorte qu'une correction inefficace ne disparaisse pas dans un nouveau ticket.
Signaler un défaut
Le type de ticket de bug demande de définir la gravité (bloquante, majeure, mineure ou cosmétique), les étapes pour le reproduire, ainsi que le build ou l'environnement concerné. Des champs personnalisés permettent d'ajouter tout autre élément suivi par l'équipe.
Une capture d'écran ou un enregistrement d'écran s'associe au défaut. Une note sur un enregistrement est ancrée à une frame. Une note sur une capture d'écran peut être dessinée directement dessus. Le développeur ouvre directement le repère visuel, plutôt qu'un paragraphe tentant de le décrire.
- Gravité : bloquante, majeure, mineure, cosmétique
- Étapes pour reproduire et environnement concerné
- Notes ancrées aux frames sur les enregistrements, notes dessinées sur les captures d'écran
Le cycle et le côté développeur
Le pack de cycle de test passe par les étapes planifié (48 heures), en cours (72), défauts ouverts (72), retest (48) et validé. L'étape en cours ne peut pas démarrer tant que la checklist du plan et des cas de test n'est pas finalisée. L'étape retest dispose d'un chemin de retour vers défauts ouverts intitulé "toujours en échec".
Le pack de correction de bug correspond au côté développeur : tri, reproduction, correction, vérification et déploiement. L'étape de vérification peut renvoyer le ticket à l'étape de correction avec l'étiquette "toujours défectueux". Le pack logiciel conclut la QA par une validation de version, qui est une étape de validation imposée par le moteur.
Un défaut qui s'avère être le même bug qu'un autre lui est associé : le lien est qualifié de "lié", "doublon" ou "clone", et le blocage reste lié à la dépendance que le workflow lit déjà. Le temps passé sur la correction est enregistré sous forme d'entrées qualifiées sur le ticket le jour où le travail a été effectué, et s'ajoute au total de la semaine de l'utilisateur et au total du projet par rapport aux estimations.
Limites en toute franchise
L'enregistrement d'une exécution de test en tant qu'objet propre n'est pas disponible ici ; une exécution est actuellement une simple checklist sur le cycle. Nous préférons que vous le sachiez dès maintenant plutôt que de le découvrir après un essai.
Questions fréquentes
- Peut-on envoyer à un développeur un enregistrement d'échec avec le moment précis marqué ?
- Oui. Un enregistrement associé au défaut accepte des notes ancrées aux frames, et une capture d'écran accepte des notes dessinées.
- Que se passe-t-il lorsqu'un retest échoue ?
- L'étape de retest dispose d'une transition de retour vers défauts ouverts étiquetée "toujours en échec". Le défaut y retourne sans qu'un nouveau ticket soit créé.
- La validation QA est-elle un véritable point de contrôle ?
- Sur les packs qui utilisent une étape de validation pour la signature finale, oui : le travail ne peut pas continuer sans qu'une décision soit enregistrée. Le pack de cycle de test se termine à l'étape validé en tant qu'étape terminée ; le pack logiciel utilise la validation de version comme point de contrôle.