Pourquoi laisser / ne pas laisser les développeurs tester leur propre travail

81

Je souhaite rassembler quelques arguments sur les raisons pour lesquelles laisser un développeur tester son propre travail comme dernière étape avant la mise en production du produit est une mauvaise idée, car malheureusement, mon lieu de travail le fait parfois (la dernière fois que cela a été évoqué). , la plupart des gens étaient trop occupés par d’autres tâches et n’avaient pas le temps de familiariser une autre personne avec cette partie du programme - c’est un logiciel très spécialisé).

Il existe des plans de test dans ce cas (bien que pas toujours), mais je suis très favorable à l'idée de faire en sorte que les personnes qui n'ont pas apporté les modifications testées effectuent réellement les tests finaux. Je vous demande donc si vous pouvez me fournir une liste solide et solide d’arguments que je pourrai évoquer lors de la prochaine discussion. Ou pour fournir des contre-arguments, au cas où vous pensez que cela convient parfaitement, en particulier lorsqu'il y a des tests élémentaires à tester.

pyvi
la source
6
Votre question semble indiquer que les développeurs ne devraient faire aucun test. Je m'assurerais que les développeurs testent réellement le logiciel pour s'assurer qu'il fonctionne (pas seulement compile) afin de ne pas perdre de temps en testeurs.
dnolan
4
@dnolan: Je parle des tests finaux ici, les tests avant la production du code. Bien entendu, le développeur doit tester pendant le développement.
Pyvi
Parce que c'est comme ça que ça se passe: devopsreactions.tumblr.com/post/88260308392/testing-my-own-code
Michal M le

Réponses:

103

Comme d'autres (et vous-même) l'avez noté, les développeurs devraient tester leur propre code. Cependant, après cela, tout produit non trivial doit également être testé par une ou plusieurs personnes indépendantes (service d’assurance qualité et / ou le client elle-même).

Les développeurs travaillent normalement avec la mentalité de développeur "comment faire pour que cela fonctionne?" . Un bon testeur pense à "comment casser ça?" - un état d'esprit très différent. Les tests unitaires et TDD enseignent aux développeurs de changer de chapeau dans une certaine mesure, mais vous ne devriez pas vous en fier. En outre, comme d’autres l’ont noté, il existe toujours un risque de malentendu quant aux exigences. Par conséquent, les tests d'acceptation finaux doivent être effectués par une personne aussi proche que possible du client .

Péter Török
la source
3
Je suis d'accord. Après des heures, des jours, voire des semaines, d’essayer de «faire fonctionner ce travail» dans un délai imparti, il peut être TRÈS difficile (voire même impossible) de briser cet état d’esprit. Il serait peut-être possible de tester de manière objective si vous aviez le temps de mettre votre travail de côté et de revenir après une pause, mais cela est rarement faisable.
PeterAllenWebb
Testeurs de chapeau noir ...?
Mateen Ulhaq
7
+1 pour "Les développeurs travaillent normalement avec la mentalité de développeur" Comment faire pour que cela fonctionne? ". Un bon testeur pense à" Comment
résoudre ce problème
Une note supplémentaire ici; Bien que les tests soient importants, les révisions de code aident beaucoup à détecter les bogues et garantissent que les bons tests unitaires sont écrits. Les développeurs peuvent tester différents bogues avec leurs tests unitaires, ce qui rend extrêmement important le fait que plusieurs personnes testent le logiciel.
Rudolf Olah
127

Le développeur sait comment leur code fonctionne et tombera dans l'habitude de tester leur code en fonction de ces connaissances.

Le développeur aura du mal à se soustraire à la mentalité de «comment ça marche» par opposition à «comment ça devrait fonctionner».

Pour cette raison, il est préférable de faire tester le programme par une personne très objective, c’est-à-dire le contrôle qualité ou les ingénieurs de test

John Shaft
la source
3
D'accord, un développeur prendra le chemin de la moindre résistance pour "tester" son application, les cas extrêmes seront rarement examinés.
dnolan
68
@dnolan, ce n'est pas seulement "protéger" leur code, c'est aussi que tout ce à quoi ils n'ont pas pensé dans le codage, ils ne penseront pas aux tests.
StuperUser
4
Les développeurs testent également avec les mêmes préjugés que ceux qui ont guidé leur travail. Les testeurs sont moins susceptibles de les partager.
AProgrammer
4
@ Jörg W Mittag pas vraiment. De même que tous les testeurs ne penseront pas à tous les cas de test, tous les développeurs ne le feront pas non plus. Par conséquent, la programmation en paires, etc. Deux têtes valent toujours mieux qu'une.
StuperUser
18
À un endroit où je travaillais, je devais non seulement implémenter de nouvelles fonctionnalités, mais aussi rédiger des plans de test. Cela signifiait que si je comprenais mal quelque chose, il serait mal implémenté mais ne serait pas attrapé par le département de test.
David Thornley,
30

Testeurs Test pour casser, Simple. Ce type de partialité est nécessaire pour vraiment connaître les obstacles de la série.

Aditya P
la source
15

Les développeurs DOIVENT tester leur travail. C'est une responsabilité implicite.

Je suppose que vous ne disposez pas d'une équipe dédiée à la réalisation des tests à partir de votre déclaration. Cependant, le fait d'avoir une équipe dédiée aux tests aidera beaucoup car les développeurs ont tendance à tester leur code de la façon dont ils l'ont codé. Cela ne signifie pas qu'une fois que vous avez une équipe d'assurance qualité, vous pouvez déjà souscrire des tests sous la responsabilité des développeurs.

Les développeurs utilisent généralement des filets avec des trous énormes pour attraper les insectes. En conséquence, des bugs plus petits s'échappent.

Setzamora
la source
+1 pour "Les développeurs DOIVENT tester leur travail. C'est une responsabilité implicite" - L'intérêt de faire tester votre travail par quelqu'un d'autre est d'attraper les bugs que vous avez manqués, pas de faire votre travail pour vous (ce que certaines personnes semblent penser)
Wipqozn
15

Parce que les développeurs ne sont pas doués pour essayer de casser leur propre code. Leur esprit suit simplement le chemin correct d'entrée de données et d'interaction avec l'application. De nombreux bogues résultent d'une interaction avec le système, comme un gars normal . Les développeurs ne sont pas des utilisateurs normaux. Ce sont des utilisateurs professionnels.

Saeed Neamati
la source
3
D'une manière générale, les développeurs font un mauvais travail de tester leur propre code, et je me inclure dans ce groupe. Pour une entreprise qui fabrique des logiciels, un service d’assurance qualité solide comme le roc est absolument irremplaçable.
Adam Crossland
3
Pour les logiciels hautement complexes et spécialisés, les développeurs peuvent même ne pas être des utilisateurs professionnels du logiciel. Je ne peux certainement pas toujours prédire exactement comment un changement que j'apporterai à un élément clé aura une incidence sur d'autres parties du système. Le fait de demander à quelqu'un d'autre de passer au crible a pratiquement le même objectif que la programmation en binôme: non seulement cela vous oblige à en penser plus à l'avance, mais cela réduit également considérablement la probabilité qu'une erreur passe inaperçue jusqu'à ce qu'un client la rencontre. À ce stade, la réparation sera beaucoup plus coûteuse.
un CVn
Nous avons constaté par le passé que vous n'aviez pas nécessairement besoin de testeurs dédiés. Il suffit généralement qu'un autre développeur vérifie les fonctionnalités que vous avez écrites. Nous faisons cela parce que notre société pense pouvoir embaucher des singes pour les testeurs. Mais je suis d’accord, les bons testeurs sont très importants.
c_maker
10

Il y a quelques bonnes raisons d'avoir une équipe de test dédiée. Premièrement, comme mentionné ci-dessus, les développeurs savent très bien que leur code fonctionne, mais pas le casser.

En outre, comme vous le dites, un développeur sait ce qu'il a écrit, mais une équipe de test sait ce qui aurait dû être écrit. Parfois, ces deux concepts ne correspondent pas. L’une des tâches de l’équipe de test est de s’assurer que le logiciel répond aux exigences. Dans de nombreux cas, un développeur ne connaît que très bien quelques parties du système, mais l’équipe d’assurance qualité connaît le tout.

Ce qui nous amène à la raison suivante: les équipes de test effectuent des tests d'intégration complets. Le morceau de code que vous venez d'écrire pourrait bien fonctionner tout seul, mais pourrait casser d'autres fonctionnalités que vous ne connaissiez pas.

Ayant travaillé avec une équipe d’assurance qualité et sans, je peux vous dire que j’apprécie à 100% le travail qu’ils accomplissent et qu’ils diront qu’ils constituent un élément précieux de l’équipe des logiciels. Lorsque vous avez une équipe d’assurance qualité, il est beaucoup plus facile de publier votre code, car vous savez qu’il a fait l’objet de tests approfondis, ce qui signifie que vous recevrez moins d’appels à 3 heures du matin.

Tyanna
la source
J'aime le point sur l'assurance qualité qui consiste essentiellement à analyser le résultat pour s'assurer qu'il correspond aux exigences. C'est bien d'avoir au moins 2 personnes qui conviennent que cela fonctionne comme il se doit.
Andy Wiesendanger
+1 pour a testing teams knows what should have been written. C'est tellement très vrai.
un CVn
8

Les développeurs doivent tester leur propre code.

Les testeurs indépendants testent non seulement la rupture, ils testent également les hypothèses non déclarées et non définies que les développeurs ont faites lors du codage.

Gilbert Le Blanc
la source
+1: Cela devrait être mieux classé. Ce n'est pas seulement à propos de la paresse du développeur. Un développeur qui teste son propre code aura à l'esprit un certain ensemble d'hypothèses, les mêmes que celles qu'il avait en tête lors du codage. Il a donc un angle mort lors des tests. Il ne sera pas aussi inventif sur les moyens de casser son propre code qu'un testeur indépendant qui analyse son code avec des hypothèses complètement différentes.
Ken Bloom
7

Je m'attendrais à ce que le développeur fasse des tests initiaux avant de valider toute modification et s’assure que le code fonctionne. Je m'attendrais alors à ce que le développeur introduise dans les cas de test toutes les connaissances spécifiques de la "boîte blanche" dont il dispose. Par exemple, détaille toutes les autres zones du code qui pourraient avoir été affectées.

La principale objection aux développeurs qui testent leur propre code est que vous testez un seul point de vue. Le développeur a lu la spécification et l'a interprétée. Espérons que les spécifications sont claires, complètes et sans ambiguïté, mais ce n'est pas toujours le cas. Le développeur peut avoir mal compris une partie de la spécification. S'ils testent leur propre code, ils ne seront pas pris au dépourvu car ils découvriront que la fonction fonctionne comme prévu.

Différentes personnes auront également tendance à utiliser un produit de manière différente et à suivre le code de différentes manières. Un développeur aura veillé à ce que le code fonctionne pour eux, mais n'aura peut-être pas pris en compte le cas particulier d'un autre testeur.

Luke Graham
la source
5

Les développeurs doivent tester leur propre travail. Permettre aux développeurs de confier un travail non testé à une équipe d'assurance qualité ou à leurs collègues développeurs est une très mauvaise idée. Cela fait perdre du temps aux développeurs et aux testeurs et ruine les relations.

Cependant, cela ne suffit pas toujours. Les développeurs sont susceptibles de suivre une voie heureuse dans le système ou d’être aveugles face à certaines idiosyncrasies auxquelles ils ont été exposés à maintes reprises tout au long du développement.

Un autre point est qu’il peut y avoir plusieurs couches de communication entre spécification et déploiement. Cela peut entraîner un effet de Whispers chinois sur le déploiement final. Il est préférable que toute personne ayant défini l'exigence ou le rapport de bogue vérifie que cela fonctionne comme ils le souhaitaient.

Paul Butcher
la source
3

En tant que développeur, vous êtes responsable de votre propre code, vous devez le tester. Does the feature work as expected?Si la réponse est oui, vous avez terminé.

Pourquoi ne devriez-vous pas faire des tests?

  1. Vous êtes subjectif , car les bugs trouvés sont écrits par vous (ou vos collègues).
  2. Vous êtes trop cher pour que la société exécute des tests de cas. (J'espère).
Wesley van Opdorp
la source
2
Selon moi, cette idée que les développeurs ont trop de valeur pour <insérer la tâche que vous ne souhaitez pas faire ici> peut être plutôt corrosive.
Jeremy
3

En règle générale, les développeurs ne seront pas ceux qui utilisent le code, sauf dans certains cas spécialisés. Donc, la dernière étape de test avant la promotion sur un système de production devrait être le test d'acceptation par l'utilisateur, UAT. Ils sont généralement [censés être] plus au courant de ce qu'ils attendent du paquet. Et ils sont généralement plus capables de casser des choses avec des flux d'entrée inconnus de quelqu'un qui ne l'utilise pas quotidiennement.

Vos plans de projet ne permettent-ils pas de tester les utilisateurs? Si vous demandez à des utilisateurs de le tester, vous pourrez peut-être détecter les bogues plus tôt qu'après la mise en œuvre, ce qui dans mon monde n'est pas une mauvaise chose.

Temptar
la source
3

Les développeurs ne devraient pas tester leur propre code, car cela revient à juger l'art de votre propre enfant. Cela va vous sembler beau de toute façon, et vous avez vraiment besoin d'un professionnel pour signaler les défauts. Les tests unitaires, par contre, reviennent à s’assurer que votre enfant n’essaie pas de peindre avec du plomb.

Au cas où vous ne voudriez VRAIMENT pas embaucher du contrôle qualité, demandez aux développeurs d’écrire du code de test pour d’autres développeurs. C'est une bonne première étape - bientôt, vous verrez les développeurs demander des ressources d'assurance qualité, car la plupart de leur temps est consacré à la vérification du code d'autrui, en plus de la résolution des problèmes.

Subu Sankara Subramanian
la source
Oui, d' autres développeurs testant le code sont une solution minimale / temporaire, en l'absence d'autres ressources. (en supposant que vous ayez plusieurs développeurs disponibles bien sûr!)
Tao,
3

Ce n'est pas seulement les développeurs qui protègent leur code, s'ils ne réalisent pas un cas particulier, ou interprètent mal une spécification dans la façon dont ils développent quelque chose, ils rateront ces cas lors du test de leur code.

Les techniques et les compétences pour les tests sont également très différentes.

La plupart des tests effectués par une équipe de test sont fonctionnels (un produit fonctionne selon une spécification) et une boîte noire (l'équipe de test ne verra pas le fonctionnement interne d'une application). Les testeurs fonctionnels n'ont pas besoin de se préoccuper de la façon dont les choses fonctionnent, ils ont juste besoin de se concentrer sur leur succès.

StuperUser
la source
2

D'après mon expérience, au moins dans ma petite entreprise, l'utilisateur final doit effectuer des tests. Presque tous les projets que nous recevons ne fournissent pas toutes les informations nécessaires et omettent toujours certains détails. Le développeur est toujours désavantagé en matière de test car il ne sait pas comment faire le travail de l'utilisateur. Ainsi, bien qu'il sache que le logiciel fonctionne conformément aux informations qui lui ont été données, il ne sait pas si cela aidera l'utilisateur final. faire leur travail.

Kratz
la source
1
Absolument. Le code de travail n'est pas la même chose que le code correct pour la situation.
HLGEM
2

Les développeurs ont mal interprété et interprété les exigences, et les responsables de ces exigences omettent souvent de spécifier les éléments clés. Si personne à l'exception des tests de développeur, personne ne trouvera ces déconnexions avant la mise en production. Lorsque les développeurs testent, ils en savent trop sur la façon dont cela est supposé fonctionner et n'essaient pas les choses stupides que les utilisateurs pourraient essayer. Les développeurs écrivent également leurs tests sur la base de leur propre interprétation de l'exigence, ce qui est trop souvent contraire à la réalité. Donc, les tests réussissent mais l'exigence n'a pas été remplie. Lorsque vous avez différents tests de personne, cette personne peut avoir une idée différente des exigences et vous trouvez souvent les endroits où la demande est mal exprimée par la façon dont deux personnes différentes l’interprètent différemment. Mieux vaut le découvrir lors des tests qu'après son lancement.

HLGEM
la source
Oui, excellent point. Le fait que l’analyse commerciale fait souvent défaut signifie que les exigences sont au départ souvent incomplètes ou incomplètes, ce qui amène les développeurs à perdre du temps à satisfaire leurs exigences (très bien, mais prennent beaucoup de temps) ou à formuler des hypothèses (souvent incorrectes si le développeur est inexpérimenté). domaine).
Bernard Dy
2

Le développeur doit effectuer les tests initiaux pour que nous sachions que l'élément que nous avons codé fonctionnera comme prévu, conformément aux exigences que nous avons définies. Nous avons donc fait les tests normaux et écrit des tests unitaires pour le code que nous avons écrit.

L'étape suivante consiste pour QA à découvrir ce que les développeurs ne voient pas lorsque nous écrivons le code. Un développeur pense à un niveau supérieur, mais l'utilisateur peut ne pas penser au même niveau. Lorsque le développeur teste son travail et doit entrer du texte dans une zone de texte, il peut toujours entrer un utilisateur complet pensant que l'utilisateur le ferait également. Peut-être que l'utilisateur pourrait le faire aussi, mais de manière aléatoire quand il entre un caractère spécial comme% & $ ^ dans le texte et que l'application casse l'application, cela n'a pas l'air bien chez l'utilisateur final. Un développeur ne peut pas et ne veut pas penser à toutes les possibilités qui pourraient se présenter, car il n’est pas formé pour penser de cette façon. Quand il s'agit d'un QA (testeur), ils pensent toujours à ce que l'utilisateur peut faire pour casser cette application et essaie toutes les bêtises du livre. Ce ne sont pas les utilisateurs qui sont stupides, mais nous ne devons rien laisser au hasard.

Maintenant, nous devons aussi comprendre qu’il ya généralement plus d’une pièce réalisée en même temps et que les deux vont passer à la production. Le développeur peut tester uniquement sa pièce et penser que cela fonctionne bien, mais le test de régression global doit être effectué pour toutes les pièces qui sont insérées, ainsi que pour découvrir que la combinaison de deux pièces différentes risquerait de casser l'application. pas beau non plus. Nous devons également prendre en compte les scénarios de test de charge et d'autres éléments que les testeurs connaissent mieux.

Enfin, nous devons passer par le test d'acceptation de l'utilisateur (UAT) pour voir si la pièce que nous avons créée correspond à ce à quoi on s'attendait. En règle générale, même si les exigences passent par les BA, la personne finale ne sait peut-être pas exactement à quoi cela ressemble et il / elle pourrait penser que ce n’est pas ce à quoi ils s’attendaient ou ils pourraient vouloir ajouter quelque chose pour améliorer l’apparence ou pour une raison quelconque, ils pourraient supprimer le Toute la pièce car ils pensent que la pièce n’irait pas avec les fonctionnalités déjà disponibles.

Comme expliqué ci-dessus, elles sont très importantes et ne peuvent pas être réalisées par le développeur. Elles sont absolument indispensables au bon fonctionnement de l'application. La direction peut dire qu’il s’agit d’une approche conservatrice, mais c’est la meilleure. Nous pouvons faire quelques ajustements à ce qui précède, mais nous ne pouvons pas l'éviter dans son ensemble.

Amar Jarubula
la source
2

Les commentaires ci-dessus soulèvent de grands points.

Un autre point non mentionné précédemment est que le fait de disposer d’un code de test individuel distinct constitue une vérification supplémentaire des exigences et que le système les met correctement en œuvre.

Les exigences et la documentation ne sont pas parfaites et souvent, la mise en œuvre est le résultat de l'interprétation des exigences par un développeur.

Lorsque les tests sont effectués par une personne distincte, ils fournissent également leur propre interprétation des exigences lors de la création du plan de test et de l'exécution des tests.

Lorsque les activités de test sont effectuées indépendamment des activités de développement et que les résultats des deux tests sont "d'accord", cela fournit une confirmation supplémentaire que le système est correct et correspond vraiment à l'intention initiale des exigences.

tschaible
la source
2

Lors du test, un programmeur verra une zone de texte intitulée «Quantité» et entrera «1». Un programmeur très expérimenté fera ensuite un test de suivi avec la valeur "2".

Un utilisateur verra une zone de texte intitulée "Quantité" et entrera "~~ Unicorns ROX !!! ~~". Un utilisateur expérimenté essaiera également "-12 1/2".

Espérons qu'un testeur sera quelque part pour alerter le programmeur de ce que l'utilisateur va expérimenter lorsqu'il fait ces choses.

Jeffrey L Whitledge
la source
2

Une des raisons est que les développeurs sont trop proches de leur propre code. Ils savent que ce sont des bizarreries, des comportements peu étranges. Ils ont tendance à tester autour des petites idiosyncrasies qu'ils connaissent si bien. Ils ne sont pas assez objectifs à ce sujet. Les équipes de test le traitent comme une boîte noire. Ils écrivent des matrices de dizaines ou de centaines de tests et les parcourent méthodiquement pour voir ce que le code va faire. Souvent, ils proposent des scénarios dont l'équipe de développement n'aurait jamais rêvé.

Une autre raison est le temps. Pour les grands projets construits par étapes, l’équipe de développement créera l’étape 1. Ensuite, les testeurs la testeront pendant la construction de l’étape 2 et la résolution des défauts de l’étape 1. Cela continue pour toutes les étapes, donc l'étape à tester est la précédente qui a été construite.

FrustratedWithFormsDesigner
la source
1

Je veux rassembler quelques arguments pour expliquer pourquoi laisser un développeur tester son propre travail comme dernière étape avant la mise en production du test est une mauvaise idée, car malheureusement, mon lieu de travail le fait parfois (la dernière fois que cela a été évoqué). , la plupart des gens étaient trop occupés par d’autres tâches et n’avaient pas le temps de familiariser une autre personne avec cette partie du programme - c’est un logiciel très spécialisé).

Les tests ne sont pas facultatifs pour un développeur. Un développeur doit tester le code qu'il a écrit. Sinon, comment peut-il être certain que la tâche a été accomplie avec succès? Vous devez soit écrire un certain type de tests automatiques (unittests), soit effectuer le travail de vérification manuelle "est-ce que la machine fait ce que je veux qu'elle fasse" (en utilisant l'interface graphique, en appelant la commande sur la ligne de commande ou autre).

Tout ce qui est testé par la suite n'est "que" un test supplémentaire effectué par d'autres personnes (collègues, QA, ...). Il n'y a pas d'alternative aux tests directs par un développeur. Tous ceux qui me disent qu'un développeur n'a pas à tester (ou même n'est pas autorisé à) le code / la fonctionnalité qu'il a écrit n'ont tout simplement aucune compréhension de la façon dont le logiciel est développé.

perdian
la source
3
le PO ne demande pas si les développeurs devraient ou non faire des tests; l'OP demande si c'est une bonne idée que le développeur soit le seul à effectuer les tests.
Lie Ryan
1

Il est testé par une personne non familiarisée avec le code, que cela vous plaise ou non. La question est de savoir si vous voulez que cette personne soit votre client.

Karl Bielefeldt
la source
1

Excellente question. Dans votre cas, il existe parfois des cas de test et le logiciel semble assez complexe pour qu'un débutant soit au courant du produit, ce qui n'est pas pratique. Vous dites également que le test effectué est le test final avant la production

Raisons pour lesquelles le développeur peut effectuer le test final

  • La couverture de test est suffisante. Les tests unitaires existent, un environnement de test d'intégration existe et est utilisé, des tests d'interface utilisateur, des tests exploratoires, etc. ont été effectués, etc. Un test final est donc moins un critère d'acceptation rigoureux qu'un test final " parcourir"
  • Un ensemble de cas de test écrits par un professionnel / testeur SQA existe et que quelqu'un (un développeur) peut / doit suivre explicitement
  • Le risque de défaillance de la fonction / du produit / du module a par ailleurs été réduit à des niveaux bas (laissez le professionnel tester les zones à risque élevé et un test "recrue" le risque le plus faible)
  • La réalité de la situation commerciale est qu'il est préférable de libérer un produit potentiellement défectueux plutôt que de retarder la publication.
  • Le développeur en question est également un testeur très qualifié et est capable de faire évoluer mentalement les rôles.
  • Il s’agit d’une correction de bogue faite sur le terrain par le développeur lorsque le site du client est fermé ou perd de toute autre façon des revenus en raison de la mise hors ligne du système (un correctif sera ramené au bureau et testé / publié dans une version contrôlée dès que possible. )

Raisons pour lesquelles un développeur ne devrait pas faire les tests

  • Rien d'autre

En général, il semble que vous soyez sur le bon chemin pour attaquer la vraie solution - Demandez à l'expert SQA de générer les scénarios de test ...

Remarque: je suis généralement favorable à ce que les développeurs effectuent les tests, mais je m'assure que le premier point existe ...

Al Biglan
la source
1

Les êtres humains, en tant qu'êtres humains, ont tendance à souffrir de biais cognitifs - leur jugement reposant sur deux scénarios presque identiques sera alors différent, simplement à cause de certaines choses qui ont changé - une chose que j'ai remarquée en 8 ans de développement, c'est que est confronté au test de son propre code, par opposition au code écrit par un collègue, les tests effectués sur son propre code sont d'une qualité bien pire.

Cela ne veut pas dire que le développeur est directement fautif - son cerveau utilisera le parti pris qu’il a écrit pour renforcer le fait qu’il croit que c’est juste et ne fera que des vérifications de base, par opposition à un développeur qui regarde le code de quelqu'un d'autre, fera des vérifications beaucoup plus approfondies.

Il existe des milliers d'exemples dans lesquels une procédure a été mise en place pour prévenir les distorsions cognitives, ou communément appelée "Le facteur humain", telle que des systèmes informatisés dans le contrôle du trafic aérien, afin d'empêcher que deux aéronefs différents n'occupent le même espace aérien au même moment. temps, aux procédures médicales mises en place de sorte que plus d'un médecin doit donner un diagnostic.

Il est grand temps que le secteur des technologies de l’information adopte une attitude plus professionnelle et mette en place des procédures afin d’empêcher le test de votre propre code.

Codeur chirurgical
la source
1
  • Tous les utilisateurs doivent tester: code de test Develpers, fonctionnalité de test des QA'ers, messagerie de test Marketing. De cette façon, tout le monde partage les mêmes philosophies et le même langage autour des tests, ce qui représente une moitié du combat.

  • Le test est un entretien de routine et j'utilise généralement des analogies pour comparer . Par exemple, l'analogie de changement d'huile de voiture. Vous n'avez jamais à changer votre huile. Mais vous le faites régulièrement quand même. Même chose pour se brosser les dents. Il y a une raison pour laquelle vous les entretenez quotidiennement: ils ne vont pas craquer «aujourd'hui», il s'agit de demain et des jours à venir et d'investir.

  • Tout le monde devrait partager la responsabilité de tester. Une équipe d’assurance qualité est importante. Toutefois, le fait de «tester» comme étant une tâche réservée à l’équipe d’assurance qualité en fait une activité «distincte» qui n’est pas intégrée au développement du produit et au flux de travail, ce qui n’est pas une bonne chose.

  • Quand quelque chose se brise dans la production, faites deux choses:

    1. Dites "hmm, avons-nous un test pour cela " comme premier commentaire.
    2. Assurez-vous que les correctifs incluent des tests pour le problème , d’abord à reproduire, puis corrigez-les.
Michael Durrant
la source
0

Dans mon entreprise, nous développons des applications financières assez complexes. Notre politique générale est que le développeur doit s'assurer qu'aucune erreur technique ne survient. Essentiellement, essayez tout ce que vous pouvez pour le casser, compte tenu des ressources de l'utilisateur. Si vous ne trouvez pas d'erreur d'exécution, envoyez-la aux BA pour le tester. Nous avons eu quelques développeurs qui se sont perdus en testant les exigences de l'entreprise jusqu'au point d'épuisement, mais uniquement parce que tous ces tests n'étaient pas de leur responsabilité. À moins d'une erreur flagrante clairement visible, nous l'envoyons aux personnes qui sont payées pour comprendre le résultat. En outre, les utilisateurs devraient jouer un rôle réel dans la vérification des résultats. Le vendeur dans un magasin de vente au détail n'essaie pas les vêtements pour vous, il vous aide seulement avec les "détails techniques" comme trouver des vêtements de la bonne taille.

Morgan Herlocker
la source
0

L'un des problèmes est que les développeurs sont peu enclins à violer leur propre code: peu de personnes sont disposées à rechercher des défauts dans leurs propres travaux ou à commettre des erreurs. Avoir une équipe séparée aide à s'assurer que les choses seront cassées.

Wyatt Barnett
la source
-1

Un rôle d’assurance qualité est essentiel, entre autres raisons, pour que l’on puisse vérifier que le développeur a bien compris les exigences. Le développeur ne peut pas effectuer cette vérification lui-même car s’ils pensaient avoir mal compris, cela demanderait des éclaircissements.

Stephen Paulger
la source