Pourquoi laisser / ne pas laisser les développeurs tester leur propre travail
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 produit est une mauvaise idée, car malheureusement, mon lieu de travail le fait parfois (la dernière fois que cela arrive , l'argument se résumait au fait que la plupart des gens étaient trop occupés avec d'autres choses 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 y a des plans de test dans ce cas (mais pas toujours), mais je suis très favorable à ce qu'une personne qui n'a pas apporté les modifications testées effectue réellement le test final. Je vous demande donc si vous pourriez me fournir une bonne et solide liste d'arguments que je pourrais aborder la prochaine fois que nous en discuterons. Ou pour fournir des contre-arguments, au cas où vous pensez que cela convient parfaitement, surtout lorsqu'il y a des cas de test formels à tester.
Comme d'autres (et vous-même) l'avez remarqué, les développeurs devraient tester en bloc leur propre code. Cependant, après cela, tout produit non trivial devrait également être testé par des personnes indépendantes (service AQ et/ou le client lui-même).
Les développeurs travaillent normalement avec la mentalité de développeur de "comment faire fonctionner cela?" . Un bon testeur réfléchit à "comment briser cela?" - un état d'esprit très différent. Les tests unitaires et TDD apprennent aux développeurs à changer de chapeau dans une certaine mesure, mais vous ne devriez pas vous y fier. De plus, comme d'autres l'ont fait remarquer, il existe toujours un risque de malentendu. Par conséquent les tests d'acceptation finale doivent être effectués par une personne aussi proche que possible du client.
Le développeur sait comment fonctionne son code et prendra l'habitude de tester son code en fonction de ces connaissances.
Le développeur aura du mal à se retirer de la mentalité de "comment cela fonctionne" par opposition à "comment cela devrait fonctionner".
Pour cette raison, il est préférable de demander à une personne ayant un haut degré d'objectivité de tester le programme, c'est-à-dire QA ou Test Engineers
Test des testeurs pour casser, Simple. Ce type de biais est nécessaire pour vraiment découvrir les bouchons de show.
Les développeurs DOIVENT tester leur travail. C'est une responsabilité implicite.
Je suppose que vous n'avez pas d'équipe dédiée pour effectuer les tests basés sur votre déclaration. Cependant, avoir une équipe dédiée aux tests sera vraiment utile car les développeurs ont tendance à tester leur code comme ils l'ont codé. Cela ne signifie pas qu'une fois que vous avez une équipe d'assurance qualité, vous pouvez déjà prendre des tests sous la responsabilité des développeurs.
Les développeurs utilisent généralement des filets avec d'énormes trous pour attraper les bogues. 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 bon chemin d'entrée de données et d'interaction avec l'application. De nombreux bugs sont le résultat d'une interaction avec le système comme un type 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. Tout d'abord, comme mentionné ci-dessus, les développeurs sont très bons pour tester que leur code fonctionne, mais pas pour le casser.
De plus, comme vous le dites, un développeur sait ce qu'il a écrit, mais les équipes de test savent ce qui aurait dû être écrit. Parfois, ces deux concepts ne correspondent pas. L'une des tâches de l'équipe de test consiste à 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 QA sait tout.
Ce qui conduit à la raison suivante, les équipes de test effectuent des tests d'intégration complète. Le morceau de code que vous venez d'écrire pourrait bien fonctionner seul, mais pourrait casser d'autres fonctionnalités que vous ne connaissiez pas.
Ayant travaillé avec une équipe QA et sans, je peux vous dire que j'apprécie à 100% le travail qu'ils font et je dirai qu'ils font partie de l'équipe logicielle. Lorsque vous avez une équipe QA, cela rend la publication de votre code beaucoup plus facile, b/c vous savez qu'il a été minutieusement testé et cela signifie que vous recevrez moins d'appels à 3 heures du matin.
Les développeurs doivent tester en bloc leur propre code.
Les testeurs indépendants testent non seulement la rupture, ils testent les hypothèses non énoncées et non définies que les développeurs ont faites lors du codage.
Je m'attendrais à ce que le développeur fasse quelques tests initiaux avant de valider les modifications et se soit assuré que le code fonctionne. Je m'attendrais alors à ce que le développeur insère dans les cas de test toutes les connaissances spécifiques qu'il possède. Par exemple, détaille tous les autres domaines du code qui peuvent avoir été affectés.
La principale objection aux développeurs qui testent leur propre code est que vous ne testez qu'un seul point de vue. Le développeur a lu la spécification et l'a interprétée. Espérons que la spécification soit claire, complète et sans ambiguïté, mais ce n'est pas toujours le cas. Le développeur a peut-être mal compris une partie de la spécification. S'ils testent leur propre code, cela ne sera pas détecté car ils constateront que la fonction fonctionne comme prévu.
Différentes personnes auront également tendance à utiliser un produit de manière différente et à suivre différents itinéraires à travers le code. Un développeur aura veillé à ce que le code fonctionne pour eux, mais peut ne pas avoir considéré un cas Edge qu'un autre testeur pourrait trouver.
Les développeurs devraient tester leur propre travail. Laisser les développeurs pousser le travail non testé à une équipe d'AQ 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.
Mais cela ne suffit pas toujours. Les développeurs sont susceptibles de suivre un chemin heureux à travers le système, ou d'être aveugles à 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 un certain nombre de couches de communication entre la spécification et le déploiement. Cela peut conduire à un effet Whispers chinois sur le déployable final. Il est préférable que celui qui a défini l'exigence ou le rapport de bogue teste que cela fonctionne comme il le souhaite.
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 feriez-vous pas des cas de test?
- Vous êtes subjectif, car les bogues trouvés sont écrits par vous (ou vos collègues).
- Vous êtes trop cher pour que l'entreprise exécute des tests de cas. (J'espère).
En règle générale, les développeurs ne seront pas, dans la plupart des cas, ceux qui utilisent le code, sauf dans certains cas spécialisés. Ainsi, la dernière étape de test avant la promotion vers un système de production devrait être le test d'acceptation par l'utilisateur, UAT. Ils sont généralement [censés être] plus familiers avec ce qu'ils attendent du package. Et sont généralement plus capables de casser les choses avec des flux d'entrée inconnus de quelqu'un qui ne les utilise pas quotidiennement.
Vos plans de projet ne répondent-ils pas aux tests utilisateurs? Si vous demandez aux utilisateurs de le tester, vous pouvez attraper des bogues avant la post-implémentation, ce qui n'est pas une mauvaise chose dans mon monde.
Les développeurs ne devraient pas tester leur propre code, car cela revient à juger l'art de votre propre enfant. Ça va vous sembler beau de toute façon, et vous avez vraiment besoin d'un professionnel pour signaler les défauts. Les tests unitaires, d'autre part, reviennent à s'assurer que votre enfant n'essaie pas de peindre avec du plomb.
Au cas où vous ne voudriez VRAIMENT pas embaucher de l'AQ, 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 des développeurs demander des ressources d'assurance qualité car la plupart de leur temps est consacré à tester le code des autres, en plus de CR.
Ce n'est pas seulement les développeurs qui protègent leur code, s'ils ne réalisent pas un cas particulier, ou qu'ils interprètent mal une spécification dans la façon dont ils développent quelque chose, alors ils manqueront 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 (qu'un produit fonctionne selon une spécification) et 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 seulement besoin de se concentrer sur leur fonctionnement.
Un programmeur, lors des tests, 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 saisira "~~ licornes ROX !!! ~~". Un utilisateur expérimenté essaiera également "-12 1/2".
Avec un peu de chance, un testeur sera là quelque part pour alerter le programmeur sur ce que l'utilisateur va vivre quand il fera ces choses.
D'après mon expérience, au moins dans ma petite organisation, l'utilisateur final doit tester. Presque tous les projets que nous recevons, ils ne fournissent pas toutes les informations nécessaires et omettent toujours certains détails. Le développeur est toujours désavantagé en termes de tests car il ne sait pas comment faire le travail de l'utilisateur, donc bien qu'il sache que le logiciel fonctionne selon les informations qui lui ont été fournies, il ne sait pas si cela aidera l'utilisateur final. faire leur travail.
Les développeurs ont mal lu et mal interprété les exigences et les responsables des exigences ne parviennent souvent pas à spécifier les éléments clés. Si personne, sauf les tests du développeur, personne ne trouvera ces déconnexions avant d'être mis en ligne. Lorsque les développeurs testent, ils en savent trop sur la façon dont il est censé 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 qui n'est trop souvent pas ce que l'on voulait vraiment dire. Les tests réussissent donc mais l'exigence n'est pas remplie. Lorsque vous testez une personne différente, cette personne peut avoir une idée différente des exigences et vous trouvez souvent les endroits où la retraite a été mal exprimée par la façon dont deux personnes différentes l'interprètent différemment. Il vaut bien mieux le découvrir lors des tests qu'après la mise en ligne.
Le développeur doit effectuer les tests initiaux afin que nous sachions que la pièce que nous avons codée fonctionnerait de la manière attendue, conformément aux exigences que nous avons. Nous devons donc effectuer les tests normaux et écrire des tests unitaires pour le code que nous avons écrit.
La prochaine étape est le travail des QA pour 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 sa pièce et doit entrer du texte dans une zone de texte, il peut toujours entrer une chaîne complète, pensant que l'utilisateur le ferait également. Peut-être que l'utilisateur peut le faire aussi, mais au hasard quand il entre un caractère spécial comme% & $ ^ dans le texte et que cela casse l'application, cela ne semble pas bon pour l'utilisateur final. Un développeur ne peut pas et ne pensera pas à toutes les possibilités qui pourraient se produire parce qu'il n'est pas formé à penser de cette façon. Quand il s'agit d'un QA (testeur), ils pensent toujours à ce que l'utilisateur pourrait faire pour casser cette application et essayer toutes les choses stupides du livre, pas les utilisateurs sont stupides mais nous ne devons rien laisser au hasard.
Maintenant, nous devons également comprendre qu'il y a généralement plus d'une pièce réalisée en même temps et que les deux iront en production. Le développeur pourrait 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 poussées, ainsi que pour découvrir que la combinaison de deux pièces différentes pourrait casser l'application et il le fait pas bien non plus. Nous devons également tenir compte des scénarios de test de charge et d'autres choses que les testeurs connaissent mieux.
Enfin, nous devons passer par UAT (User Acceptance Test) pour voir si la pièce que nous avons faite correspond à ce qui est attendu. Généralement, bien que les exigences passent par les BA, la personne finale pourrait ne pas savoir exactement à quoi cela ressemble et il/elle pourrait penser que ce n'est pas ce à quoi elle s'attendait ou ils pourraient vouloir ajouter quelque chose d'autre pour le rendre plus beau ou pour une raison quelconque, ils pourraient supprimer le pièce entière car ils pensent que la pièce n'irait pas avec les fonctionnalités déjà disponibles.
Comme expliqué ci-dessus, ceux-ci sont très importants et ne peuvent pas être effectués par le développeur seul et sont absolument nécessaires pour que l'application fonctionne correctement. La direction peut dire que c'est une approche conservatrice mais c'est la meilleure approche. Nous pouvons apporter quelques modifications à ce qui précède, mais nous ne pouvons pas les éviter dans leur ensemble.
Les commentaires ci-dessus soulèvent de grands points.
Un autre élément non mentionné précédemment est que le fait d'avoir un code de test individuel distinct agit comme une vérification supplémentaire des exigences et si le système les met correctement en œuvre.
Les exigences et la documentation ne sont pas parfaites, et la mise en œuvre est souvent 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 sont "d'accord", cela fournit une confirmation supplémentaire que le système est correct et correspond vraiment à l'intention initiale des exigences.
Une des raisons est que les développeurs sont trop proches de leur propre code. Ils savent que ce sont des caprices, ce sont des petits comportements étranges. Ils ont tendance à tester autour les 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 cas de test et les parcourent méthodiquement pour voir ce que le code fera. 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 qui sont construits par étapes, l'équipe de développement construira la phase 1. Ensuite, les testeurs la testeront pendant la phase 2 en cours de construction et les défauts de la phase 1 seront corrigés. Cela continue pour toutes les étapes, donc l'étape en cours de test est la précédente qui a été construite.
Il est testé par quelqu'un qui ne connaît pas le code, que cela vous plaise ou non. La question est de savoir si vous voulez que quelqu'un soit votre client.
Les êtres humains, étant humains, ont tendance à souffrir de biais cognitifs - où leur jugement dans deux scénarios presque identiques différera, simplement en raison de certaines choses qui ont changé - une chose que j'ai remarquée en 8 ans de développement, c'est que lorsqu'un développeur est confronté à tester son propre code, contrairement au code qu'un collègue a écrit, les tests effectués sur leur propre code sont de bien pire qualité.
Cela ne veut pas dire que le développeur est en faute directement - son cerveau utilisera le parti pris qu'il a écrit, pour renforcer le fait qu'il croit que c'est son droit, et n'effectuera que des vérifications de base, contrairement à un développeur qui regarde le code de quelqu'un d'autre, fera beaucoup de vérifications plus approfondies.
Il existe des milliers d'exemples où une procédure a été mise en place pour prévenir les biais cognitifs, ou communément appelés "le facteur humain", tels que les systèmes informatisés de contrôle du trafic aérien, pour empêcher deux avions différents d'occuper le même espace aérien en même temps. temps, aux procédures médicales mises en place afin que plus d'un médecin doive poser un diagnostic.
Il est grand temps que l'industrie informatique évolue vers une attitude plus professionnelle et mette en place des procédures pour empêcher les tests de votre propre code.
Grande question. Dans votre situation, des cas de test - parfois - existent et le logiciel semble être suffisamment complexe pour que la mise à niveau d'un novice sur le produit ne soit pas pratique. Vous dites également que le test effectué est le test final avant la production
Raisons pour lesquelles le développeur pourrait faire le test final
- Il y a suffisamment d'autres couvertures de tests ... Des 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"
- Il existe un ensemble de cas de test écrits par un SQA/testeur professionnel que quelqu'un (un développeur) peut/doit suivre explicitement
- Le risque de défaillance de la fonctionnalité/du produit/du module a autrement été atténué à de faibles niveaux (laissez le professionnel tester les zones à haut risque et un "débutant" teste le risque le plus faible)
- La réalité de la situation commerciale est qu'il est préférable de publier un produit présentant des défauts potentiels que de retarder la publication.
- Le développeur en question est également un testeur très qualifié et est capable de faire mentalement le changement de rôle
- Le changement est un correctif de bogue fait sur le terrain par le développeur lorsque le site du client est fermé ou autrement perd des revenus en raison de la mise hors ligne du système (un correctif qui 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 effectuer les tests
- Rien d'autre
En général, il semble que vous soyez sur la bonne voie pour attaquer la vraie solution - Demandez à l'expert SQA de générer les cas de test ...
Remarque: Je suis généralement en faveur de laisser les développeurs faire les tests, mais je fais en sorte que la première puce existe ...
Tout le monde devrait tester - le code de test Develpers, la fonctionnalité de test QA'ers, la messagerie de test marketing. De cette façon, tout le monde partage les mêmes philosophies et le langage autour des tests, ce qui représente la moitié de la bataille.
Les tests sont une maintenance de routine et j'ai l'habitude tilisez des analogies pour comparer. Par exemple, l'analogie du changement d'huile de voiture. Vous n'avez jamais à changer votre huile. Mais vous le faites régulièrement de toute façon. Idem pour se brosser les dents. Il y a une raison pour laquelle vous les entretenez quotidiennement - ils ne vont pas se casser "aujourd'hui", il s'agit de demain et des jours futurs et de faire un investissement.
Tout le monde devrait partager la responsabilité pour tester. Une équipe QA est importante, mais faire des "tests" comme quelque chose que seule l'équipe QA fait en fait est une activité "séparée" qu'elle n'est pas intégrée au développement de produits et au workflow, ce qui n'est pas une bonne chose.
Quand quelque chose tombe en panne dans la production, faites deux choses:
- Dites "hmm, avons-nous un test pour cela " comme premier commentaire.
- Faire n'importe quel correctif inclure des tests pour le problème , d'abord pour reproduire, que corriger.
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 arrive , l'argument se résumait au fait que la plupart des gens étaient trop occupés avec d'autres choses 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 une sorte de tests automatisés (unittests) ou effectuer le travail de vérification "la machine fait-elle ce que je veux qu'elle fasse" manuellement (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" des tests supplémentaires 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é.
Dans mon entreprise, nous créons des applications financières assez complexes. Notre politique générale est que le développeur veille à ce qu'aucune erreur technique ne survienne. Fondamentalement, 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 test. Nous avons eu quelques développeurs qui se sont perdus dans les tests des exigences commerciales au point de s'épuiser, mais uniquement parce que tous ces tests n'étaient pas de leur responsabilité. Sauf s'il y a une erreur flagrante qui est clairement visible, nous l'envoyons aux personnes qui sont payées pour comprendre le résultat. De plus, les utilisateurs devraient avoir un vrai rôle dans la vérification des résultats. Le vendeur d'un magasin de détail n'essaye pas les vêtements pour vous, il vous aide uniquement avec les "détails techniques" comme trouver des vêtements de la bonne taille.
Un problème est que les développeurs sont peu incités à casser leur propre code - peu de gens sont prêts à rechercher des défauts dans leurs propres travaux ou à faire des erreurs. Le fait d'avoir une équipe distincte permet de s'assurer que les choses seront brisées.