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.