Qu'est-ce que les tests logiciels ?
Lorsque j'ai commencé chez JMP il y a plus de dix ans, si vous m'aviez demandé ce qu'étaient les tests logiciels, j'aurais consulté mon moteur de recherche Web préféré (ou, de nos jours, un assistant LLM en IA) et j'aurais répondu quelque chose du genre : les tests logiciels sont le processus d'évaluation d'une application ou d'un produit logiciel pour garantir qu'il fonctionne comme prévu et répond aux exigences des utilisateurs.
Cependant, au fil de nombreuses discussions avec mon collègue Joseph Morgan, j'ai adopté une définition de l'ingénierie logicielle, succinctement énoncée par Glenford Myers [1] :
« Les tests sont le processus d’exécution d’un programme dans le but de trouver des erreurs. »
Cette définition est-elle si différente ? Je dirais que oui. Bien que Myers et al. [1] aient beaucoup discuté de ce sujet, pour la plupart des gens, il existe une différence psychologique entre demander à quelqu'un de vérifier que quelque chose fonctionne et essayer de le casser. En adoptant la définition de Myers, un ingénieur de test a son objectif : trouver des erreurs. Non seulement cela fournit une structure, mais en trouvant et en corrigeant ces erreurs (ou comme nous pourrions le penser, les bugs) tôt et de manière réfléchie, le résultat est un logiciel qui fonctionne comme prévu et répond aux exigences des utilisateurs.
Où sont les insectes ?
Si vous êtes toujours d'accord avec moi et que vous êtes à l'aise avec la définition des tests, la question suivante est de savoir par où commencer pour essayer de casser le logiciel. Pour cela, nous pouvons nous tourner vers Boris Beizer [2] :
« Les insectes se cachent dans les coins et se rassemblent aux limites. »
Décomposons cela en deux parties, où nous traiterons une entrée comme une sorte de données ou d'informations que vous donnez au logiciel pour obtenir une réaction ou faire quelque chose avec ces informations.
Les bogues se regroupent aux limites : cela souligne que les bogues se trouvent généralement aux limites de ce que le système est censé gérer. Par exemple, si une fonction est censée accepter des entrées entre 0 et 1, nous devons tester les limites (0 et 1) ainsi que juste à l'extérieur de celles-ci.
Les bugs se cachent dans les recoins : cela suggère que les bugs se cachent souvent dans les parties d'un système qui impliquent plusieurs entrées. Autrement dit, tout comme nous pensons aux interactions, nous ne trouverons pas de bug à moins de tester ces combinaisons.
Où allons-nous à partir d’ici ?
Au cours des prochaines semaines, vous entendrez mes collègues et moi-même aborder différents sujets liés à la validation (est-ce que nous créons le bon produit ?) et aux tests (trouver des bugs, s'assurer que le logiciel fonctionne). Ce qui m'intéresse particulièrement, c'est qu'il existe un lien profond entre les tests et la conception d'expériences (un autre sujet dont j'aime parler).
Que vous développiez vos propres applications, que vous soyez confronté à votre propre défi de test ou que vous soyez simplement intéressé par ce sujet, j'espère que vous continuerez à lire. Des sujets que vous aimeriez voir abordés ? Faites-le nous savoir dans les commentaires !
Et, comme un blog ne semble pas complet sans une image, image du premier « bug informatique », comme celui d'une partie d'une équipe de l'Université de Harvard en 1947 qui comprenait Grace Hopper.
Avec l'aimable autorisation du Naval Surface Warfare Center, Dahlgren, VA., 1988., Premier bug informatique, 1945 , marqué comme domaine public, plus de détails sur Wikimedia Commons
Références.
- G. Myers, C. Sandler et T. Badgett, L'art des tests logiciels, 3e éd. , New Jersey, John Wiley & Sons, Inc, 2011.
- B. Beizer, Techniques de test de logiciels , Van Nostrand Reinhold, Série Sciences et ingénierie électriques/informatiques, 1983
Salut @Ryan_Lekivetz !
Merci pour cette très belle introduction, j'ai hâte d'en savoir plus sur l'utilisation des tableaux de couverture ou d'autres méthodes de localisation de défauts pour tester les logiciels.
