Ça sent la question des devoirs.
Des tests dans le domaine du logiciel sont-ils nécessaires?
Oui. Absolument. À tous les niveaux. En dehors de quelques domaines spécialisés, nous ne sommes pas encore à un stade où nous pouvons prouver mathématiquement que notre code est correct face à des bugs spécifiques (du moins pas dans un délai raisonnable). où ça casse.
Si nous créons un logiciel avec beaucoup de soin, alors pourquoi devrions-nous tester?
Les tests ne consistent pas uniquement à rechercher des erreurs de codage. Vous devez également vous assurer que vous répondez à toutes vos exigences et que l'ensemble du système fonctionne comme prévu. Si j'ai l'obligation de renvoyer un code d'erreur spécifique à une transaction ayant échoué, je dois alors écrire un test pour vérifier à la fois que la fonctionnalité existe et qu'elle fonctionne correctement.
Et tout cela suppose que la spécification et la conception sont complètes, correctes et cohérentes en interne, ce qui n’est souvent pas le cas. Même si vous respectez les spécifications à la lettre et suivez la conception jusqu'au dernier point et point-virgule, si la spécification ou la conception est incorrecte, des problèmes se poseront au moment de l'intégration. Souvent, les tests de système ou d'intégration consistent à découvrir que la spécification elle-même est erronée et doit être révisée (voir récit de guerre ci-dessous).
Après les tests, pouvons-nous être sûrs que nous avons atteint cet objectif (le produit / logiciel fonctionne comme prévu) car nous en avons fait les tests? C'est possible?
Non, pas à 100%. Nous ne pouvons pas tester toutes les combinaisons possibles d'entrées ou de chemins d'exécution dans un code autre que le plus simple. Nous ne pouvons pas prendre en compte tous les facteurs environnementaux. Nous ne pouvons pas imaginer tous les modes de défaillance possibles.
Nous pouvons tester à un point où nous sommes raisonnablement sûrs qu'il n'y a pas de gros problème. Encore une fois, c’est pourquoi nous devons tester à tous les niveaux. Ecrivez une suite de tests pour vous assurer que votre code gère correctement les conditions de bord (mauvaise entrée, résultats inattendus, exceptions, etc.). Test unitaire pour vérifier que votre code répond à ses exigences. Test du système pour vérifier le traitement de bout en bout. Test d'intégration pour vérifier que tous les composants se parlent correctement. Faites des tests d'utilisabilité pour vous assurer que tout fonctionne de manière à ce que les clients ne veuillent pas vous tirer dessus.
Scénario réaliste: je travaillais sur un système dorsal qui envoyait parfois des mises à jour à un service d'interface graphique pour les afficher dans un tableau à l'écran. Au cours du projet, un filtre a été ajouté à l'affichage (par exemple, l'opérateur peut choisir d'afficher un sous-ensemble des entrées de la table). Erreur de conception n ° 1 - le filtrage aurait dû être effectué par le service d'interface graphique (j'ai cette notion pittoresque et antiquaire selon laquelle les fonctions de gestion d'affichage devraient être la responsabilité du logiciel de gestion d'affichage), mais en raison de la politique et de mon incapacité à reconnaître les problèmes avant qu'ils ne deviennent problèmes , cette exigence a été mis sur le service de back-end. Bon, d'accord, pas de problème, je peux le faire. Si l'état du filtre change, je reçois un message, puis j'envoie un message de création ou de suppression pourchaque ligne du tableau , car c’est ainsi que fonctionne l’interface (erreur de conception n ° 2 - il n’ya aucun moyen d’envoyer des mises à jour à plusieurs lignes dans un seul message; nous ne pouvions même pas envoyer un seul message "effacer" ou "supprimer" pour effacer la table entière).
Eh bien, tout fonctionne bien pendant le développement; Les tests d'unité, de système et d'intégration montrent que j'envoie les bonnes informations et que je gère correctement les modifications du filtre. Ensuite , nous arrivons à des tests d'utilisation, et la chose tombe dur , car le volume de données a été écrasante. La latence du réseau entre mon service principal et l'interface graphique était de l'ordre de 0,15 à 0,25 seconde. Pas mal si vous devez seulement envoyer des mises à jour pour une douzaine de lignes ou plus. Mortel lorsque vous devez envoyer des mises à jour pour plusieurs centaines. Nous avons commencé à recevoir des rapports de bugs indiquant que l'interface graphique se figeait après la modification de l'état du filtre. eh bien, non, ce qui se passait, c’était que cela prenait de l’ordre de plusieurs minutes mettre à jour l’affichage, car le protocole de message mis au point avec une logique à la fois ne pouvait pas gérer un scénario réel.
Notez que tout cela aurait pu et aurait dû être anticipé par tout le monde, du contractant principal au plus vieux, si nous avions pris la peine de faire l’analyse la plus élémentaire à l’avance. La seule défense que je puisse offrir est que nous clôturions la deuxième année d'un projet de six mois qui devait être mis en pièces presque immédiatement après l'accouchement, et nous étions tous désespérés de le voir.
Ce qui nous amène à la dernière raison de tester - CYA. Les projets du monde réel échouent pour diverses raisons, notamment politiques, et tout le monde n'agit pas de bonne foi lorsque les choses tournent mal. Les doigts sont pointés, les accusations sont portées et, à la fin de la journée, vous devez être capable de pointer sur un enregistrement montrant qu'au moins vos données fonctionnent comme prévu .
If we create a software with care in during its development period then why should we go for Test?
- Parce que de toute façon, même le programmeur le plus qualifié fait des erreurs.