Que devrait signaler un testeur?

Question

J'ai un site web que je construis pour un client. J'ai maintenant un testeur sur le projet avec moi.

Je pense que les testeurs sont nécessaires. VRAIMENT! Je ne peux pas tester mon propre code. J'apprécie également la valeur d'un nouvel ensemble d'yeux. Mais quels sont les désirs de reportage?

Il est facile de dire que tout doit être rapporté, mais je ne l'ai pas quelqu'un entre moi et le testeur de filtrer les demandes sans importance. Le testeur ne connaît pas bien le système ni l'utilisateur cible. Elle m'attribue des tâches et non le chef de projet. Je pense que cela va changer bientôt, mais jusqu'à ce qu'il le fasse, que recommandez-vous? Il semble y avoir une croyance que nos utilisateurs n'ont jamais utilisé l'interent avant tout, et ils sont aussi stupides que des roches.

Le problème que j'ai est que tout le testeur suggère est accepté automattically et qui me sont confiées.

J'ai de nombreux cas qui me font tomber ma mâchoire et dire « Vraiment? Êtes-vous sérieux? Cela mérite d'être un problème? »

Ex: Nécessité d'ajouter du texte en haut de la page qui dit « * = requis » pour les champs obligatoires.

Avez-vous déjà ressenti cela? Comment avez-vous géré cela?

Pour l'instant, je fais comme je l'ai dit, mais je fais clairement que je ne suis pas d'accord.

Answer 1

Il me semble que votre testeur fait ce qu'il faut. Vous ne pouvez assumer aucun niveau d'expertise utilisateur lors du test d'une application. Si un utilisateur peut casser quelque chose, ils le feront.

Vous et votre testeur devez établir une échelle de gravité. Les valeurs aberrantes (celles que n'importe qui avec l'expérience d'Internet pourrait probablement contourner/n'atteindraient jamais) seraient considérées basse priorité et resteraient sur le brûleur arrière jusqu'à ce que vous assommiez les articles de haute priorité.

... ces valeurs aberrantes doivent tout de même être enregistrées car elles peuvent définitivement revenir vous mordre le cul à la fin.

Answer 2

Je signalerais au client ce que chaque changement coûtera en termes de temps et d'argent. Les choses qui sont des bugs légitimes que vous aurez probablement besoin de corriger sur votre propre temps (sauf si votre contrat dit le contraire). Les choses qui sont de conception/questions subjectives vous devriez être en mesure d'attribuer un coût à. Dites au client ce que cela lui coûtera et il pourra décider s'il veut continuer ou non.

Nous espérons que vous avez une sorte de spécification du projet que le client a signé sur de sorte que vous savez quand le projet est terminé et ce genre de choses ne sont pas inclus dans le périmètre du projet. Sinon, vous pourriez avoir un peu de bagarre entre vos mains. Pour les changements que vous pensez être en dehors de la portée du projet, vous pourriez avoir besoin de faire des compromis - peut-être les facturer à un taux moins cher ou partager le coût avec eux. Si vous êtes dans cette situation, c'est une bonne expérience d'apprentissage pour que tout soit documenté dans la spécification du projet afin qu'il n'y ait aucune question sur ce qui sort de la portée du projet. J'ai été là - une expérience comme celle-ci est suffisante pour vous apprendre à mettre plus de travail dans vos spécifications.

Answer 3

Vous devez ajouter des priorités pour vos problèmes. Cela vous permettra de faire les problèmes importants en premier, et les problèmes esthétiques en dernier.Voici les priorités exemple de Jira:

• Priorité 1 - un plantage reproductible; problème bloquant tout autre test ou développement d'une caractéristique spécifique; perte de données persistantes de l'utilisateur; énorme fuite de mémoire
• Priorité 2 - un problème majeur qui doit être corrigé avant la publication du produit; empêche les utilisateurs d'utiliser une fonctionnalité; affecte négativement le partenaire; fuite de mémoire importante dans les fonctionnalités fréquemment utilisées
• Priorité 3 - un problème mineur devant être corrigé avant la publication d'un produit; n'empêche pas les utilisateurs d'utiliser un produit; problème d'utilisabilité très visible; fuite de petite mémoire dans des fonctionnalités rarement utilisées
• Priorité 4 - un problème purement cosmétique; n'affecte pas la fonctionnalité

Answer 4

Rapporte tout et triage. Après un peu de temps, elle commencera à comprendre ce qui passe après le triage et ce qui ne l'est pas. Les humains peuvent apprendre; apprendre.

Answer 5

En fait, il semble que votre testeur fasse la bonne chose (et le texte pour "* = requis" est une très bonne idée). En plus des suggestions sur la hiérarchisation des rapports, je suggérerais que vous classiez les rapports selon qu'ils se rapportent à l'expérience utilisateur ou à la fonctionnalité.

Answer 6

Vous et le testeur ne serez jamais d'accord exactement sur ce qui "doit" être signalé. Réglez juste la priorité sur les problèmes correctement, et continuez à fixer les choses prioritaires en premier.

Une chose que vous ne voulez absolument pas faire est de décourager le testeur de produire des bogues. Ça va revenir vous mordre quand quelque chose est complètement brisé, et ils disent "Je pensais que c'était comme ça que ça fonctionnait". Assurez-vous de communiquer correctement le calendrier et l'état du développement, afin de ne pas perdre de temps à tester les fonctionnalités qui ne sont pas suffisamment complètes.