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

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.

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 .

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

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

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.

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.

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.

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.

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.

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.

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).

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.

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.

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.

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.

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.

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.

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.

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.

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.

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é.

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.

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 ...

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.

• 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.

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.

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.

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.