Quelles sont les informations que vous demandez lors de la résolution d'un problème sur la boîte d'un client à l'aide d'une application de bureau?

Question

Nous écrivons une application de bureau Windows qui est installé sur quelques milliers d'ordinateurs que nous avons pas accès. Lorsque l'un de ces utilisateurs rapporte un bug, même si la description est assez complet, il existe d'autres informations qui peuvent être utiles.

Nous travaillons actuellement sur un agent de rétroaction automatique, ce qui signifie que nous aurons accès à des informations très détaillées. Mais comme un enfant dans un magasin de bonbons, nous ne sommes pas sûrs où commencer. Quelles informations vous inclure dans votre trousse de commentaires dans le même cas? Ce qui est utile pour nous aider à s'y reproduire l'erreur?

Ce que nous avons à ce jour est:

• Le numéro de version de notre application,
• OS et numéro de version du système d'exploitation
• Informations Proxy
• Version .NET et le numéro de mise à jour
• Informations spécifiques à notre application (par exemple. versions de données)
• les journaux d'accès et d'erreur

Notez que ceci est similaire à cette question , mais nous n'êtes pas intéressés à obtenir les informations quand le programme se bloque que nous sommes lorsque l'utilisateur éprouve un bug.

Edit: Précision: ne demande pas quelles informations l'utilisateur doit donner dans le cas d'un bug, mais quelle information devrait nous rassembler programmaticaly

?

Answer 1

Même si vous avez toutes ces informations, reproduire le problème peut être difficile. Lorsque les utilisateurs décrit comment ils ont créé le bug ils sont souvent trompés sur les principales étapes - il est difficile pour eux de savoir quels domaines sont critiques quand ils ne connaissent pas le fonctionnement interne de l'application. Vous voudrez peut-être mettre en place un moyen de suivre les actions des utilisateurs, telles que la gestion des événements de niveau racine ou d'autres moyens - si vous avez undo / redo fonctionnalité alors je suis sûr que cela suffirait. Vous pouvez ensuite inclure les dernières étapes (x) de la chaîne d'action dans le rapport d'erreur.

Answer 2

Edit: Je pense que j'ai mal lu votre question. Je pensais que vous parlez de ce que l'information pour obtenir d'un client de rapporter un bug, plutôt que de planifier déjà ce que je décris ici. Je laisse pour référence de toute façon.

Dans une situation similaire, malgré moins d'utilisateurs, notre application a un bouton « journaux Package pour le soutien » qui va créer un fichier zip avec tous les fichiers journaux et le fichier de projet en cours, le cas échéant. Toutes les autres informations que vous avez décrit fait déjà partie de l'un des fichiers journaux. De cette façon, un client peut facilement envoyer le fichier ZIP pour nous, ce qui peut être fait à partir de la fenêtre principale de l'application sans ouvrir un fichier de projet ou la connexion à une interface réseau, qui sont les deux principaux points où quelque chose peut mal tourner. Cela rend beaucoup plus facile que de compter sur l'utilisateur fournissant des commentaires « à la main ».

En dehors de cela, les étapes exactes pour reproduire le problème doit être disponible. La plupart de c'est généralement dans le fichier de projet lui-même (qui est dans le fichier ZIP que nous obtenons), avec seulement quelques étapes manquantes.

Les choses qui semblaient importantes pour cela, autre que ce que vous déjà inscrit:

• utilisateur / informations de compte. Cela peut aider à des problèmes d'autorisation. Vous pouvez inclure des choses comme fuseau horaire, lieu, thème Windows.
• Configuration de l'application, y compris où il est installé.
• Comme nous l'avons dit, le fichier actuel que l'utilisateur travaille avec, parce que cela peut être la cause du problème.
• Paramètres utilisateur, à savoir les données des magasins d'applications par utilisateur. Vu les choses avec ces étranges. liste MRU peut également être utile.

Answer 3

En dehors de l'état de base de l'application (version, configuration, etc.), les informations les plus importantes pour obtenir est:

• L'étape (s) nécessaire pour reproduire l'erreur ou bug, y compris les données utilisées si possible
• La sortie attendue
• La sortie réelle
• Les coordonnées au cas où vous devez suivre (si votre logiciel est consommé de façon anonyme)

Ce sera suffisamment d'informations pour résoudre 99,9% des problèmes. Pour le reste, le suivi et obtenir des informations détaillées que vous pensez aider à résoudre le problème (qui, espérons-le, sera beaucoup mieux comprise à ce stade).