Les programmeurs sont-ils de mauvais testeurs?

36

Je sais que cela ressemble beaucoup à d’autres questions qui ont déjà été posées, mais c’est en fait légèrement différent. Il semble être généralement considéré que les programmeurs ne sont pas bons pour jouer le rôle de tester une application. Par exemple:

Joel on Software - Cinq bonnes raisons de ne pas avoir de testeurs (c'est moi qui souligne)

Ne pensez même pas à essayer de dire aux diplômés en informatique de niveau CS qu'ils peuvent venir travailler pour vous, mais que "tout le monde doit faire une pause en assurance qualité pendant un moment avant de passer au code." J'ai vu beaucoup de cela. Les programmeurs ne font pas de bons testeurs et vous perdrez un bon programmeur, qui est beaucoup plus difficile à remplacer.

Et dans cette question , l'une des réponses les plus populaires dit (encore une fois, mon emphase):

Les développeurs peuvent être des testeurs, mais ils ne devraient pas être des testeurs. Les développeurs ont tendance à éviter involontairement / inconsciemment d’utiliser l’application d’une manière qui pourrait la casser. C'est parce qu'ils l'ont écrit et le testent principalement de la façon dont il devrait être utilisé.

La question est donc de savoir si les programmeurs sont mauvais pour les tests? Quelles preuves ou quels arguments existe-t-il pour étayer cette conclusion? Les programmeurs sont-ils seulement mauvais pour tester leur propre code? Existe-t-il des preuves suggérant que les programmeurs sont réellement bons pour les tests?

Qu'est-ce que je veux dire par "tester?" Je ne parle pas des tests unitaires ou de tout ce qui est considéré comme faisant partie de la méthodologie utilisée par l'équipe de logiciels pour écrire des logiciels. Je veux dire une sorte de méthode d’assurance qualité qui est utilisée après que le code ait été généré et déployée sur ce que cette équipe logicielle appellerait «l’environnement de test».

jhsowter
la source
17
@jshowter Les programmeurs sont pires lorsqu'ils testent leur propre code tout en étant brillants lorsqu'ils testent du code d'autres personnes. Les testeurs (bons testeurs) sont eux-mêmes des programmeurs (car ils doivent comprendre la logique de programmation et ses fonctionnalités), à ceci près qu'ils n'écrivent pas trop de code. Je pense que cela a plus à voir avec la psychologie puisque j'hésite toujours à trouver des doutes dans mon propre travail, aussi mauvais soit-il.
Ubermensch le
6
@ Ubermensch, je suis en désaccord avec le fait que les développeurs sont de brillants testeurs du code des autres par défaut. Certains développeurs le sont, après avoir pratiqué les tests pendant un certain temps. Cela nécessite un état d'esprit différent et un type de motivation différent, ce qui n'est pas du tout évident pour les développeurs en général. De nombreux développeurs ont tendance à se concentrer sur la partie codage et à en profiter le plus, et peuvent ne pas comprendre - ou même ne pas être conscients de - l’importance d’autres activités dans le cadre du SDLC complet.
Péter Török
1
@ jshowter Si vous recherchez des faits concrets / des données de recherche, je ne les trouve pas. La plupart de la littérature concerne le développement agile et n'a pas pu trouver celui qui correspond à votre cas particulier. Vous pouvez essayer chez Google Scholar ou Scirus.
Ubermensch
3
Nous ne sommes pas de mauvais testeurs! Cela a fonctionné sur mon PC! ;-)
Joris Timmermans
2
@MadKeithV Ha! Ceci est mon avatar JIRA (question tracker);)
yannis

Réponses:

39

La question semble porter spécifiquement sur le test du système , c'est donc ce dont je parle tout au long de cette réponse.

Je pense qu'il y a une distinction importante à faire entre être une mauvaise personne pour choisir d'effectuer un test et être réellement mauvais pour le test.

Pourquoi les programmeurs sont mauvais en test:

  • Si vous avez écrit le code, vous (devriez) déjà avoir pensé à autant de façons possibles que les choses pourraient mal tourner et en avoir traité le problème.
  • Si trouver un bogue particulièrement dangereux signifie que vous devez ensuite y remédier, il se peut que vous en ayez marre dans un code, cela ne vous aidera pas à motiver.

Pourquoi les programmeurs sont bons pour tester:

  • Les programmeurs ont tendance à être des penseurs logiques et à travailler de manière systématique.
  • Les programmeurs expérimentés seront très efficaces pour identifier rapidement les cas critiques et proposer ainsi des tests utiles. (S'il existe un processus de test formalisé, la plupart de ces cas devraient déjà avoir été identifiés et testés avant le test des systèmes.)
  • Les programmeurs savent très bien s’assurer que toutes les informations utiles sont consignées dans un rapport de bogue.

Pourquoi les programmeurs sont-ils de mauvais testeurs?

  • Les programmeurs sont plus chers que les testeurs (dans la grande majorité des cas).
  • La mentalité est fondamentalement différente: "Construire un produit (fonctionnel)" vs "Cette chose ne sort pas avec des bugs (inconnus) dedans."
  • Les testeurs seront généralement plus efficaces, c'est-à-dire qu'ils effectueront plus de tests dans le même temps.
  • Les programmeurs sont spécialisés dans la programmation. Les professionnels de l'assurance qualité sont spécialisés dans les tests.
vaughandroid
la source
4
Notez que la pensée logique des programmeurs peut être un inconvénient pour être un bon testeur. Combien de fois avez-vous vu un programmeur réagir avec "mais c'est impossible!" quand confronté à un bug trouvé? Seulement pour découvrir qu'ils avaient manqué quelque chose de sérieux dans leur raisonnement qui rendait le virus "impossible".
Joris Timmermans
2
@CraigYoung - il est clair que c'est une pensée logique défectueuse, mais c'est très courant (les systèmes sont complexes). Le fait est qu'en testant, vous ne devriez pas utiliser la pensée logique pour éliminer les tests "inutiles", et il semble difficile pour les développeurs d'éviter ce type de pensée.
Joris Timmermans
3
+1 Une excellente réponse équilibrée. Explique également pourquoi la combinaison entre les tests unitaires automatisés et d'intégration écrits par les programmeurs et les tests système effectués par le contrôle qualité est la meilleure combinaison.
Danny Varod
1
+1 pour "l'état d'esprit est fondamentalement différent". Après tout, ce sont des rôles différents, avec des ensembles de compétences connexes (mais différents).
joshin4colours
3
@MadKeithV La pensée logique est essentielle dans les tests, tout comme l'élimination des tests inutiles. Envisagez-vous des tests boîte noire ou blanche? Dans le test de la boîte noire, vous concevez des tests à partir des exigences sans connaître l’implémentation. Pour vérifier les hypothèses erronées, la logique erronée, etc. Les développeurs IMHO sont bons à cela, à condition qu'ils ne connaissent pas la mise en œuvre. En particulier, s'ils ont écrit le code et commis des erreurs, ils sont inévitablement enclins à commettre les mêmes erreurs lors des tests. Les tests du système doivent être des tests de type boîte noire.
MarkJ
19

Je pense que les programmeurs sont mauvais pour tester leur propre code .

Nous aimons croire que notre code fonctionne parfaitement selon les exigences et le tester en tant que tel. À ma place, nous testons notre propre code, puis les uns des autres avant de les publier dans le cycle de test réel, et beaucoup plus de bogues ont été détectés de cette manière que par le seul test de notre propre code.

Amy
la source
1
Mes deux centimes. Les développeurs testent généralement uniquement les dernières modifications, le dernier correctif, la dernière fonctionnalité, ce qu'ils ont fait (et le mien) et, dans certains cas, ils (nous) sont un peu aveugles ou paresseux pour tester d'autres fonctionnalités.
Andrea Girardi
11

Les programmeurs sont certainement les personnes appropriées pour tester certaines parties du système. À certains endroits, ils sont les seuls à pouvoir le faire efficacement.

Un endroit où les programmeurs ont tendance à être très mauvais au test est le bit "utilisez l'interface utilisateur comme un utilisateur normal" - ils ne sont pas des utilisateurs normaux et ne se comportent pas comme eux. Par exemple:

  • Les programmeurs ont tendance à être très doués pour obtenir des entrées de texte parfaites. Je vois un problème assez commun qui concerne les espaces de début ou de fin. La plupart des gens n'y paraissent pas, mais les bons programmeurs sont probablement religieux pour faire de leurs chaînes la chaîne appropriée sans espaces superflus.
  • Les programmeurs ont tendance à être des claviéristes, tirant parti des onglets et autres raccourcis pour accélérer le travail. Les utilisateurs normaux ont tendance à saisir la souris entre les champs.
  • Les programmeurs ont tendance à comprendre ce que le système leur dit plutôt que d'ignorer les messages d'erreur et de cliquer simplement sur OK.

Ainsi, les utilisateurs normaux font beaucoup de choses que les programmeurs ne font pas. Vous ne pouvez pas compter entièrement sur l'équipe de développement pour UAT.

Wyatt Barnett
la source
3
Exemple supplémentaire pour votre premier point: nos utilisateurs ont tendance à copier à partir de MS Word, ce qui insère des éléments étranges comme em-dash et citations intelligentes - qui vont parfois casser même les bibliothèques que nous n'avons pas écrites. Aucun de nous n'est jamais dans Word, de sorte que les cas d'utilisation nous traversent à peine l'esprit, et encore moins qu'on les teste.
Izkata
1

Au niveau technique (tests unitaires, tests d'intégration, tests de régression), les programmeurs sont probablement les seules personnes qualifiées à être testeurs, car ces types de tests sont automatisables et doivent donc être automatisés, ce qui nécessite une programmation.

Mais je ne pense pas que ce soit ce dont vous parlez, et je suis à peu près sûr que ce n'est pas ce que Joel Spolsky veut dire non plus - c'est la partie qui reste, le test manuel pratique: transformer un document d'exigences et une spécification fonctionnelle en un script de test et ensuite exécuter méticuleusement ce script par rapport au produit fini.

Être un bon testeur requiert des qualités essentiellement orthogonales à celles d'un bon programmeur. Il y a un peu de chevauchement - vous devez être capable de penser de manière analytique, vous avez besoin d'une certaine affinité avec les ordinateurs en général - mais à part cela, les compétences d'un testeur sont très différentes. Cela en soi ne signifie pas que vous pouvez avoir les deux ensembles de compétences, et en fait, certaines personnes le font probablement. Cependant, pour être un très bon programmeur, il faut une certaine paresse (le désir d'automatiser vos tâches), tandis qu'un très bon testeur a besoin de persistance (vérifiez que les trois mille champs de formulaire ne sont pas incohérents), et même les programmeurs qui ont ce qu’il faut pour être un testeur qui a généralement horreur de cette idée.

Et puis il y a le biais sélectif: un programmeur qui est déjà impliqué dans un projet, même si ce n'est que marginalement, a déjà des connaissances de base sur le code base, et aura du mal à l'aborder avec un esprit vide, du point de vue de l'utilisateur final . Cela n'a même pas besoin d'être explicite, comme dans "Je sais que ce bouton fonctionne, je vais donc simplement noter" pass ". cela peut être beaucoup plus subtil, et ces effets subtils peuvent faire en sorte que des cas critiques soient omis lors des tests.

tdammers
la source
1

D'après mon expérience, oui, les programmeurs sont de mauvais testeurs. Trop souvent, j’ai vu les autres et moi-même aller «Hein, mais j’ai testé cela avant de me connecter! face à un testeur reproduisant le bug devant vous.

Pourquoi? Eh bien, je ne sais pas pourquoi, mais peut-être que c’est parce que nous voulons voir les choses fonctionner. Ou nous voulons simplement en finir avec les tests de telle ou telle fonctionnalité.

Quoi qu'il en soit, les tests ne sont pas une compétence que nous avons apprises et nous ne travaillons pas en tant que programmeur, car nous sommes doués pour casser des fonctionnalités. Nous pourrions également ne pas avoir la moindre idée de la planification d’un test ou de tout ce que l’AQ fait. Nous ne sommes plus qualifiés pour effectuer le travail d'un testeur, comparé à un testeur pour implémenter votre nouveau pipeline de rendu 3D.

Comme dans la question, tester ne veut rien dire d'automatisé mais bien tester en utilisant le programme.

Morothar
la source
1

Il y a plusieurs niveaux de test. Les tests de "bas niveau" peuvent et doivent être réalisés par les développeurs. Je pense à l'unité testig.

D'autre part, les tests "de haut niveau" sont totalement une autre chose. En général, je pense que les développeurs sont de mauvais testeurs, non pas parce qu'ils manquent de compétences, mais parce qu'il est très difficile de changer de façon de penser et de travailler en quelques instants.

J'essaie de tester le plus possible mes codes, mais après au moins 10 minutes effectuées par un testeur, un problème ou une amélioration se pose. Cela signifie que tester quelque chose que vous créez est un travail difficile. Vous savez où cliquer, vous savez quand vous cliquez, vous connaissez la logique métier, vous savez probablement comment les données sont conservées. Tu es un dieu que tu ne tomberas jamais.

AngeloBad
la source
0

Quel genre de test voulez-vous dire? Si vous voulez dire par des tests exhaustifs exhaustifs, je pourrais comprendre certaines raisons de dire oui bien que je soupçonne que la plupart des gens seraient pauvres dans cette catégorie si l’on considère toutes les combinaisons possibles d’intrants comme une exigence pour de tels tests.

Je peux reconnaître que le développeur qui conçoit le logiciel peut avoir une vision en tunnel en ce qui concerne le code à traiter et ignorer certains cas limites que l’on n’aurait peut-être pas pris en compte. Par exemple, si je crée un formulaire Web qui prend un nombre, n, puis imprime de 1 à n à l'écran, je risque de rater des cas particuliers, comme si rien n'est entré ou quelque chose qui n'est pas un nombre naturel, comme e ou pi. . Qu'est-ce que le programme est censé faire dans ces cas peut être discutable.

Le développement piloté par les tests serait un exemple de méthodologie de développement qui met les tests sous un jour différent et qui peut donner une autre vision ici.

JB King
la source
Merci d'avoir demandé ça. J'ai mis à jour ma question pour indiquer ce que je considère comme des tests. Essentiellement, les tests sont une activité qui survient après la construction et le déploiement du logiciel, et non pendant le développement (comme les tests unitaires) ou dans le cadre d'une méthodologie de développement (comme l'évaluation par les pairs).
Jhsowter
0

Les programmeurs définissent très bien les tests lorsqu'ils définissent les tests avant d' écrire le code. Avec la pratique, ils vont encore mieux.

Cependant, lors de la définition des tests de code qu'ils ont écrits, ils ne font pas très bien. Ils auront les mêmes angles morts dans les tests qu’ils avaient lors de l’écriture du code.

Utiliser des programmeurs pour faire des tests manuels n’est que stupide. Le test manuel est assez idiot seul; obliger les programmeurs à le faire est extrêmement ridicule. C'est cher et chasse les programmeurs compétents.

Kevin Cline
la source
Bien que je préconise l'écriture de tests unitaires et d'intégration, je ne vois pas comment TDD (ou l'écriture des tests en premier) résoudrait ce problème. Si vous écrivez les principaux scénarios de réussite avant le code, vous ne trouverez probablement pas la plupart des bogues. Vous devez penser à tout ce qui peut mal tourner. Avoir du code écrit, peut vous aider à trouver certains d’entre eux, car vous pouvez passer en revue les branches et les méthodes que vous appelez pour voir ce qui peut les casser.
Danny Varod
En outre, bon nombre des bugs que j'ai découverts et que les développeurs avaient manqués étaient liés aux ordres d'appel de l'API. Ce que la plupart des tests unitaires ne couvrent pas, en particulier si vous ne connaissez pas d'autres méthodes susceptibles d'affecter celle que vous testez (et qui n'a pas encore été implémentée).
Danny Varod
@Danny: avec TDD, vous ne devriez écrire que des branches ou des méthodes en réponse à un test qui a échoué, et vous écrivez uniquement le code nécessaire pour réussir le test qui a échoué.
Kevin Cline
Je connais la méthodologie de TDD, je ne suis tout simplement pas d'accord avec les conclusions.
Danny Varod
0

Un type de test auquel les développeurs ont particulièrement échoué est le test si les exigences sont remplies. Ce que les développeurs pensent que quelque chose dans une exigence signifie et ce que les testeurs pensent que cela signifie sont souvent deux choses complètement différentes.

Je peux penser à un exemple récent où le développeur a été invité à effectuer une exportation delta et à la pensée du développeur qui visait à obtenir tous les enregistrements qui n’avaient pas été envoyés et les testeurs pensaient que cela signifiait obtenir de nouvelles recrues et des modifications. Ils devaient retourner chez le client pour savoir qui avait raison. J'ai codé le code et j'ai fait la même hypothèse que le développeur a fait sur l'exigence. Parce que logiquement, si vous vouliez inclure des mises à jour, vous les auriez mentionnées. Et je suis généralement bon pour repérer ces choses ambiguës car j’étais du côté utilisateur.

Ainsi, d’autres développeurs effectuant les tests auraient tendance à émettre bon nombre des mêmes hypothèses, car elles auraient également formulé certaines hypothèses telles que "ils auraient eu plus de détails s’ils parlaient de X vice Y parce qu’il ya tant de détails à résoudre avant que je puisse le faire. Mais les rédacteurs d’exigences ne pensent pas de la sorte. Ainsi, une personne qui pense davantage comme des rédacteurs d’exigences doit tester les hypothèses du développeur et une personne qui n’est pas un développeur est la meilleure personne pour même s’apercevoir qu’il ya un problème.

HLGEM
la source