L'AQ doit-elle trouver des scénarios reproductibles?


10

Parfois, mon équipe d'assurance qualité signale des bogues, mais ni moi ni eux n'avons la moindre idée de la façon de les reproduire. Cela conduit à des sessions de débogage très longues et frustrantes qui parfois ne donnent même pas de résultats.

Mon logiciel est fortement lié à du matériel propriétaire, de sorte que les bogues peuvent provenir de plusieurs directions à la fois.

Dois-je m'attendre à plus de leur part que "votre logiciel s'est écrasé lorsque j'ai appuyé sur un bouton" ou dois-je comprendre moi-même ce qui s'est passé?

ÉDITER:

Un de mes collègues a souligné que nous sommes probablement tous des développeurs ici, donc les résultats pourraient souffrir un peu de biais


1
Ce n'est pas vraiment une réponse, mais il convient de souligner qu'en plaçant (plus) de journalisation dans votre application, vous pouvez réduire quelque peu ce problème. Peut-être que votre version de test pourrait être définie sur un mode d'enregistrement détaillé qui vous donnerait de vagues étapes de reproduction pour vous aider dans les sessions de débogage?
ChrisFletcher

Pas vraiment, les tests devraient faire ça. L'AQ devrait faire l'AQ.
mattnz

1
Pensez à ajouter à votre produit une logique qui vous aide à retracer les étapes suivies par l'utilisateur et à disposer d'un bouton QA qui permet au rapporteur de bogue d'extraire facilement lesdites informations de votre produit et de les ajouter au rapport de bogue.

Au moins une capture d'écran de la situation réelle aiderait la plupart du temps à reproduire l'erreur. (voir le commentaire de journalisation ci-dessus). Usersnap est un outil pour un meilleur rapport de bogues et un gain de temps de communication.
Gregor

Réponses:


31

Le contrôle qualité doit toujours essayer de rendre les bogues aussi faciles à reproduire que possible et la description du bogue doit contenir les étapes suivies.

Cependant, s'ils ne peuvent pas facilement reproduire les bogues, ils doivent toujours être entrés dans la base de données de bogues avec un titre / des titres appropriés et une description complète de ce qu'ils ont fait pour provoquer le bogue. La description du bogue doit clairement indiquer qu'ils ne peuvent pas reproduire le bogue (peut-être avec un commentaire du type "essayé cinq fois, c'est arrivé une fois"). De cette façon, si quelqu'un d'autre voit le même bogue, il peut ajouter à la base de données des bogues avec ses résultats et vous obtenez également autant d'informations que possible, ce qui pourrait être vital plus loin pour vous faire gagner du temps à dépister le problème.

En outre, vous pouvez filtrer les informations - il peut y avoir beaucoup de bogues dans différents systèmes que vous savez tous liés à (par exemple) une zone du code - si le contrôle qualité ne rapporte rien (car ils ne peuvent pas les reproduire) ), ces informations ne vous parviennent pas.


... a full description of what they did to cause the bug. En quoi est-ce différent d'un dépôt?
Steven Evers

13
@SnOrfus: Les repos sont, par définition, reproductibles. Si vous trouvez un bogue mais que vous ne pouvez pas le reproduire plus tard, il est toujours utile de savoir ce que vous faisiez à ce moment-là, pour aider à retrouver la cause.
BlueRaja - Danny Pflughoeft

3
@SnOrfus: The software crashedvs The software crashed editing foowidgetsvs The software crashes when viewing a foowidget and toggling the frobulator 10 times followed by pressing this key sequence (stack trace attached). Le dernier détail n'est peut-être pas évident, mais avoir la deuxième description au lieu de la première est certainement utile.
Daenyth

@Daenyth: Assez juste. Je vais peut-être trop loin dans la sémantique d'une description complète .
Steven Evers

Assurez-vous que "Closed Did / Can't not reproduce" est disponible (là et acceptable) à utiliser dans votre traqueur de défauts.
mattnz

13

Il semble que votre service d'assurance qualité effectue trop de tests exploratoires (c'est-à-dire qu'ils n'ont pas un bon plan de test).

Les tests exploratoires sont bons et identifient les zones problématiques, mais à partir de là, ils devraient définir des scénarios de test reproductibles (c'est-à-dire un plan de test) à effectuer qui révéleront des bogues spécifiques.

Il y a un certain nombre de raisons pour lesquelles une repro correcte est nécessaire (pas seulement bonne, mais nécessaire):

  1. Vous devez faire un repro pour pouvoir déboguer / rechercher la cause.
  2. Le contrôle qualité devra pouvoir vérifier le correctif une fois que vous aurez terminé.
  3. D'autres tests réussis devront effectuer des régressions sur les bogues précédents.
  4. Les bogues connus peuvent être éliminés si l'exposition est trop faible ou si la reproduction est trop peu probable.

Donc, comme le note SteveCzetty: fermez-le comme aucune repro et retournez au travail.


3
Le problème avec les étapes de reproduction est qu'en général, avec les bogues de crash, ils ne sont pas anticipés ou recherchés et ils se produisent généralement au milieu d'un plan de test. Ils devraient essayer de le reproduire, mais cela est souvent imparfait. Pour les tests manuels, un bon logiciel d'enregistrement d'écran de bureau pendant les cas de test peut capturer toutes les étapes et tous les horodatages qui ont conduit au crash, ainsi que les erreurs simples ou les détails apparemment sans conséquence que la personne chargée de l'assurance qualité aurait pu manquer lors de ses étapes de reproduction. Avec cela et les journaux de test, un développeur devrait avoir une image plus claire.
maple_shaft

3
@maple_shaft C'est en effet vrai - je ne m'attends pas à ce que tous les bogues de QA soient 100% reproductibles. L'enregistrement d'écran est une option intéressante et mérite certainement plus d'attention, car il permet plus de flexibilité sans renoncer à la possibilité de surveiller l'épaule du testeur.
Michael K

2
@maple_shaft: Je suis d'accord, et MTM a cela intégré. Dans ce cas cependant, il y a une différence significative entre ce qu'Eric obtient ("Il y a eu un plantage") et quel est le meilleur scénario (Journaux d'événements + Journaux d'application + Vidéo + Enregistrement d'action + Intellitrace + Repro détaillé). Le travail d'IMO / E QA ne se termine pas lorsque l'écran bleu se produit - et une repro est la première chose qu'ils devraient essayer de produire, même si ce n'est pas toujours faisable.
Steven Evers

@SnOrfus Je ne pouvais que rêver de travailler avec une équipe QA aussi professionnelle. Dans la plupart des organisations dans lesquelles j'ai travaillé, ce sont les lies qui étaient trop incompétentes ou paresseuses pour les couper en tant que développeurs de logiciels. Étonnamment, la meilleure équipe d'AQ avec laquelle j'ai travaillé a été complètement délocalisée, probablement parce qu'ils veulent réellement faire des tests d'AQ.
maple_shaft

@maple_shaft: Là où je travaille, avant de passer de QA à Dev, nous faisions déjà la plupart de cela (la vidéo prend des craploads d'espace disque dur lorsque vous avez 400000 cas de test).
Steven Evers

7

Si le bogue ne peut pas être reproduit de manière cohérente, comment le contrôle qualité pourra-t-il savoir s'il a été corrigé?


Oui, c'est un autre problème que je n'ai pas mentionné mais que je rencontre beaucoup. Je reçois un rapport de bogue, j'apporte des modifications, puis je ferme le bogue. QA approuve ensuite la clôture. Quelques semaines plus tard, le problème est rouvert comme non résolu. J'ai aussi beaucoup de problèmes car "le logiciel s'est écrasé", qui devient un grand creuset de tous les bugs possibles
Eric

6

Oui, vous devriez en attendre davantage. Ils devraient pouvoir dire:

1. Démarrage d'une nouvelle instance de programme
2. J'ai appuyé sur le bouton A
3. Saisissez "texte de test" dans le champ NOM DU TEST sur le formulaire n ° 1
4. Appuyez sur le bouton B
5. Observé que le programme s'est écrasé avec ce message (voir capture d'écran ci-jointe).

Si tout ce qu'ils disent est "ça s'est écrasé", ils ne sont pas très bons. Même si les étapes ci-dessus ne sont pas reproductibles à 100%, un échantillon suffisamment grand de ces plantages peut aider à réduire la cause, une fois qu'un motif est détecté.


5

Mon conseil est de lire ces bugs et de leur donner une bonne vieille pensée. Si vous ne pouvez pas trouver de cause potentielle, oubliez-les pour l'instant.

L'assurance qualité doit documenter tous les problèmes rencontrés, même s'ils n'ont aucune idée de la manière dont cela s'est produit. C'est le travail de QA d'essayer de reproduire les problèmes, mais en réalité, cela ne sera pas toujours possible. Parfois, cela n'a rien à voir avec ce qu'ils ont fait au cours des 10 dernières minutes. Quelque chose est entré dans un état invalide il y a un jour, et c'est devenu apparent à cause d'une des 10 dernières étapes.

Avec ces bogues "1 sur 1000", QA devrait essayer de les reproduire un peu. S'ils ne réussissent pas, ils devraient documenter le bogue, puis essayer un peu plus.

La raison pour laquelle ils devraient saisir le bogue assez tôt est que le programmeur connaît le code beaucoup mieux que QA et pourrait immédiatement connaître le problème. Ce pourrait être le code qu'ils ont refactorisé. Il se pourrait que cette fonction qu'ils aient à moitié implémentée ait ensuite oubliée. Ils n'ont peut-être aucune idée, mais cela n'a aucun sens que le testeur perde quelques heures à essayer de reproduire un problème évident pour la personne qui l'a codé. Le testeur peut toujours ajouter plus de détails au bogue ultérieurement.

Le bogue doit inclure autant d'informations que possible. Tout ce dont le testeur peut se souvenir au sujet de la préparation du problème doit être écrit dans les moindres détails. Tous les journaux d'incident, les instantanés de base de données ou les captures d'écran pertinentes doivent également être joints.

Si le bug n'est jamais reproduit, tant mieux! Cela ne fait pas de mal de l'avoir dans la base de données. Si le programme est publié et qu'un utilisateur signale un bogue similaire plus tard, vous pouvez comparer son expérience à ce qui se trouve dans le rapport et rechercher les similitudes.

D'après mon expérience, les bugs les plus juteux ne sont pas trouvés à partir des plans de test suivants. Parfois, vous devez laisser les choses cuire pendant quelques semaines afin d'aligner la lune et les étoiles, ce qui cause un méchant bug. Si l'AQ peut faire un travail de détective et trouver des causes possibles, donnez-lui une tape dans le dos. Mais parfois, qui sait ce qui s'est passé?


+1 pour "Cela ne fait pas de mal de l'avoir dans la base de données"
PhillC

4

De nombreux bogues ne sont pas reproductibles tant que vous ne savez pas comment les corriger. Cela ne signifie pas qu'ils n'ont pas besoin d'être réparés. J'ai corrigé un bug l'an dernier que je ne savais toujours pas comment reproduire. Cela nécessite une combinaison bizarre d'une erreur de transmission synchronisée avec précision avec des données d'ordures très spécifiques dans un certain emplacement de mémoire sur la pile. Malheureusement, un de nos clients a la «chance» de se retrouver dans cette condition tout le temps.

Donc, par tous les moyens, encouragez le contrôle qualité à inclure des étapes de reproductibilité lorsque cela est possible, mais ne les blâmez pas s'ils ne le peuvent pas. Parfois, cela vous aidera à savoir où ajouter la journalisation. Parfois, tout ce qu'il fait est de vous dire ce qui ne cause pas le bogue, mais un rapport de bogue est toujours utile.


2

Si vous voulez dire que le contrôle qualité doit inclure les étapes pour reproduire le bogue si c'est possible, alors la réponse est oui. Si vous voulez dire qu'ils ne devraient enregistrer que des bogues qu'ils sont capables de reproduire, alors absolument pas. Les bogues sont des bogues, qu'ils ne surviennent qu'à minuit à la pleine lune ou à chaque fois que vous le regardez. Certains bogues ne sont pas déterministes (l'exemple classique est une variable non initialisée, où la valeur captée est semi-aléatoire), cela ne signifie pas qu'ils ne devraient pas être enregistrés, examinés et si possible corrigés.

Les bogues non reproductibles devraient généralement avoir une faible priorité, mais ils devraient certainement être enregistrés.


1

OMI, tu devrais. Le contrôle qualité ne fait pas son travail s'il ne peut pas vous donner d'étapes de reproduction. Ne perdez pas votre temps à essayer de reproduire quelque chose que vous ne pouvez pas, fermez-le simplement comme "Ne peut pas reproduire" et continuez.

Votre temps est beaucoup plus précieux que cela.


1

Un rapport de bogue doit contenir:

  • Étapes à reproduire
  • Comportement réel
  • Comportement attendu

Par exemple:

  • J'ai supprimé tous les fournisseurs de la base de données (à l'aide de DELETE * FROM tSuppliers), ouvert la boîte de dialogue fournisseur et cliqué sur la liste déroulante Fournisseur.
  • La liste contenait le message suivant: GUPOS ERROR #0000000: SOMETHING WENT WRONG!. Lorsque j'ai cliqué sur le message, l'application a disparu de l'écran et du Gestionnaire des tâches.
  • Je m'attendais à voir une liste vide ou (de préférence) un message tel que "Aucun fournisseur trouvé". Cliquer sur la liste vide ou le message ne devrait avoir aucun effet. L'application ne doit évidemment pas disparaître sans avertissement en aucune circonstance.

Donc, oui - il devrait contenir les étapes de reproduction. Le fait qu'ils ne ressentent pas le besoin de l'inclure semble indiquer qu'ils pensent que leur travail consiste à "casser le logiciel", plutôt qu'à identifier les défauts.


0

Le contrôle qualité doit pouvoir reproduire les bogues en fonction des étapes entrées. S'ils essayaient dur, mais ne pouvaient toujours pas se reproduire, ils devraient toujours entrer les bogues avec autant de détails qu'ils ont avec l'horodatage afin que les développeurs puissent jeter un œil à l'application et déboguer les journaux pour plus de détails.


0

L'argent est en jeu ici. Pourquoi un membre de l'équipe devrait-il être en mesure de créer une tâche mal définie et à faible chance de succès qui pèse sur un développeur (espérons-le) très bien rémunéré?

Il ne s'agit pas de picorer l'ordre, la hiérarchie, l'arrogance, nous contre eux, ou quelque chose comme ça. Il s'agit simplement d'investir dans des activités qui ajoutent de la valeur au produit.

Lorsqu'il peut être démontré qu'un problème affecte négativement et de manière mesurable la valeur du produit, il doit être étudié, reproduit et corrigé. Corrigez votre pipeline de défauts de produit pour filtrer le bruit.


-1

votre équipe d'AQ craint

Allez vers eux et dites-leur de lire un document que tout testeur professionnel doit avoir imprimé directement dans leur cerveau (j'étais un testeur une fois et je l'ai toujours là, dans mon cerveau): Comment signaler efficacement les bugs .

En particulier, dirigez-les vers la section "Montrez-moi comment me montrer" :

C'est l'ère d'Internet. C'est l'ère de la communication mondiale. C'est l'époque où je peux envoyer mon logiciel à quelqu'un en Russie par simple pression d'un bouton, et il peut m'envoyer des commentaires à ce sujet tout aussi facilement. Mais s'il a un problème avec mon programme, il ne peut pas m'avoir devant lui pendant qu'il échoue. «Montrez-moi», c'est bien quand vous le pouvez, mais souvent vous ne pouvez pas.

Si vous devez signaler un bug à un programmeur qui ne peut pas être présent en personne, le but de l'exercice est de leur permettre de reproduire le problème. Vous voulez que le programmeur exécute sa propre copie du programme, fasse les mêmes choses et le fasse échouer de la même manière. Quand ils peuvent voir le problème se produire sous leurs yeux, ils peuvent le gérer ...


S'ils commencent à vous crier dessus en se plaignant que "les insectes peuvent provenir de plusieurs directions à la fois" , dites-leur qu'ils craignent encore plus que vous ne le pensiez auparavant. Dites-leur que la testabilité est une fonctionnalité qu'ils devraient évaluer parmi les autres fonctionnalités du projet et qu'ils devraient investir des efforts pour obtenir cette fonctionnalité.

  • Les améliorations de testabilité que l'on pourrait obtenir quand il y a un testeur professionnel concentré sur cela pourraient ressembler à de la magie. Je l'ai appris moi-même il y a quelques mois. Un ingénieur QA travaillant avec notre équipe m'a donné une poignée de demandes de testabilité à développer pour certains composants de notre application. Les choses sur lesquelles il a posé des questions n'avaient que très peu de sens pour moi, mais je les lui ai simplement données en supposant qu'il savait mieux en tant que professionnel. Peu de temps après avoir fini, il a trouvé un outil qui a réduit les efforts de test par ordre de grandeur . Il a dit que la plupart de ces informations étaient basées sur ces requêtes cryptiques que j'avais implémentées, allez comprendre.
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.