Pourquoi Cem Kaner considère-t-il qu'un test ne révélant pas un bug est une perte de temps?


15

Qu'en est-il de confirmer la fonctionnalité dans des tests positifs, de prouver qu'elle fonctionne - dois-je dire que c'est une perte de temps? Quel genre de concept se cache derrière cette citation?

Les tests infructueux, c'est-à-dire les tests qui ne détectent pas d'erreurs, sont une perte de temps.

Web Engineering: The Discipline of Systematic Development of Web Applications citant Cem Kaner .


2
Pas vraiment. Kaner affirme qu'en général, les tests devraient simplement trouver des défauts.
John V

4
C'est une position très académique. M. Kaner et M. Schrödinger doivent parfois s'asseoir pour une tasse de café.
Blrfl

2
@Blrfl seul problème avec cela est que M. Schrödinger est mort. Oh, attendez ... euh ...
ikmac

1
Cette déclaration sans contexte semble incroyablement stupide ...
Rig

1
«Confirmer la fonctionnalité dans des tests positifs» - C'est fondamentalement impossible. Vous ne pouvez pas prouver quelque chose de correct, vous ne pouvez que le prouver.
Konrad Rudolph

Réponses:


37

J'ai écrit la plupart des tests de logiciels informatiques il y a plus de 25 ans. J'ai depuis indiqué plusieurs parties du livre que je considère comme obsolètes ou tout simplement erronées. Voir http://www.kaner.com/pdfs/TheOngoingRevolution.pdf

Vous pouvez en voir plus (vues actuelles, mais sans pointeurs explicites vers TCS) sur mon site pour le cours de test de logiciel Black Box (vidéos et diapositives disponibles gratuitement), www.testingeducation.org/BBST

La culture de test à l'époque était largement confirmative.

Dans les tests modernes, l'approche des tests unitaires est largement confirmative - nous écrivons de grandes collections de tests automatisés qui vérifient simplement que le logiciel continue de fonctionner comme prévu. Les tests servent de détecteurs de changement - si quelque chose dans d'autres parties du code et cette partie a maintenant des problèmes, ou si des valeurs de données qui étaient auparavant impossibles dans le monde réel atteignent maintenant l'application, alors les détecteurs de changement se déclenchent, alertant le programmeur à un problème de maintenance.

Je pense que l'état d'esprit de confirmation est approprié pour les tests unitaires, mais imaginez un monde dans lequel tous les tests du système étaient confirmatifs (pour les personnes qui font une distinction, veuillez interpréter les "tests d'intégration du système" et les "tests d'acceptation" comme inclus dans mes commentaires sur le système test.) Le but du test était de confirmer que le programme répondait à ses spécifications et l'approche dominante était de créer un million (ou au moins quelques centaines) de tests de régression au niveau du système qui mappaient des parties de la spécification aux comportements du programme. (Je pense que la confirmation de la spécification au comportement est utile, mais je pense que c'est une petite partie d'un objectif plus large.)

Il existe encore des groupes de test qui fonctionnent de cette façon, mais ce n'est plus la vue dominante. À l'époque, ça l'était. J'ai écrit avec emphase et j'ai dessiné de forts contrastes pour souligner les gens qui étaient constamment formés dans cet état d'esprit. Aujourd'hui, certains des contrastes marqués (y compris celui cité ici) sont dépassés. Ils sont mal interprétés comme des attaques contre les mauvais points de vue.

À mon avis, les tests de logiciels sont un processus empirique d'apprentissage des informations liées à la qualité d'un produit ou service logiciel.

Un test doit être conçu pour révéler des informations utiles.

À l'époque, d'ailleurs, personne ne parlait du test comme méthode pour révéler des "informations". À l'époque, les tests visaient soit (une version de ...) à trouver des bogues, soit (une version de ...) à vérifier (vérifier) ​​le programme par rapport aux spécifications. Je ne pense pas que l'affirmation selon laquelle les tests servent à révéler des informations utiles soit entrée dans le vocabulaire des tests jusqu'à ce siècle.

Imaginez les tests de notation en fonction de leur valeur d'information. Un test qui est très susceptible de nous apprendre quelque chose que nous ne savons pas sur le logiciel aurait une valeur d'information très élevée. Un test qui est très susceptible de confirmer quelque chose que nous attendons déjà et qui a déjà été démontré à plusieurs reprises auparavant, aurait une faible valeur d'information. Une façon de hiérarchiser les tests consiste à exécuter des tests de valeur d'informations plus élevés avant des tests de valeurs d'informations plus faibles.

Si je devais simplifier à l'excès cette hiérarchisation afin qu'elle attire l'attention d'un programmeur, d'un chef de projet ou d'un responsable de processus qui n'a aucune idée des tests de logiciels, je dirais "UN TEST QUI N'EST PAS CONÇU POUR RÉVÉLER UN BOGUE EST UNE PERTE DE TEMPS . " Ce n'est pas une traduction parfaite, mais pour les lecteurs qui ne peuvent ou ne comprendront aucune subtilité ou qualification, c'est aussi proche que possible.

À l'époque, et je le revois ici, certaines personnes qui ne comprennent pas les tests répondraient qu'un test conçu pour trouver des cas d'angle est une perte de temps par rapport à un test d'une utilisation majeure d'une fonction majeure. Ils ne comprennent pas deux choses. Premièrement, lorsque les testeurs trouvent le temps de vérifier les valeurs limites, les principales utilisations des principales fonctions ont déjà été exercées plusieurs fois. (Oui, il existe des exceptions, et la plupart des groupes de tests accorderont une attention particulière à ces exceptions.) Deuxièmement, la raison pour laquelle tester avec des valeurs extrêmes est que le programme est plus susceptible d'échouer avec des valeurs extrêmes. Si cela n'échoue pas à l'extrême, vous testez autre chose. C'est une règle efficace. D'un autre côté, s'il échoue à une valeur extrême, le testeur peut s'arrêter et signaler un bug ou le testeur peut dépanner davantage, pour voir si le programme échoue de la même manière à des valeurs plus normales. Qui fait ce dépannage (le testeur ou le programmeur) est une question de culture d'entreprise. Certaines entreprises budgétisent le temps du testeur pour cela, certaines budgétisent les programmeurs et certaines s'attendent à ce que les programmeurs corrigent les bugs de coin, qu'ils soient généralisables ou non, de sorte que le dépannage ne soit pas pertinent. Le malentendu courant - que les testeurs perdent du temps (plutôt que de maximiser l'efficacité) en testant des valeurs extrêmes est une autre raison pour laquelle "Un test qui n'est pas conçu pour révéler un bug est une perte de temps" est un message approprié pour les testeurs. C'est un contrepoint à l'encouragement de certains programmeurs à (en fait) ne jamais exécuter de tests qui pourraient contester le programme. Le message est trop simplifié, mais toute la discussion est trop simplifiée.

Soit dit en passant, la «valeur de l'information» ne peut pas être le seul système de priorisation. Ce n'est pas ma règle lorsque je conçois des suites de tests unitaires. Ce n'est pas ma règle lorsque je conçois des tests de vérification de build (aka sanity checks). Dans ces deux cas, je suis plus intéressé par les types de couverture que par la puissance des tests individuels. Il existe d'autres cas (par exemple, des tests automatisés à haut volume qui sont peu coûteux à configurer, à exécuter et à surveiller) où la puissance des tests individuels n'est tout simplement pas pertinente pour ma conception. Je suis sûr que vous pouvez penser à des exemples supplémentaires.

Mais en règle générale, si je pouvais énoncer une seule règle (par exemple, parler à un cadre dont la tête explose s'il essaie de traiter plus d'une phrase), ce serait qu'un test à faible valeur d'information est généralement une perte de temps.


4
+1 pour avoir pris le temps de répondre à une question pour laquelle vous êtes la source faisant autorité, ainsi que pour valider mon utilisation du terme "Build Verification Tests" que tant de gens me regardent avec plaisir ... Toujours agréable de voir des gens de votre stature prenant le temps d'aider les gens d'ici
Jimmy Hoffa

1
Eric G: Je pense que si vous relisez, vous verrez que Cem déclare qu'en tant que lecteur, il comprend que sa vision du sujet a évolué au fil du temps. Ou vous pouvez simplement continuer et ignorer la subtilité et les qualifications, pour paraphraser Cem. (et je prends les "qualifications" non pas comme ses références, mais comme exceptions.)
Jim Holmes

Votre citation me rappelle quelque chose que j'ai observé à propos de la science: on ne peut pas prouver (ou même soutenir de manière significative) une théorie scientifique en menant des expériences dont on s'attend à ce qu'elle produise des résultats cohérents avec la théorie; la façon de soutenir une théorie est de faire un effort de bonne foi pour expérimenter des dispositifs qui ne la soutiendront pas, mais ne pouvant pas le faire.
supercat

@supercat vous pouvez soutenir une théorie avec un test pour quelque chose de cohérent avec la théorie si le test ne vous était pas venu à l'esprit avant la théorie (par exemple, montrer l'accélération d'un objet tombant dans le vide est comme vous le calculeriez pour être en dit plus que de montrer qu'il tombe). Les tests de cas de bord sont analogues; Je pourrais m'attendre à ce que le logiciel se comporte correctement lorsqu'il s'agit de valeurs extrêmes, mais cela donne plus de confiance dans la qualité pour voir que cela se produit que pour répéter les valeurs d'entrée qu'il a probablement vues pendant le développement, tout en étant plus susceptible de trouver un bogue.
Jon Hanna

@ JonHanna: Ma formulation était médiocre: le problème n'est pas l'attente, mais l'effort. On ne peut pas prouver une théorie en essayant de trouver des tests qu'elle réussira; il faut s'efforcer de bonne foi de trouver des tests qui échoueraient s'ils n'étaient pas valides.
supercat

11

L'idée est, selon Kaner, "puisque vous manquerez de temps avant de manquer de cas de test, il est essentiel d'utiliser le temps disponible aussi efficacement que possible."

Le concept derrière la citation que vous demandez est présenté et expliqué en détail dans l'article Testing Computer Software par Cem Kaner , Jack Falk, Hung Quoc Nguyen, dans le chapitre "LES OBJECTIFS ET LIMITES DES TESTS":

ALORS, POURQUOI TESTER?

Vous ne pouvez pas trouver tous les bugs. Vous ne pouvez pas prouver que le programme est correct et vous ne le souhaitez pas. C'est cher, frustrant et cela ne vous rapporte aucun concours de popularité. Alors, pourquoi s'embêter à tester?

LE BUT DE TESTER UN PROGRAMME EST DE TROUVER DES PROBLÈMES DANS CELUI-CI

La recherche de problèmes est au cœur de votre travail. Vous devriez vouloir en trouver autant que possible; plus le problème est grave, mieux c'est.

Comme vous manquerez de temps avant de manquer de cas de test, il est essentiel d'utiliser le temps disponible aussi efficacement que possible. Les chapitres 7, 8, 12 et 13 examinent en détail les priorités. Le principe directeur peut être exprimé simplement:


Un test qui révèle un problème est un succès. Un test qui n'a pas révélé de problème était une perte de temps.


Considérons l'analogie suivante, tirée de Myers (1979). Supposons que quelque chose ne va pas avec vous. Vous allez chez un médecin. Il est censé exécuter des tests, découvrir ce qui ne va pas et recommander des mesures correctives. Il exécute test après test après test. À la fin de tout cela, il ne trouve rien de mal. Est-il un grand testeur ou un diagnosticien incompétent? Si vous êtes vraiment malade, il est incompétent et tous ces tests coûteux ont été une perte de temps, d'argent et d'efforts. Dans le logiciel, vous êtes le diagnosticien. Le programme est le patient (assurément) malade ...


Vous voyez, le point ci-dessus est que vous devez prioriser vos tests à bon escient. Le test devrait prendre un temps limité et il est impossible de tout tester dans le temps imparti.

Imaginez que vous ayez passé une journée (semaine, mois) à exécuter des tests, à ne trouver aucun bogue et à laisser passer un bogue parce que vous n'aviez pas le temps d'exécuter un test qui le révélerait. Si cela se produit, vous ne pouvez pas simplement dire "ce n'est pas de ma faute parce que j'étais occupé à effectuer d'autres tests" pour justifier cette erreur - si vous le dites, vous serez toujours tenu responsable.

Vous avez perdu du temps à exécuter des tests qui n'ont pas révélé de bogues et à cause de cela, vous avez raté un test qui trouverait un bogue.

(Au cas où vous vous poseriez la question, les échecs comme ci-dessus sont généralement inévitables, peu importe comment vous essayez, et il existe des moyens de les résoudre, mais ce serait plus un sujet pour une question distincte ... et probablement un meilleur choix pour SQA. SE.)


12
Cette réponse représente correctement sa position, mais il convient de souligner que de nombreuses personnes pensent que sa position est erronée. Étant donné le choix entre un test qui démontre que la fonction la plus importante de l'application fonctionne correctement (test d'acceptation, si vous voulez) et un test qui trouve un bug trivial (alignement d'un pixel) dans un coin rarement utilisé de l'application, je savoir ce que je choisirais dans mon temps limité. Et pour l'analogie avec le médecin: si je vais POUR UN CONTRÔLE plutôt qu'en réponse à des symptômes, confirmer que le cœur est bon, les poumons sont bons, etc., etc. est un bon résultat. Donc là.
Kate Gregory

@KateGregory Je suis d'accord, je pense la même chose. Je trouve toujours son opinion erronée, nous testons principalement pour recueillir des informations ..
John V

2
@KateGregory est d'accord - je ne pense pas qu'il soit exact d'étiqueter un test réussi comme un déchet total. Cependant, je pense qu'un point qu'il fait est intemporel : si le bug passe à travers les tests de publication, le contrôle qualité aurait besoin de quelque chose de plus que "oh mais nous étions occupés à exécuter d'autres tests" pour couvrir leur dos. J'ai moi-même vécu cela en tant que testeur dans le passé, et je vois ça maintenant que je suis développeur, et je ne pense pas que cela disparaîtra jamais
mnat

4

Eh bien, je ne connais pas M. Caner, mais à mon humble avis

tests qui ne détectent pas d' erreurs

sont une perte de temps. Cela inclut la situation où vous avez déjà des tests (peu importe s'ils sont automatiques ou simplement sur une liste de contrôle), et vous ajoutez de nouveaux tests qui valident essentiellement les mêmes cas que vous avez déjà. Vos nouveaux tests ne trouveront donc pas plus d'erreurs que les existants.

Une telle situation peut se produire, par exemple, si vous parcourez simplement une liste de façon aléatoire - je pourrais aussi dire «sans cervelle» (pardonnez-moi ce mot) - choisissez des cas de test dans votre programme, sans penser s'ils vérifient un nouveau cas de pointe, une nouvelle équivalence classes de vos données d'entrée, ou si elles augmentent la couverture du code par rapport aux tests déjà écrits.


-1

À mon avis, cette citation fait référence à des tests trop généraux ou non fiables.

Si vous effectuez un test pour une fonction qui valide les e-mails et que vous ne fournissez que des e-mails valides, ce test est complètement inutile. Il faudrait tester cette fonction pour "n'importe quelle" chaîne possible, courriels invalides, courriels trop longs, caractères Unicode (áêñç ....)

Si vous codez un test qui vérifie uniquement que name@dom.com renvoie vrai et que nom @ com renvoie faux, ce test est identique à aucun test du tout.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.