Amener les utilisateurs à rédiger des rapports de bogues décents et utiles

Quelqu'un connaît-il un bon moyen d' amener les utilisateurs à rédiger un rapport de bogue semi-décent (lire: utile ) ?

Nous voulions mettre en place quelque chose qui aurait du sens pour la plupart des utilisateurs (être facile à lire et à comprendre), tout en fournissant également des informations utiles aux développeurs.

Cela ne fonctionne pas lorsque je clique sur le bouton bleu! Ahhh, je viens de perdre une semaine de travail ... pour que ça marche.

n'est pas très utile, comme ça.

J'ai commencé à fixer une liste, mais j'ai pensé vérifier avec vous si une méthode similaire existe déjà.

Le moyen le plus efficace d'amener les utilisateurs à rédiger des rapports de bogues décents et utiles est

1. pour leur permettre de voir leurs rapports en ligne ...
   ^{[Système] Merci d'avoir signalé, vous pouvez trouver l'état de votre demande ici: ...}
2. ... ainsi que l' évaluation et les commentaires de l'ingénieur affecté ...
   ^{[Ingénieur] Demande rejetée, car les détails suivants sont manquants: ...}
3. ... avec une option pour modifier / améliorer leur rapport.
   ^{[Utilisateur] Les détails demandés sont ajoutés, veuillez réévaluer: ...}

J'irais jusqu'à prétendre que c'est le seul moyen efficace.

Avouons-le, la compétence pour rédiger efficacement des rapports de bogues ne vient que de l'expérience. Il faut apprendre à acquérir de l'expérience. L'apprentissage implique de pratiquer, d'obtenir des commentaires et de s'améliorer.

Les rapports de bogues en ligne modifiables par l'utilisateur sont le moyen le plus efficace d' apprendre aux utilisateurs à s'améliorer .

• ^{Les options alternatives à ce qui précède sont 1) pour organiser des sessions d'apprentissage en face à face avec les utilisateurs (oui, bien sûr, surtout quand il y en a des milliers dans le monde). Ou 2) expliquez-leur les choses par téléphone ("regardez, si vous ne pouviez voir que les conneries que vous avez écrites à la ligne 225 ..."). Quoi d'autre? Oh 3) par e-mail, bien sûr "dans le courrier que vous nous avez envoyé il y a deux mois, vous avez mentionné ... non pas cet e-mail, vous nous avez envoyé cinq e-mails ce jour-là, trois d'entre eux avaient pour sujet Re: cliquez sur le bouton bleu , regardez le deuxième, celui avec une capture d'écran de 10 Mo attaché à lui ... quoi? vous ne le trouvez pas? "}

À mon avis, ce qui est plus important, c'est d'utiliser le bogue pour établir un contact permanent significatif avec l'utilisateur. La rédaction et la compréhension des rapports de bogues est une compétence, et mon conseil serait de faciliter le plus possible la prise de contact par l'utilisateur, puis de faire progressivement ses commentaires plus utiles au besoin.

Par exemple, récupérez simplement l'e-mail de l'utilisateur et donnez-lui un champ en texte brut avec le texte suivant à compléter:

"I did _____ , and expected ______ to happen, but ______ happened instead."

Après avoir reçu l'e-mail, effectuez une réponse automatique pour obtenir une double option pour confirmer qu'ils ont soumis le bogue, vous l'avez reçu et le suivi du bogue est correct.

Vous pourriez envisager de prendre quelques idées de Mozilla et Sun sur ce sujet:

• Consignes de rédaction de bogues - Article Mozilla MDN
• Comment écrire un bug correct - article Mozilla QMO
• Comment rédiger un rapport de bogue utile - Article Sun SDN

En particulier (à partir de la page Mozilla "Comment écrire un bug correct"):

Aperçu général d'un rapport de bogue

Résumé : Comment décririez-vous le bug en moins de 60 caractères? Il doit identifier rapidement et uniquement un rapport de bogue ainsi qu'expliquer le problème, et non la solution que vous avez suggérée.

Bon : «L'annulation d'une boîte de dialogue de copie de fichier bloque le gestionnaire de fichiers»

Mauvais : "Le logiciel plante"

Mauvais : "Le navigateur devrait fonctionner avec mon site Web"

Composant : Dans quelle sous-partie du logiciel existe-t-il? Ce champ est obligatoire pour soumettre un rapport de bogue. Cliquez sur le mot «Composant» pour voir une description de chaque composant. Si aucune ne semble appropriée, mettez en surbrillance la composante «Général».

OS : Sur quel système d'exploitation (OS) l'avez-vous trouvé? (par exemple Linux, Windows XP, Mac OS X.) Exemple: «Si vous savez que le bogue se produit sur plusieurs types de système d'exploitation, choisissez« Tous ». Si votre système d'exploitation n'est pas répertorié, choisissez Autre ».

Description : les détails de votre rapport de problème, notamment:

- Vue d'ensemble : il s'agit d'un retraitement détaillé plus large du résumé. Un exemple serait: "Glisser-sélectionner n'importe quelle page plante les builds Mac dans la fonction NSGetFactory".

- Build Id : pour le trouver, allez sur la page «à propos de» via la barre d'emplacement ou, si vous avez l'extension Nightly Tester Tools de MozQA, allez dans Outils | Nightly Tester Tools et sélectionnez l'option qui contient la sortie de l'ID de build. Il devrait ressembler à ceci: "Mozilla / 5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: 1.9.1b3) Gecko / 20090305 Firefox / 3.1b3".

- Constructions et plates-formes supplémentaires : si le bogue se produit ou non sur d'autres plates-formes (ou navigateurs, le cas échéant). Il devrait ressembler à ceci: "N'existe pas sur Mozilla / 5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: 1.9.1b3) Gecko / 20081107 Firefox / 3.1b2".

Étapes à reproduire : étapes minimisées et faciles à suivre qui déclencheront le bogue. S'ils sont nécessaires, assurez-vous d'inclure toutes les étapes de configuration spéciales. Un bon exemple de ceci ressemblerait à ceci: 1) Affichez n'importe quelle page Web. (J'ai utilisé l'exemple de page par défaut, http://www.google.com/ ). 2) Faites glisser-sélectionnez la page. Plus précisément, tout en maintenant le bouton de la souris enfoncé, faites glisser le pointeur de la souris vers le bas à partir de n'importe quel point de la région de contenu du navigateur vers le bas de la région de contenu du navigateur.

Résultats réels : ce que l'application a fait après avoir effectué les étapes ci-dessus, par exemple: l'application s'est bloquée.

Résultats attendus : ce que l'application aurait dû faire si le bogue n'était pas présent, par exemple: la fenêtre devrait défiler vers le bas. Le contenu défilé doit être sélectionné. Ou, au moins, l'application ne devrait pas planter.

Il y a Comment rapporter des bogues efficacement par Simon Tatham. Il explique bien les choses, pour le rendre facile à comprendre pour les utilisateurs moins expérimentés. Cependant, l'inconvénient est qu'il s'agit d'un peu de texte. Lorsqu'un utilisateur essaie de signaler un problème mais ne parvient pas à l'expliquer, vous ne pourrez généralement pas le convaincre de lire tout cela.

Vous pouvez poser des questions faciles à comprendre et faciles à répondre aux utilisateurs pour qu'ils s'attendent à des rapports utiles.

Par exemple, "Quelle a été votre dernière action avant cette erreur?", "Avez-vous essayé de ... juste avant cette erreur?".

Aucun utilisateur ne vous rédigerait un rapport de bug comme: "Mon pilote vidéo n'est pas à jour. Votre bibliothèque graphique n'est peut-être pas compatible avec les anciens pilotes graphiques."

En supposant que la base d'utilisateurs est constituée d'utilisateurs finaux qui ont eu un problème avec le logiciel que vous avez écrit ....

Ce n'est pas le travail de vos utilisateurs de devenir un ingénieur logiciel compétent ou un professionnel des tests, et vous ne devriez pas vous y attendre. Vos utilisateurs sont des gens ordinaires qui s'attendent à juste titre à ce que le logiciel "fonctionne tout simplement". Si ce n'est pas le cas, ils rapporteront tout ce qu'ils pensent qu'ils veulent pour attirer votre attention. Vous ne pouvez pas changer cela et ne devriez pas essayer de le faire. Toute tentative d'insister sur le type de rapports qu'un professionnel est censé faire entraînera la perte du rapport de bogue, et le client - "J'ai eu un problème avec ce logiciel, mais au lieu de m'aider, ils ont été remplis sortes de formes inutiles qui ne signifient rien et n'ont aucune valeur pour moi. Je vais trouver des logiciels qui fonctionnent réellement. ".

ce n'est pas leur travail .....

Si vous voulez de bons rapports de bogues, faites appel à des professionnels pour trouver vos bogues. Si vous, en tant que développeur de logiciels, ne vous inquiétez pas de traiter avec des clients, employez quelqu'un qui le peut.