comment dépannez-vous avec & # 8220; travaille sur ma machine & # 8221; des scénarios

Question

Il arrive souvent que lorsque vous signalez un bogue à un développeur, celui-ci revienne en disant "cela fonctionne sur mon système". bien que ce soit une application de navigateur. Comment procédez-vous pour résoudre ce problème?

Answer 1

Du point de vue de la formation / du processus:

Formez votre équipe à savoir que "travaille sur ma machine". n'est pas une réponse sans sortie de prison.

Disposez d'un serveur de génération automatique .

Avoir un déploiement de test automatisé.

Vos développeurs doivent savoir que " fonctionne " est défini comme "fonctionne sur le serveur de test", pas seulement sur leur machine.

D'un point de vue test / débogage:

Le développeur doit connaître la séquence d'actions à l'origine du bogue.

Vous voudrez peut-être faire une capture d'écran montrant le bogue, ou éventuellement une capture vidéo (à l'aide d'outils tels que Camtasia ). Les gens peuvent être assez mauvais pour décrire la séquence d'actions qu'ils ont effectuées sur un système qui a conduit à l'apparition d'un bogue, c'est pourquoi plus vous pouvez capturer d'informations sur le bogue et sur la meilleure façon de le reproduire.

Du point de vue développement / environnement:

S'il existe véritablement un bogue qui apparaît sur un environnement, mais pas celui du développeur, déterminez s'il est visible sur aucun environnement de développement ou uniquement sur celui de votre développeur.

À partir de là, il s'agit d'essayer de réduire les différences entre les deux environnements afin que votre développeur puisse voir le problème sur sa machine.

Vous pouvez également essayer de résoudre le problème dans l'environnement de production (hors développement).

Les détails de leur mise en œuvre varient en fonction de la plate-forme.

Answer 2

Vous devez donner autant d'informations que possible au développeur. Même des choses que vous ne pensez pas pertinentes.

Je ne peux pas compter le nombre de fois où un problème a été signalé et que je ne peux pas le répéter. Je découvre ensuite un élément d'information que l'utilisateur n'avait pas inclus à l'origine, mais qui était la clé pour le déverrouiller. puzzle.

Vous devez également ne pas accepter cette réponse et dire "il faut bien que quelque chose soit différent entre votre configuration et la mienne, que pouvons-nous nous faire pour résoudre ce problème".

Answer 3

Nous traitons ce problème en disposant d'un environnement de développement en plus du développement local qui soit aussi proche que possible du système de production en termes de configuration, de matériel, etc. En conséquence, presque tous les problèmes qui surviennent dans l'environnement de production sont reproductibles sur ce système de développement même s’ils ne peuvent pas être reproduits sur des machines de développement locales.

Answer 4

C’est une réplique d’évasion que je rencontre souvent avec les équipes. Ma réponse est généralement la suivante: "Vous savez, votre système n’est pas le serveur de production et c’est là où il doit fonctionner". En d'autres termes, cette excuse n'est tout simplement pas acceptable.

Je leur indique également les possibilités:

a. Il existe une différence de configuration entre le système local et le serveur.

b. Certaines dépendances de la fonctionnalité ne sont pas mises à jour sur le serveur.

c. Ils n'ont pas effacé le cache de leur navigateur.

d. Je réplique le problème sur le serveur de stockage intermédiaire et le leur montre.

e. ... et ainsi de suite, selon les cas.

Answer 5

Essayez de recréer autant que possible l'utilisateur qui a trouvé le système du bogue: de la configuration du serveur à la configuration de la machine, y compris le navigateur, le système d'exploitation, etc. Vous devriez probablement avoir plusieurs configurations sur lesquelles tester votre application avant de la publier.

Answer 6

IE Tester est un bon outil pour ce type de dépannage. Si vous avez besoin de tester de nombreux navigateurs, les machines virtuelles telles que Virtual PC sont votre meilleur choix afin que vous puissiez avoir plusieurs configurations de clients sur votre serveur de test.

Answer 7

ahh oui ... la plus ancienne excuse du livre.

En supposant que le développeur et le testeur testent tous les deux sur le même serveur, j'essaierais d'isoler le bogue en identifiant la différence entre la machine des développeurs et celle des testeurs. Peut-être quelque chose de mineur comme la version flash, les différences de navigateur ou l’oubli de vider le cache de votre navigateur

Je vous recommanderais également d'utiliser un cadre de test automatisé et des applications de test sur un serveur de test dédié.

Answer 8

Vous ne pouvez pas faire grand chose en tant qu'utilisateur final, mais en tant que développeur, vous pouvez éviter beaucoup de ces problèmes en incluant beaucoup de journalisation dans le système. Les différences auxquelles l'utilisateur pensera seront simplement les choses simples que vous avez. déjà testé, mais une bonne journalisation vous permet de voir exactement ce qui se passait lorsque le système est tombé en panne. J'ai trouvé pas mal de bugs qui ne pourraient pas arriver de cette façon.