Comment savoir quand arrêter les tests?

Je sais que c'est une question très très fondamentale. Pour certaines applications logicielles, il existe un nombre presque infiniment élevé de cas de test pour une application. Il n'est pas pratique de tester tous ces cas de test. Comment décider quand arrêter les tests? (autre que "lorsque l'argent s'épuise").

Le livre de Glenford Myers The Art of Software Testing a une règle simple mais bien fondée sur des principes: le test est terminé lorsque vous avez arrêté de trouver des bogues. Ou, plus concrètement, lorsque la vitesse à laquelle vous trouvez de nouveaux bugs ralentit considérablement.

Les bogues ont tendance à "se regrouper" dans certains modules et certaines fonctions: au moment où vous trouvez un bogue dans un, vous savez que vous devriez y chercher plus de bogues. Pour trouver des bogues, vous pouvez utiliser les techniques de test de boîte noire, de test de boîte blanche et de test de mutation. Tant que vous trouvez des bogues, vous savez que votre processus de test fonctionne!

Pour visualiser votre progression, indiquez le nombre de bogues que votre équipe a détectés par jour. Si le graphique descend, vous savez que les techniques que votre équipe utilise ne les trouveront pas de toute façon. Bien sûr, si vous pensez que vos techniques ne sont pas à la hauteur, veuillez lire le livre de Myers et appliquer les principes.

Maintenant, il est possible que vous manquiez simplement un nouveau patch de bogues, et le taux de détection de bogues aurait considérablement augmenté si vous aviez continué à tester un peu plus. Cependant, si vous pensez que vos techniques sont solides, cela est peu probable.

La réponse simple est que cela dépend du système. Si vous écrivez un logiciel intégré pour un moniteur cardiaque ou des outils de surveillance de la sécurité pour un réacteur nucléaire, la norme est beaucoup plus élevée que si vous écrivez une plate-forme de blogs.

C'est vraiment une question pour un bon testeur de système (et je n'en suis pas un) mais je vais essayer.

Votre mesure de base sera la couverture du test: quelle quantité de l'application a été réellement testée (à la fois par test unitaire et fonctionnellement).

Vous devez évaluer chaque cas d'utilisation potentiel (et les paramètres de ce cas d'utilisation) pour la probabilité qu'il soit réellement utilisé (afin que vous puissiez supprimer les cas limites), la complexité (les choses plus simples étant moins susceptibles de contenir des bogues, ou plutôt moins susceptibles de contenir du matériel pour trouver des bugs), le coût du test (en termes de temps) et l'impact potentiel d'un défaut s'il est découvert dans cette zone (c'est là qu'intervient le réacteur nucléaire vs la plateforme de blogging).

Sur la base de cette évaluation, vous devez déterminer lesquels d'entre eux vont être testés et dans combien de détails. Une fois que vous avez une liste comme celle-là, l'équipe (y compris un chef de produit / chef de projet / représentant des utilisateurs) peut parcourir cette liste et établir des priorités en fonction des contraintes que vous avez.

Une technique utile à considérer est que vous pouvez également varier les cas d'utilisation testés avec chaque version. Par exemple, vous pouvez avoir une liste de cas de test non critiques et tester la moitié d'entre eux avec une version et l'autre avec la suivante (puis alternative). De cette façon, vous augmentez la couverture totale des tests que vous obtenez pour l'effort (mais au risque d'introduire des bogues de régression).

Cela peut également s'étendre aux tests de plate-forme - si vous prenez en charge deux back-ends de base de données (ou plusieurs navigateurs), testez la moitié de l'application sur l'un, l'autre moitié sur l'autre, puis échangez la prochaine version.

(Je pense que c'est ce qu'on appelle le rayage, mais ne me citez pas à ce sujet.)

Et puis la dernière chose à penser n'est pas ce que vous testez mais ce que vous corrigez réellement lorsque des problèmes sont découverts. Il est courant de dire "corriger tous les bugs" mais la réalité est qu'il y a des contraintes de temps et que tous les bugs ne sont pas égaux. Encore une fois, des nettoyages de bogues réguliers avec toutes les parties concernées sont la meilleure voie à suivre. Cela est particulièrement pertinent lorsqu'un correctif de bogue peut être particulièrement intrusif, car le travail supplémentaire de test et de test de régression qu'il génère peut l'emporter sur les avantages du correctif.

Lorsque le risque associé à l'utilisation du logiciel a été réduit à un niveau acceptable.

"Les tests de programme peuvent être utilisés pour montrer la présence de bugs, mais jamais pour montrer leur absence!" --Edsger Dijkstra

Quelque chose de bien à garder à l'esprit lors de tout test, automatisé ou autre. Vous pouvez seulement prouver que vous n'avez plus trouvé de bogues, pas qu'il n'y en a plus.

Mais plus vous mettez les yeux sur une section de code, plus vous pouvez être sûr de son bon fonctionnement. Cela ressemble beaucoup à la citation de Knuth sur l'optimisation à cet égard: vous pouvez tester les mauvaises choses très facilement et vous pouvez tester aux mauvais moments de votre développement.

Essentiellement, vous voulez être couvert dans deux grands endroits:

1. Le logiciel réussit-il les tests BDD qui démontrent qu'il répond aux exigences spécifiées. Le logiciel ne peut même pas être appelé terminé si ce n'est pas vrai.

2. Les segments les plus critiques, complexes et incertains ont-ils des tests adéquats pour assurer la confiance? S'il s'agit d'une boucle principale, ou quelque chose que vous avez dû optimiser ou pirater: mettez-le à l'épreuve. Si c'est compliqué et a beaucoup de divisions logiques: mettez-y beaucoup de tests. Si vous ne pouvez pas le tester à l'unité, ou s'il est trop profond pour être testé directement: assurez-vous que le code a été révisé et le code indirectement testé à la main.

Si vous attendez la fin du projet, vous aurez en effet un très grand nombre de cas de test. Si vous livrez en continu, en vous concentrant sur les petites livraisons, vous aurez moins de cas de test à chaque itération et vous pourrez tout tester. Si vous ne pouvez pas faire de petites livraisons, hiérarchisez et commencez les tests à partir de la plus grande priorité et passez les tests jusqu'à ce que vous deviez arrêter.

Si vous parlez de tests unitaires et que vous effectuez TDD (en écrivant d'abord les tests), ce n'est pas un problème: vous arrêtez simplement de tester lorsque les fonctionnalités sont terminées.

En TDD incrémentiel, vous écrivez un test qui échoue, puis implémentez la plus petite quantité de code qui peut le faire passer, puis refactorisez. Continuez à ajouter des tests de cette manière jusqu'à ce que la méthode soit terminée.

Voici un bon exemple.

Les statisticiens se sont également penchés sur cette question - en fait dès les années 1970-80. Compte tenu des hypothèses appropriées sur la façon dont les bogues sont découverts, ils essaient d'estimer le nombre de bogues à partir des données des tests. Ceci est ensuite utilisé pour déterminer quand s'arrêter en fonction de l'optimisation d'une fonction de perte. Voir par exemple https://rpubs.com/hoehle/17920 ... pour un bref traitement d'un des articles sur cette question, y compris le code R sur la façon de le faire dans la pratique.

Bien sûr, un problème sera toujours les hypothèses sur le processus de découverte de bogues. Par exemple, dans le traitement ci-dessus, on suppose que les bogues sont découverts indépendamment les uns des autres. En pratique, la correction d'un gros bogue peut, par exemple, provoquer de nouveaux bogues, etc.

Lorsque la date d'expédition est arrivée. Il n'y a pas de fin à tester un logiciel. Mais là encore, il y a quelque chose connu sous le nom de calendrier. Vous devrez tester la plupart de vos fonctionnalités dans le temps prévu et corriger les bugs que vous rencontrez. Il n'y a aucun moyen de garantir que le logiciel est parfait.

Les premières choses à tester seraient le «chemin heureux», les cas marginaux et les entrées invalides. S'il y aura plus d'un utilisateur simultané, vous devrez tester les problèmes de concurrence comme le verrouillage et les conditions de concurrence. Si l'application utilise des ressources externes, vous devrez tester le comportement de l'application lorsque ces ressources ne sont pas disponibles. Après cela, vous pouvez utiliser le code pour rechercher des éléments susceptibles de provoquer sa rupture et les tester. Lorsque tous ces tests réussissent, le rapport coût / bénéfice des tests supplémentaires commence à augmenter, il est donc raisonnable de s'arrêter à ce stade.

Tout se résume à une question de confiance. Êtes-vous convaincu que le système est suffisamment testé?

De toute évidence, le «niveau de confiance» est très subjectif puisque vous ne pouvez jamais vous sentir complètement certain, mais suffisamment certain - et c'est ce que nous recherchons. Pour cela, vous devez créer une liste d'indicateurs, communément connue sous le nom de définition du fait et devrait être un point sur lequel toute votre équipe est d'accord.

Voici quelques "indicateurs terminés" liés aux tests:

• Votre build et votre installation sont-ils complètement automatisés et tous les tests (unit, gui, intégration) exécutés automatiquement?
• Écrivez-vous vos tests pendant (ou de préférence avant) l'écriture du code, plutôt qu'après?
• Vous sentez-vous suffisamment en sécurité pour refactoriser un gros code sans introduire de bogues?
• Votre niveau de couverture de code est-il suffisamment élevé?
• Avez-vous un testeur dédié dans votre équipe? Est-il / elle impliqué (e) quotidiennement tout au long du développement et pas seulement à la fin?
• Votre testeur a-t-il essayé manuellement (exploratoire) de le casser sans succès?

Si vous pouvez vérifier ces points, vous pouvez probablement dire que vous avez suffisamment testé.

Jamais, je pense que vous n'aurez jamais fini de tester dans un système .. il y a tellement de variables que vous ne pouvez pas gérer.

Mais, comme nous le savons, vous ne pouvez pas tester "pour toujours", donc je pense que la limite dépend essentiellement de:

• Lorsque le risque associé à l'utilisation du logiciel a été réduit à un niveau acceptable. (comme le dit @Graham Lee)
• Qui est l'utilisateur du système? cela peut être vous ou le président des États-Unis. Dans le premier cas, peu importe si un bug apparaît parce que vous le résolvez et que c'est fait. Dans le deuxième cas, vous ne voulez voir apparaître AUCUN bug.
• Quelle est votre relation avec votre client? Peut-être que le client est votre père, donc ce n'est pas si terrible, ou peut-être que c'est une grande entreprise.
• Quelle est la gravité du bug pour les utilisateurs du système? Sera-ce la cause de la troisième guerre mondiale ou juste un vilain message?

Lorsque les personnes qui doivent se déconnecter du déploiement sont satisfaites.

ou dans certains cas, la majorité des responsables est satisfaite.