Il faut savoir quand arrêter le test, particulièrement dans une organisation peu mature. En effet, les organisations matures construisent de bonnes données empiriques. Elles connaissent leur taux de défauts par point de fonction ou, plus généralement, par KLOC (milliers de lignes de code exécutable). Si le taux de défauts attendu
Savoir quand s’arrêter
n’est pas atteint, elles modifient en conséquence leur méthode de test. Mais, en général, la plupart des entreprises utilisatrices de System i ont de petites équipes IS et peu de temps pour maîtriser parfaitement une multitude de mesures.
Nos activités de test sont régies par des contraintes de temps ou de budget. Et il n’y aura jamais assez de temps pour effectuer tous les cas . Mais si nous adoptons une approche basée sur le risque, nous aurons exécuté tous les cas de tests de priorité haute et moyenne, d’après le plan. Prenons un scénario plus plausible : nous avons couvert sept jours d’un test de 14 jours et nous n’avons plus trouvé de défauts. Peut-être que le système testé n’a pas d’autres défauts (hautement improbable), nos scénarios de cas de tests ne sont pas bons (plus probable), ou le nombre de défauts fluctue selon la zone du système testée.
Nous devons alors prendre une décision fondée sur des facteurs tels que le produit développé, le risque de délivrer un logiciel mal testé, notre propre niveau de confiance, et la qualité du code programme produit. Il n’est pas rentable de consacrer un seul jour à tester le système pour découvrir un défaut mineur. Mais délivrer un logiciel insuffisamment testé est en fin de compte beaucoup plus coûteux. A moins d’être l’homme-orchestre de votre entreprise, résistez à la tentation de trouver la cause racine d’un défaut dans le test système.
Notez vos résultats et continuez si possible par la séquence de test suivante. Les programmeurs sont souvent tentés non seulement de mettre le système en panne, mais aussi de montrer qu’ils peuvent le réparer. Le temps consacré à cela n’est pas un bon usage du temps de test. Le test système doit se dérouler comme une machine bien huilée. Par exemple, un contrôleur de qualité sur une chaîne de montage automobile ne décide pas de réparer une pièce défectueuse et, ce faisant, d’arrêter toute la chaîne. Il reconnaît et documente le problème et passe à la voiture suivante. Vous devriez faire de même : charger quelqu’un d’autre de corriger les défauts.
Téléchargez cette ressource
Guide de Cyber-résilience pour Microsoft 365
La violation de votre tenant M365 va au-delà d’un simple incident de cybersécurité. Elle peut entraîner une interruption opérationnelle généralisée, des perturbations commerciales et une exposition de vos données sensibles. Découvrez les méthodes et technologies pour évaluer, comparer et renforcer votre posture de sécurité Microsoft 365.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Les 3 prédictions 2026 pour Java
- Infrastructures IT : 5 leviers concrets pour éviter les impasses technologiques
- Top 6 des priorités des DSI en 2026
- Semi-conducteurs : comment l’Irlande veut contribuer à atténuer la pénurie mondiale de puces
Articles les + lus
CES 2026 : l’IA physique et la robotique redéfinissent le futur
Les 3 prédictions 2026 pour Java
Semi-conducteurs : comment l’Irlande veut contribuer à atténuer la pénurie mondiale de puces
Face à l’urgence écologique, l’IT doit faire sa révolution
D’ici 2030, jusqu’à 90 % du code pourrait être écrit par l’IA, pour les jeunes développeurs, l’aventure ne fait que commencer
À la une de la chaîne Tech
- CES 2026 : l’IA physique et la robotique redéfinissent le futur
- Les 3 prédictions 2026 pour Java
- Semi-conducteurs : comment l’Irlande veut contribuer à atténuer la pénurie mondiale de puces
- Face à l’urgence écologique, l’IT doit faire sa révolution
- D’ici 2030, jusqu’à 90 % du code pourrait être écrit par l’IA, pour les jeunes développeurs, l’aventure ne fait que commencer
