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

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.

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.

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, 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é.

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é?

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.

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.

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.

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.

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.

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.

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.