🏅 ✋🏻 💩 Modèles de justification des tâches et antipatterns 🤵 📂 🤵🏻

Table des matières

Lorsque vous démarrez une tâche, elle doit être justifiée. Vous devez convaincre le développeur que:

c'est vraiment un bug;
il doit être corrigé;
il doit être corrigé exactement comme nous l'avons dit.

Et parfois vous lisez des bugs (surtout des bugs de débutants) et vous vous demandez:

- Pourquoi est-ce un bug ??

Par exemple, il dit: «Téléchargez le rapport, nous obtenons 57,6. Et ce devrait être - 57,9 ".

La rédaction de la justification résoudra les problèmes:

Les collègues distraient avec les questions «Pourquoi est-ce un bug?», En le sortant de son contexte.
Un mois plus tard, vous avez vous-même oublié, mais, en fait, pourquoi c'était un bug ...

Voir aussi:
Pourquoi une justification dans un bogue est nécessaire - plus en détail sur pourquoi, en général, la justification.

Des centaines de testeurs débutants (étudiants) sont passés par moi. C’est précisément sur leurs tâches que j’ai commencé à poser la question "Pourquoi est-ce un bug?" ... Vous demandez aux gars, et en retour vous obtenez "Oui, c’est évident!". Eh bien, en quelque sorte pas très =))

À travers un tas de tâches et de questions, "Pourquoi?" des modèles de réponses ont commencé à émerger. J'ai souligné les bons et les mauvais schémas. Je veux en parler.

Cet article s'adresse:

Testeurs débutants - apprenez à expliquer correctement votre point de vue;
gestionnaires de tests - pour donner un lien vers leurs Padawans et ensuite se référer aux antipatterns sans autre explication.

1. Antipatterns: mauvaise justification

1.1. De toute évidence

Pourquoi les testeurs n'écrivent-ils pas du tout une justification dans un bogue? Oui, car cela leur semble évident. Et ils projettent leurs pensées sur tout le monde. C'est évident pour moi = c'est évident pour tout le monde pourquoi écrire quelque chose?

Mais en réalité, ce n'est pas le cas, car chaque personne est dans une sorte de contexte. Et ce qui est évident pour vous n'est pas du tout un fait évident pour quelqu'un d'autre.

Regardons des exemples simples. Lisez le mot que j'écrirai ci-dessous - qu'avez-vous pensé en le lisant? Quelles associations vous sont venues à l'esprit?

LOCK

Une serrure de porte ou une immense forteresse de pierre?

LE MARIAGE

Un mariage ou un iPhone cassé?
...

Oui, ce sont des homonymes. Mais ils montrent très clairement le problème «c'est évident». Il est évident pour vous que le château est un château, et pour moi que c'est un château.

Et si vous écrivez dans un bug:

Résultat
57,6

Résultat attendu
Évidemment, il devrait y avoir 57,9

Cela ne répond pas à ma question "POURQUOI?" Que signifie «évident»? Expliquez-moi s'il vous plaît. Ce n'est pas évident pour moi, sinon je ne demanderais plus. Mais l'auteur est évident et il pense que tout le monde aussi.

Si nous parlons de l'expérience des débutants, alors l'un de mes étudiants a formulé le mieux cette idée:

"Je n'ai pas du tout compris pourquoi justifier les bugs, jusqu'à ce que je lise les bugs des autres étudiants"

Vous pouvez dire depuis très longtemps que c'est "évident" pour tout le monde qui est différent et je ne suis pas dans votre contexte, et bien plus encore ... Mais l'auteur de la tâche considérera qu'ils lui reprochent tout simplement, les autres ne comprennent pas, mais il va bien!

Et juste en lisant les bugs des autres, vous commencez à penser: «Hmmm, pourquoi pense-t-il ainsi? J'ai pensé différemment. " C'est alors que la compréhension vient que votre «évident» n'est pas évident pour tout le monde.

Une fois que je suis entré dans le traqueur de bogues et que j'ai vu un tel bogue d'un étudiant: «Nous entrons le nom Sharipat, il est défini comme masculin. Et ça devrait être comme une femme! Pourquoi devrait-il être comme une femme? Je regarde ce nom - eh bien, Sharipat et Sharipat, ressemble à un homme. Je demande:

"Pourquoi avez-vous décidé cela?" Pourquoi femme?
- Oui, parce que ma femme s'appelle ainsi!

Et cela m'explique déjà au moins pourquoi il a commencé la tâche. Lorsque nous testons des applications, nous essayons d'abord des données simples, des choses que nous savons. Nous essayons notre nom, le nom de notre femme, frère, sœur ...

Il a essayé d'entrer le nom de sa femme et a découvert un bug. Et s'il écrivait même dans le résultat attendu: «Le sexe est féminin, c'est un prénom féminin - mon nom est ça», alors au moins la question «Pourquoi avez-vous commencé cette tâche?» Disparaîtrait.

Bien entendu, une telle justification ne suffit pas. Google «noms inhabituels», car il ne nous est même pas interdit de nommer la table de chevet de notre fils, mais vaut-il la peine de considérer ce mot comme le nom masculin correct?

Donc, ici, il faut google, quels sont les noms en général, pour localiser le problème - le problème avec les noms russes? Kazakh? Ukrainien? Mais le système devrait-il pouvoir les traiter? Et ainsi de suite. Peut-être pas du tout un bug ...
Et pourtant, «le nom de ma femme est ainsi» permet au moins à l'auteur de nous introduire dans son contexte et explique pourquoi il a décidé de commencer la tâche.

Et rappelez-vous, les preuves peuvent être dictées par le contexte. Vous avez soigneusement étudié le grand module du système, vous savez tout à fond. Par conséquent, il est tout à fait évident pour vous que "cette puce devrait fonctionner ICI". Mais si vous revenez à la tâche dans un mois ou deux, vous travaillerez déjà sur un autre module, et se rappeler pourquoi il en sera ainsi sera plus difficile.

Même le crayon le plus stupide est plus net que la mémoire Internet la plus nette

Lorsque vous démarrez un bug et que le résultat attendu vous semble évident, arrêtez-vous et pensez: «Pourquoi est-ce que je pense que oui?». Et notez la réponse à cette question.

1.2. Je le jure par maman!

Quand un élève se rend compte que n'écrire rien du tout, "parce que c'est évident", n'échoue pas, il passe à l'étape suivante de la colère, du déni et de la justification des bogues, qui s'appelle "Je jure par maman!" C'est à ce moment-là que nous disons simplement que c'est si juste, sans expliquer pourquoi.

Autrement dit, la justification ressemble à ceci:

Résultat
57,6

Résultat attendu
57,9 parce que c'est si juste

Mais une telle justification ne répond pas encore à ma question «Mais pourquoi?». Pourquoi avez-vous décidé que c'était si juste? Je ne suis toujours pas un wang ou un télépathe, et je ne sais pas pourquoi vous pensez que c'est vrai.

En fait, ce n'est pas très différent de la situation "n'a rien écrit du tout, car c'est évident". Par conséquent, j'appelle cela la deuxième étape - c'est précisément dans ce scénario que les événements se développent habituellement, d'abord «évidemment», puis «oui, donc exactement à droite». Regardons un exemple tiré de la vie des étudiants:

Pierre et les Indiens

Notre système peut infléchir les noms par cas. Un élève vérifie le nom de Peter. Savez-vous comment ça penche? Dans le cas nominatif, il est écrit par la lettre E, et dans tous les autres - par E. "Peter, mais Peter."

Et donc je vais dans le traqueur de bogues et je lis un tel bogue: "Peter se penche sur les cas à travers la lettre e, mais devrait à travers e."

Je demande:

"Pourquoi le pensez-vous?"
- Eh bien, il est évident que par E il est nécessaire (première étape)
"Pourquoi pensez-vous que c'est évident?"
- Mais c'est ainsi selon les règles de la langue russe!
- Par quelles règles?
- Eh bien, dois-je exécuter et google les règles de la langue russe? (deuxième étape - si bien, croyez-moi)
- OUI! Oui, c'est exactement ce que vous devez faire. Parce que ce sera la raison du bug. Parce que votre développeur est peut-être indien et vous êtes aussi indien. Et vous ne connaissez pas les règles de la langue russe! Donnez-leur donc un lien et toutes les questions disparaîtront immédiatement.

Bien sûr, il n'est pas nécessaire d'aller à l'extrême et de donner des liens vers des dictionnaires lorsque vous mettez un bug sur une faute de frappe ou une virgule manquée. Néanmoins, Peter est un exemple non trivial, c'est une exception à la règle. Cela fonctionne toujours comme ça, mais pour Peter, c'est différent.

Par conséquent, ici le lien sera utile. Surtout si le développeur demandait: "Est-ce vraiment vrai?" Vous pouvez l'accuser de stupidité et d'analphabétisme et ruiner la relation. Et vous pouvez donner un lien, confirmant doucement votre point de vue.

Mais ok, prenons un autre exemple, pas sur les règles de la langue russe, qui sont "si évidentes".

Email.rf

Mes élèves aiment beaucoup cette tâche (presque tous les flux la rédigent):

- J'essaie de m'inscrire avec email.ru et je ne peux pas. Ceci est un bug!
- Pourquoi?
- Comment ça, pourquoi? Nous vivons en Russie, tout le monde a de tels e-mails!

J'ai raconté ce cas à la conférence DUMP, et j'avais une salle d'audience complète. J'ai demandé à lever la main de ceux qui ont un tel e-mail. Sur 200 personnes, trois personnes ont levé la main.

Le fait que nous vivions en Russie ne signifie pas que tout le monde a de tels e-mails. Eh bien, oui, oui ... Et des ours apprivoisés et des poupées gigognes ...

Il n'y a pas de relation causale ici, il est tout simplement difficile de renoncer à votre idée. Après tout, ici, j'ai trouvé un bug! Comment cela ne peut-il pas être un bug ?? Tellement cool. La Russie, évidemment! Non, pas évident? Eh bien, tout de même, la Russie, il y en a sûrement beaucoup.

Cette logique ressemble plus à «Je suis trop paresseux pour aller sur Google, recherchez des faits. Croyez le mot. " Lorsque nous n'avons pas de faits et de preuves, il y a un désir de voiler sa justification et d'écrire "Probablement, probablement, à coup sûr ...".

Mais ce sont des mots STOP! Si vous avez envie de les écrire, vous n'avez pas de faits réels. Alors réfléchissez bien. Et pourquoi devons-nous faire une tâche basée sur l'imagination d'un testeur? Prouvez votre théorie!

Et s'il n'y a pas de faits? Ensuite, la tâche ne vaut même pas la peine d'être commencée. Oui, il est difficile de refuser le bug "votre propre langue". Mais cela aussi doit pouvoir.

Email.ru - faits

Quels pourraient être les faits?

Premièrement, nous pouvons créer notre site pour certains clients gouvernementaux qui doivent s'inscrire dans le domaine.rf. Norme d'entreprise, ils n'ont pas le choix.

Ou nous avons vraiment beaucoup de ces clients, comme le montrent les statistiques. Par exemple, il y a beaucoup d'erreurs dans les journaux «tentative d'enregistrement via un tel domaine». Et peut-être que cela vaut la peine de créer cette fonctionnalité. Afin de ne pas perdre de clients potentiels.

Sur la base de ces faits, PM (Project Manager) décide si nous ferons la tâche ou non. Et si nous le voulons, alors quand. Ou il peut dire: "Eh bien, il y a des erreurs, et bien, il y a moins de 1% du total des inscriptions, nous ne les ferons pas"

Au lieu de l'abstrait "oui, de telles personnes existent vraiment!" Donnez les FAITS.

Et lorsque vous définissez la tâche, utilisez le principe 5 pourquoi. Lorsque vous notez le résultat attendu, demandez-vous: «Pourquoi est-ce que je m'attends à cela?» La première réponse sera «C'est évident», mais posez à nouveau la question «Pourquoi?». Et si vous remarquez qu'il n'y a pas de données, il vous semble juste que oui - recherchez les faits ou discutez de la situation avec des collègues.

1.3. Les lapins sont offensés

S'il n'y a pas de faits, mais que vous ne voulez pas refuser le bug, les élèves passent à l'étape suivante de la colère, du déni et de la justification des bugs ... Pression sur les émotions:

J'essaie de m'inscrire avec le nom Cthulhu, mais pas le système. Devrait donner, sinon ... J'ai été offensé et je suis parti, et VOUS! Perdu un client!

Et sûrement tout le monde est le même que moi, donc vous avez perdu TOUS les clients, et ils ont également déposé une plainte pour insulte et ont pris tout l'argent!

Et d'autres voitures ...

Bien sûr, quand personnellement je n'aime pas quelque chose, c'est très en colère d'ignorer mon problème. Qu'est-ce que cela signifie "Les gens normaux ne s'inscrivent pas avec ce nom?" Suis-je fou?! Comme je veux, ça s’appelle, comment pouvez-vous m’interdire quelque chose?!

Et puis la projection s'allume - si je ne l'aime pas, alors les autres utilisateurs ne l'aimeront pas! Si ce n'est pas tout, alors au moins beaucoup. Par conséquent, c'est définitivement un bug et doit être corrigé. Eh bien, ou du moins partons dans le cadre de la formation, si nous parlons d'étudiants.

Cependant, l'utilisateur offensé est la pire justification qui puisse jamais être. Parce qu'ils peuvent justifier n'importe quel non-sens:

N'y a-t-il pas de chat sur le principal? Eh bien, c'est tout! J'ai été offensé et parti! Et VOUS! Perdu un client !!
Je me suis inscrit et je n'ai pas été payé pour ça ?? J'ai été offensé et je suis parti ... ET VOUS! Eh bien, vous comprenez!

Tout peut arriver et m'offenser. Le bouton est vert, mais je voulais un rouge, le système ne m'a pas offert de pizza en cadeau ... En tant qu'utilisateur, je peux m'offusquer de tout. Mais qui s'en soucie? Tout de même, cela ne vous plaira pas, le ressentiment est inévitable. Et menacer est généralement la dernière chose.

Tout a commencé avec l'un des étudiants, qui vient de dire cette phrase secrète:
- Ah, vous ne voulez pas vous inscrire via le domaine de la Fédération de Russie? Et en tant qu'utilisateur, j'ai essayé de m'inscrire, j'ai vu cette situation flagrante, et GONE! Et VOUS! Perdu un client!

Ensuite, mon ami a dit que de tels discours ressemblaient beaucoup à "Des lapins ont été offensés". Je ne sais pas d'où elle tire cette analogie, mais tout le monde a aimé.

L'élève s'est rendu compte qu'il s'énervait. Je suis allé chercher une justification sans émotion. Et nous avons obtenu le nom d'antipattern.

Rappelez-vous une règle simple - il ne devrait pas y avoir d'émotions dans le bug!

Les émotions sont un phénomène passager. C'est maintenant que vous flambez de colère juste et que vous voulez l'exprimer dans des commentaires malveillants comme "seul un idiot pourrait écrire du code comme ça". Mais souvenez-vous de toute situation où un enfant à côté de vous était capricieux, organisant une crise de colère pour maman à cause d'un jouet non acheté ou d'une crème glacée. En tant qu'observateur extérieur, aimez-vous regarder cette scène? Mais votre hystérie dans le traqueur de bogues est exactement la même!

Par conséquent, si vous le voulez vraiment, dites tout verbalement. Discutez avec le développeur de la tâche dans le fumoir, en défendant avec véhémence votre position. Mais dès que nous sommes arrivés à l'ordinateur - nous supprimons les émotions, nous écrivons uniquement les faits. Sans «si oui si» et sans «et VOUS! Perdu le client! ”

N'oubliez pas qu'ils reprennent leurs tâches après un an ou deux ou trois. Et puis, même vous regarderez avec délicatesse votre propre colère. Après tout, il n'y a plus d'émotions passées, cela semble ridicule. Donc, le maximum d'émotions verbalement - dans le fumoir! Et dans un bug en quelque sorte sans eux.

Et dans la justification, n'écrivez pas sur les lapins méga-offensés. Parfois, une telle défense de la tâche revient au ridicule:

L'élève a trouvé une faute de frappe dans l'offre de l'utilisateur. Mettez un bug avec une priorité critique. Lorsqu'on lui a demandé de clarifier la priorité, il s'est indigné:

- Le système m'a trompé, je ne peux pas lui faire confiance !!!

Il était probablement inquiet que la question devienne «ce n'est pas du tout un bug», alors il a commencé à défendre son bug. Mais cela ne dérange pas que ce soit un bug. Mais pourquoi est-ce critique? Qui lit l'offre?

- J'ai lu! Par conséquent, je vois que le système est mauvais, s'il y a une faute de frappe, que peut-il faire? Et comment y croire maintenant?!

Mais "je lis" ≠ "tout le monde lit". Et puis l'étudiant lui-même a admis qu'il ne lisait pas attentivement CHAQUE accord de licence qui nous est glissé lors de l'installation des programmes. Donc avec l'offre la même histoire. Alors que tout va bien, ils ne le lisent pas. Si quelque chose n'est pas agréable, adressez-vous déjà aux règles.

Cependant, "le système m'a trompé et je ne peux pas le croire maintenant" à cause d'une faute de frappe sur la dixième page du texte que peu de gens lisent ... Eh bien ... N'écrivez pas ceci dans un bug, ne le dites pas à votre RM.

Donc, nous supprimons les émotions du bug. Et que pouvons-nous y laisser? Bien sûr, les faits!

Au lieu d'écrire sur les émotions, «les lapins seront sûrement offensés, ils partiront et vous perdrez des clients»:

- collecter des statistiques;
- estimer les coûts de main-d'œuvre;
- compter le ROI;
- Interviewer les utilisateurs;
- Comparer le produit avec ses concurrents;

Et au lieu d'un écureuil hystérique, vous deviendrez un testeur cool qui fait des bugs réfléchis!

2. Bons modèles de justification

Comment justifier correctement les bugs? Que faut-il écrire dans le résultat attendu pour que votre bug soit corrigé comme vous l'avez écrit? Et ils n’ont pas demandé 10 fois «pourquoi est-ce si juste»?

Trois antipatterns ont été discutés ci-dessus, discutons de trois bons modèles pour justifier les bugs.

2.1. Pruflink

Ce pourrait être:

Lien avec les exigences
Les exigences elles-mêmes (fichier Word, présent ...)
Lien Internet
ROI estimé
Lettre client
Statistiques

Lien avec les exigences

Le bogue le plus simple est lorsqu'il existe un savoir traditionnel et que le système ne fonctionne pas comme décrit ici.

Nous écrivons donc le résultat attendu: "57,9, car il en est ainsi dans l'énoncé des travaux." Hmm, hmm ... Attendez une minute. Cela ressemble à "je jure devant maman" ...

Oui, dans cette formulation, cela ressemble à ça. Par conséquent, confirmez vos mots avec un lien. Sinon, le développeur lit le bogue et il a besoin de:

comprendre quel type de savoirs traditionnels est impliqué;
trouver les savoirs traditionnels eux-mêmes;
trouver l'endroit précis en question;
pour saisir ...

N'est-il pas plus facile de ne laisser que le dernier élément? Après tout, le développeur peut travailler sur 10 projets différents, dont la documentation est distribuée dans 10 endroits différents. Il lui faudra 5 à 10 minutes pour rechercher des savoirs traditionnels et l'ajout d'un lien pour vous ne prendra qu'une seconde. Après tout, vous testez maintenant les savoirs traditionnels, ce qui signifie qu'il est ouvert et devant vos yeux. Copiez le lien et collez!

Respectez le temps des collègues et ils vous seront reconnaissants.

Exigences elles-mêmes

Si les exigences ne sont PAS stockées dans une confluence ou un autre système cloud, mais dans un Word standard, joignez le document que vous testez.

Il est possible que vous testiez des exigences obsolètes. Et si vous joignez un fichier Word direct que vous vérifiez, l'analyste peut le voir et dire: «Oh, attendez, nous avons déjà tout changé 10 fois, j'ai oublié de le télécharger. Attends! "

Si vous ne le faites pas, passez trois heures en confrontation avec le développeur, qui dira "mais j'en ai un autre!". Vous courrez, surveillez ses besoins, puis les vôtres, puis cherchez un analyste pour clarifier qui a raison ...

Et donc vous avez immédiatement mis les exigences, le développeur a dit "quelque chose est une sorte de poubelle", a redirigé l'analyse. L'analyste les a écrits, et quand il ouvre votre mot, il comprendra immédiatement s'il est dépassé ou non. C'est gagner du temps!

Lien Internet

Comme nous nous en souvenons, les exigences sont loin d'être toujours. Et au lieu d'eux peut-être ... Lien vers Internet! Oui, pourquoi pas?

Si nous rappelons notre exemple «Peter, Peter», alors même si nous avons des exigences dans le système, il est peu probable qu'il indique «Le système fonctionne selon les règles de la langue russe» et toutes les règles de la langue russe sont répertoriées. Bien sûr, personne n'écrit comme ça. Et il s'avère que si vous voulez vous référer aux règles de la langue russe, vous devez aller les chercher sur Google.

Ou si vous prenez un exemple de Sharipat. Encore une fois, où avez-vous trouvé que c'est un prénom féminin normal? Nous recherchons sur Google toutes sortes de noms kazakhs et autres, trouvons Sharipat, trouvons d'autres noms similaires et donnons un lien vers cette page.

Et ici déjà, même si le développeur n'est pas d'accord avec vous, il peut venir dire: «Écoutez, vous avez donné un lien vers le site, mais c'est une sorte de presse jaune, ils écrivent toujours des ordures.» Mais si vous n'avez pas donné le lien, le développeur devra se rechercher sur Google, rechercher lui-même toutes sortes de sites et alors seulement il comprendra que vous avez peut-être attaqué de fausses informations.Gagnez-lui du temps, donnez immédiatement un lien vers Internet.

Oui, ici, vous devez comprendre que tous les liens ne sont pas utiles et justifiés, mais cela montrera au moins pourquoi vous pensez que c'est vraiment un bug. Ce n'est pas ma "maman qui te jure", mais avec une justification!

Lettre du client La

justification peut être envoyée à une lettre du client. Nous avons même un champ distinct, Business Justification, où nous notons quel client a demandé cette fonctionnalité. Et puis, lorsque nous lisons notre bug, nous voyons immédiatement:

- Oui, l'analyse de rentabilisation est vide. Cela signifie que nous avons nous-mêmes trouvé ce problème et pensons qu'il doit être résolu.

Ou:

- Oui, un tel client s'est plaint du problème le 1er août 2015

Et si nous devons clarifier avec ce client ce qui ne lui convient pas exactement, nous pouvons facilement trouver cette lettre, car nous avons toutes les informations (qui, quand, comment la lettre est appelée). Connaissant ces informations, je vais aller chercher une lettre dans 5 secondes dans mon Outlook. Si ces informations ne sont pas là, je devrai aller dans Outlook et rechercher parmi 10 papas différents - quel client l'a demandé et dans quelle lettre?

De plus, si nous constatons que cette fonctionnalité a été demandée par plusieurs clients différents, elle augmente immédiatement la priorité. Puisque nous comprenons:

- Oui, voici le client 1 qui s'est plaint, puis, après quelques semaines / mois, le client s'est plaint d'un autre. Hmmmm, mais il y a sûrement un tas d'autres clients qui souffrent également, mais sont silencieux. Pleure, pique, mais continue de manger le cactus. Après tout, tout le monde ne va pas nous écrire et nous signaler un problème ...

Donc, plus il y a de plaintes, plus la priorité est élevée. Puisque nous comprenons qu'il s'agit d'un véritable utilisateur se plaignant, ils ont vraiment de tels problèmes. Et même si nous revenons au bug six mois ou un an plus tard, grâce à la lettre jointe ou au moins un lien vers celle-ci, il sera toujours possible de remonter l'historique de la tâche.

ROI

Nous pouvons essayer de calculer le ROI - ratio de retour sur investissement. Avons-nous vraiment besoin de créer cette fonctionnalité ou de corriger ce bogue? Cela apportera-t-il l'effet approprié?

C'est une chose de faire une modification mineure pendant une demi-heure de développement, ce qui aidera des centaines d'utilisateurs. C'est complètement différent - en raison de l'hystérie d'un utilisateur, deux semaines pour refaire le travail du système, qui convient à tout le monde.

Si nous calculons le ROI et voyons que le jeu en vaut la chandelle, nous mettons les calculs dans la tâche. Mais parfois, après les calculs, il s'avère que vous n'avez pas besoin de faire la tâche. Et c'est normal! Nous avons donc économisé du temps à l'équipe pour discuter des fonctionnalités inutiles.

C'est pourquoi nous réfléchissons à la justification - parce que parfois il semble "Ah, quel bug, quel bug!", Et puis vous commencez à réfléchir à la justification ... Et vous comprenez que cette poubelle, pas un bug, ne vaut pas la peine d'être démarrée ...

Par exemple, nous arrivons à travailler avec une application mobile, et il existe un panneau de débogage pour les testeurs qui ressemble à ceci:

Wow, wow! Il y a un peu de bleu, il y a un peu de rouge, le texte n'est pas complètement visible, les polices sont dispersées ... Un bug évident! Comment cela n'a-t-il pas été remarqué avant moi? Autorisation urgente, besoin de refactoring!

Comment justifier? "Que voulez-vous dire, si un utilisateur VOIT CECI, alors il sera immédiatement offensé et partira." Arrêter . -. , [2]. . , , !

… , ? . , , . ? !

, . . . ? ? , , .

— , !

Statistiques

Recueillir des statistiques et investir dans la tâche:

- le nombre d'erreurs dans les journaux;
- le nombre de réclamations dans le support technique;
- le nombre de clics sur le bouton;
- le nombre d'utilisateurs qui sont partis au stade de la commande (fermé l'onglet);
- ...

Autrement dit, si vous pensez que le formulaire standard pour passer une commande dans la boutique en ligne est «mauvais» et doit être amélioré, justifiez-le. Pourquoi est-ce mauvais? Alors que pour entrer l'adresse dont vous avez besoin de connaître votre index et remplir les 10 champs obligatoires? Est-ce vraiment mauvais ou seulement vous ennuie?

Gardez à l'esprit que les développeurs peuvent ne pas voir «l'évidence» dans leur logiciel. Après tout, ils l'ont développé, testé ... Ils le voient constamment 100 fois par jour, ils sont déjà habitués à l'interface. Donc, même si elle est vraiment dépassée, vous avez besoin de faits.

Et les faits sont faciles à collecter - nous vous demandons de faire des statistiques pour voir quand l'utilisateur quitte la page. Et s'il a ajouté de la pizza au panier, puis a commencé à remplir les champs et après 5-7 craché et est parti, ce n'est pas très cool. Et si chaque tiers agit comme ça - ça vaut vraiment la peine d’améliorer quelque chose!

Si vous vous souvenez de l'email.ru, vous pouvez consulter les journaux - y a-t-il des erreurs comme «La tentative d'enregistrement pour un tel email est rejetée»? Peut-être qu'ils n'existent pas du tout, mais nous avons déjà trouvé un tas d'utilisateurs offensés, à cause de quoi le site a littéralement perdu des millions.

Pourquoi les statistiques sont-elles meilleures que les émotions? Parce que nous, les professionnels de l'informatique et les utilisateurs ordinaires sommes deux mondes différents. Ce qui nous convient n'est pas pratique pour eux. Et vice versa.

Supposons que nous faisons un logiciel de comptabilité. Il nous semble: "Fu, personne ne travaille avec la souris, il faut s'assurer que tout fonctionne depuis la ligne de commande, pour que la souris n'ait pas besoin d'être touchée!" Nous passons beaucoup de temps sur cette fonctionnalité, mais les vrais utilisateurs ne l'utilisent pas du tout. Parce qu'ils ont besoin d'une souris pour cueillir, piquer sur le gros bouton ... Mais ce qui est pratique pour les programmeurs, ils s'en moquent généralement, car ils sont à l'aise avec quelque chose de complètement différent.

Et si vous voulez dire à tout le monde ce dont les utilisateurs ont besoin, étudiez d'abord les tests d'utilisabilité, puis dites si les lapins sont offensés ou non.

Dans notre système, nous collectons des statistiques anonymes, quelles fonctionnalités sont utilisées et lesquelles ne le sont pas. Il y a tellement de filtres sur un formulaire Web qui sont difficiles à maintenir. Sont-ils nécessaires? Vous ne pouvez pas simplement retirer et retirer, cela vaut la peine de vérifier.

Les statistiques sont donc généralement très surprenantes. Nous pensions que ce filtre n'était pas utilisé du tout, mais en fait, il fonctionnait toutes les heures. Et de l'autre, ils avaient de grands espoirs, mais personne n'a besoin de lui ...

Seules les statistiques indiquent honnêtement l'existence du problème. S'il n'y a pas de statistiques, ce sera juste du goût. Et tout le monde a des goûts différents. Le testeur veut le bouton rouge, le développeur le vert et le concepteur le bleu. Alors cherchez des faits et donnez-leur un lien pruflink!

2.2. Uniformité

S'il n'y a pas de pruflink, on peut se référer à l'uniformité du système. Parce que si le système fonctionne toujours de cette façon, puis qu'il fonctionne soudainement différemment - cela pourrait bien être la raison du bug.

Par exemple, si notre système fonctionne comme un puntoswitcher (c'est lorsque j'imprime en russe, en oubliant de changer la mise en page et que le système change moi-même). Je peux taper "Olga", ou je peux taper "Jkmuf", le système transformera la deuxième option en première.

Cela se produit sur toutes sortes d'applications gouvernementales. Parfois, ils travaillent eux-mêmes sur le même principe. Vous devez vous inscrire clairement comme dans votre passeport. Comme nous vivons en Russie, l'enregistrement est en russe, nous corrigerons donc les lettres anglaises. Vous avez évidemment oublié de changer la disposition, mec!

Jkmuf → Olga

D'accord, mais si j'essaye de taper le nom "Julia"? Il commence par la lettre U, et cette lettre ne correspond pas à la lettre de l'alphabet russe, mais à un caractère spécial:

> → Yu

Et ceci est une classe d'équivalence complètement différente!

Autrement dit, si nous comprenons que le système fonctionne comme un puntoswitcher, nous avons au moins 2 classes d'équivalence: il y a des lettres russes qui correspondent aux lettres latines, et il y a celles qui correspondent à un caractère spécial.

Ce sont des classes complètement différentes, elles doivent être vérifiées! Et peut-être que lorsque nous imprimons un caractère spécial, le système ne le reconnaît pas. Et puis nous commençons un bug - je tape le symbole>, je m'attends à ce que le système le traduise dans la lettre U, mais rien ne se passe. Pourquoi je m'attends à ça? Parce que le système DÉJÀ fonctionne comme ça, parce que si j'entre dans Jkmuf, le système comprendra que c'est Olga.

Nous montrons que le système fonctionne déjà de cette façon, et c'est une bonne justification. Nous ne disons pas "Je jure par ma mère, elle travaille comme ça", nous le prouvons sur Olga.

2.3. Problème ou # douleur de la vie

Parlez-nous d'un vrai problème d'utilisateur.

Parce que nous sommes des testeurs. Notre tâche est d'écraser et de casser, d'entrer «Guerre et paix» dans un court champ, d'éditer une entrée dans deux onglets de navigateur et une autre, l'autre. Et même si quelque chose ne fonctionne pas pour nous, cela ne signifie pas que l'utilisateur fera de même.

Et parfois, les bugs ne sont pas corrigés simplement parce que "oui, personne ne fait ça!" Et c'est normal. Pourquoi gaspiller de l'énergie et des ressources sur un problème qui ne se pose jamais?

Cela est particulièrement vrai pour les problèmes d'utilisation. Comme nous nous en souvenons, ce qui est pratique pour un informaticien est gênant pour un simple utilisateur. Et vice versa! Et il s'avère que si nous écrivons simplement "Eh bien, c'est inconfortable ..." - c'est une mauvaise justification, on ne sait jamais ce qui est inconfortable, tout convient au reste. Mais si nous collectons les commentaires des utilisateurs, attachons leurs lettres dans lesquelles ils se plaignent de nous, cela suggère immédiatement qu'un tel problème existe vraiment. Et cela augmente déjà sa priorité.

Le problème d'un vrai client est toujours meilleur qu'un simple test négatif d'un testeur.

Cela ne signifie pas que les testeurs ne sont jamais corrigés pour les problèmes. Si vous avez un problème, plaignez-vous aussi! Peut-être que le développeur peut vous aider en seulement 5 minutes, il ne connaît tout simplement pas la situation.

Lorsque je teste une nouvelle fonctionnalité, je la couvre d'autotests. Le framework de test existe depuis longtemps, nous y sommes habitués. Les tests sont similaires les uns aux autres, donc copiez-collez - après tout, nous modifions généralement un paramètre, laissant le reste inchangé. C'est le principe «1 test = 1 test», de sorte qu'une baisse du test indique immédiatement la cause.

Et maintenant, je dois copier les paramètres de l'autotest à l'autotest. Et je dois les déterrer du premier test au deuxième, troisième, quatrième, cinquième, dixième ... Et dans ce copier-coller, je n'ai besoin que de changer 1 valeur sur une ligne, et si je ne le fais pas, tout s'effondrera avec un terrible une erreur.

Bien sûr, quand je fais du copier-coller, je me trompe au moins quelque part ... En conséquence, j'ai écrit 30 tests, les ai exécutés en même temps, et tout est tombé avec NPE. Je m'assois, je me gratte la tête et je pense "bon sang, où je me trompe?"

J'ai fait du tri toute la journée, je cherchais une erreur, je faisais des auto-tests ... J'essaie de trouver un bug ou un endroit où j'ai foiré. Du coup, je trouve et puis au prochain rallye je me plains:

"J'ai écrit ces tests automatiques toute la journée hier, car j'ai fait une erreur lors du cinquième test et j'ai ensuite essayé de comprendre pendant longtemps quelle était la raison de la chute." Oh, ce copier-coller!

Et puis le développeur dit:
"Oui, elle viendrait vers moi; je refaçonnerais tout pour vous en une demi-heure et réglerais ce problème."

Et c'était donc possible? !!!

S'il vous plaît, n'ayez pas peur! Peut-être que vous souffrez, et le développeur ne le sait même pas. Et peut-être qu'il peut résoudre rapidement votre problème, ici et maintenant. Et peut-être pas le réparer, mais suggérer une solution de contournement.

Bien sûr, si le problème est un problème ponctuel, ou s'il prend trop de temps pour le résoudre, la tâche d'optimisation passera à la prochaine version ou plus. Mais cela vaut au moins de discuter «comment cela peut-il être amélioré» et de fixer une tâche. Après tout, s'il n'y a pas de tâche, personne ne fera rien.

Il existe différents cas de problèmes:

- problème client;
- le problème de l'utilisateur réel;
- problème du testeur;
- un problème au sein de l'équipe;

Certains sont plus prioritaires, d'autres moins. Et pourtant, si nous décrivons le cas réel et le vrai problème, alors une telle tâche a plus de chances de correction que "évidemment, donc tout le monde ira mieux".

Oui, vous devez comprendre que même si nous décrivons à quel point il est mauvais pour les vrais utilisateurs, cela ne garantit toujours pas que nous corrigerons le bogue, mais c'est la vie. En tout cas, si nous avons au moins décrit le problème, il sera au moins clair pourquoi nous avons défini cette tâche. Même si nous revenons à lui dans un mois, deux ou trois. Nous verrons toujours pourquoi nous avons pensé que les utilisateurs étaient mauvais et mal à l'aise de travailler avec.

3. Lorsque la justification n'est pas nécessaire

Soudain, non? =)

Néanmoins, l'anti-modèle a «évidemment» des exceptions. Nous n'avons vraiment PAS besoin d'écrire une justification si le système:

raccroché;
est tombé avec une erreur non gérée;

Surtout si cela s'est produit en production. Si notre site est, il n'y a aucune raison de le justifier, vous devez battre le gong et courir vers le développeur "le réparer de toute urgence!" C'est possible sans bug du tout. Et vous pouvez avec une brève "Erreur 500 sur le principal", cela suffit.

Ne pas aspirer la raison du doigt, car "c'est toujours nécessaire". Écrire «le système ne doit pas tomber» est du texte pour le plaisir.

Mais! Vous devez absolument écrire le résultat attendu. Même si cela vous semble évident, notez-le, cela ne vous effacera pas.

Étapes
Ouvrir le site example.com

Résultat
Erreur 500

Résultat attendu
La page principale s'est ouverte

Tout semble être simple ici - le principal ne s'ouvre pas, mais il devrait. Mais il existe des exemples plus compliqués.

Par exemple, le développeur a créé une formule à partir des savoirs traditionnels et, quelque part, une division par zéro se produit. Si vous écrivez simplement «Il ne devrait pas y avoir d’erreurs, le rapport est chargé», le développeur vous posera toujours la question «Comment devrait-il s’ouvrir alors? Il y a une division par zéro! »

Vous devez y réfléchir et écrire «Je m'attends à ce qu'un rapport s'ouvre avec telle ou telle valeur selon la formule » - pendant que vous pensez à ce qui devrait être là, vous pouvez vous-même trouver le joint dans le mandat. Et puis vérifiez avec l'analyste comment correctement.

Donc même s'il n'y a pas de justification, il y a au moins le résultat attendu. Et rappelez-vous qu'il s'agit d'une exception à la règle. Le système ne doit pas tomber et geler. Cependant, ces bogues sont rares, et dans d'autres cas, il devrait y avoir une justification.

4. Résumé

Nous avons discuté de 3 antipatterns. Trois étapes de colère, de déni et de justification des bugs:

Évidemment - il est évident pour nous que nous ne le justifions pas. Et puis nous obtenons "oh, j'ai oublié pourquoi je voulais" ... C'est évident seulement pour vous, seulement ici et seulement maintenant. Après six mois, vous oublierez vous-même pourquoi. Expliquez à quel point ces preuves sont stupides.
Je jure par ma mère, c'est vrai! - Pourquoi jurer? Pour une raison quelconque, vous pensez que c'est si juste, alors dites-moi pourquoi. Donnez un lien vers les exigences, par exemple.
Les lapins ont été offensés - "Oh, vous n'avez pas ajouté de chat à la page principale? Eh bien, c'est tout! J'ai été offensé ... ET ALLÉ! Et toi! Perdu le client !! ” Mais ce qui vous dérange peut être pratique pour les autres. Supprimez donc les émotions et donnez des faits.

Au lieu de cela, ils devraient utiliser la justification correcte:

Pruflink - TK, Internet, lettre client dans laquelle il a demandé cette fonctionnalité ...
Uniformité - Si le système fonctionne toujours de cette façon, et à un endroit différent, cela vaut la peine de le réparer!
Problème - décrivez le problème qui se pose pour vous ou l'utilisateur (si vous communiquez avec les clients). Le vrai problème est toujours meilleur qu'un simple test négatif.

Assurez-vous d'écrire pourquoi nous avons décidé qu'il s'agit vraiment d'un bug et pourquoi nous voulons qu'il soit corrigé exactement comme nous l'avons écrit ici. Nous nous posons des questions de la série «5 pourquoi»

- pourquoi est-ce que je pense que c'est évident?
- pourquoi je pense que c'est si juste?
- pourquoi je pense que les utilisateurs sont contrariés?

Nous fournissons des liens vers des exigences sur Internet, indiquons l'uniformité ou parlons du vrai problème de l'utilisateur.

Et quand après un an vous relirez des tâches exécutées avec compétence, vous me direz toujours «Merci!» ツ

Modèles de justification des tâches et antipatterns