L’évolution de la définition du test au fil des années

Cet article est la traduction de l’original « The history of the definition of testing« , rédigé par Rik Marselis à propos l’histoire de la définition du test.

Aujourd’hui, les équipes de livraison informatique sont convaincues que la qualité est un objectif très important. Au cours des dernières décennies, l’ingénierie de la qualité a évolué à partir de l’activité de test et a surmonté ces limites.

Cette évolution se reflète dans le changement des définitions du test au fil des années. Dans ce blog, vous allez explorer les différentes définitions et vous verrez notre brève analyse de cette évolution.

La première définition du test que je connaisse se trouve dans le livre « The art of software testing » de Glenford Myers qui a été publié en 1979.

Il définit:

“Le test est le processus d’exécution d’un programme dans le but de trouver des erreurs.”

L’idée à l’époque était: trouver les erreurs, résoudre les problèmes pour avoir un logiciel parfait. Mais dans les années 1980, les logiciels sont rapidement devenus si complexes qu’il est devenu évident que cette approche n’était pas réalisable.

Le premier livre de la série TMAP, “Tester selon TMap” (1995) a visé à faire du test un processus structuré et a introduit cette définition :

“Le test est un processus de planification, de préparation et de mesure, visant à établir les caractéristiques d’un système d’information en démontrant la différence entre le statut actuel et le statut demandé.”

L’idée était: un système d’information n’est jamais exactement identique à ce qui était demandé, nous allons l’examiner et dire où il ne correspond pas, afin que quelqu’un puisse le réparer.

Avec cette définition, le focus est toujours mis sur le fait que les systèmes informatiques ont des problèmes qui doivent être résolus.

Au début des années deux milles, deux nouvelles définitions du test ont été publiées, l’une dans le livre TMap NEXT et l’autre dans le glossaire ISTQB.

Le livre « TMap NEXT – pilotage des projets par le test» définit en 2006 :

“Le test est un processus qui donne de la visibilité, des recommandations sur la qualité et les risques associés.”

Bref, pour décider si vous souhaitez commencer l’utilisation d’un produit, vous vous référez directement à la qualité et aux risques liés. D’ailleurs, dans cette définition apparente, le produit peut être autre chose, il n’est pas forcément limité aux produits informatiques. 

Le focus est désormais sur la mesure de la qualité afin de fournir des informations précieuses.

En 2007, l’ISTQB a publié la définition suivante, qui reste inchangée à ce jour :

“Le test est le Processus consistant en toutes les activités du cycle de vie, statiques et dynamiques, concernant la planification et l’évaluation de produits logiciels et produits liés pour déterminer s’ils satisfont aux exigences et démontrer qu’ils sont conformes aux objectifs et détecter des anomalies.”

Dans cette très longue définition, le point de départ est que l’objet de test est bon, (« démontrer qu’ils sont adaptés à l’emploi »), mais à la fin, cette définition indique toujours que le test recherche les défauts (tout comme Glenford Myers l’a déjà mentionné dans sa définition).

Malheureusement, l’ISTQB n’a aucune référence directe à la qualité. Mais ils font référence à la fois à la vérification (satisfaire aux exigences spécifiées) et à la validation (adapté à l’usage).

Le 17 mars 2020, nous avons lancé le livre le plus récent de la série TMAP, intitulé “Quality for DevOps teams”. Dans ce livre, la définition du test est:

“Le test consiste en des activités de vérification, de validation et d’exploration qui fournissent des informations sur la qualité et les risques associés, dans le but d’établir le niveau de confiance qu’un objet de test sera capable de fournir la valeur business recherchée.“

Cette définition comporte de nombreux éléments des définitions précédentes, elle est le résultat d’une évolution. La nouveauté est l’extension avec l’exploration (principalement pour explorer des comportements inattendus et des possibilités imprévues). Une autre nouveauté est l’accent mis sur l’information fournie aux parties prenantes afin qu’elles puissent établir leur confiance dans la valeur business, car nous prenons la valeur business recherchée comme point de départ pour le test.

Cette définition vise également à véhiculer l’idée qu’une qualité parfois médiocre au bon moment est mieux pour générer de la valeur business que d’avoir la meilleure qualité trop tard.

Au fil des années, nous avons constaté que le test (et dans un sens plus large l’ingénierie de la qualité) a commencé par “rechercher les défauts et les corriger” pour arriver à “déterminer s’il est suffisamment bon pour générer de la valeur business”.

Bonne chance et amusez-vous en testant !!

Rik Marselis et Emna Ayadi

Rik Marselis consultant qualité principal chez Sogeti aux Pays-Bas. Il a aidé de nombreuses organisations à améliorer leurs processus informatiques, à établir leur approche qualité et tests, à mettre en place leur organisation qualité et tests, et il a agi en tant que coach qualité, consultant qualité, responsable des tests et superviseur qualité. Rik utilise ses plus de 40 ans d’expérience dans le développement, la qualité et les tests de systèmes pour apporter des solutions adaptées à l’usage à nos clients. Il se concentre sur trois missions principales : * Conseil en Ingénierie Qualité & Tests au sens large (politique qualité & tests, démarrage de projet, amélioration des processus, coaching, contre-avis, etc…) * Développer et donner des cours de formation pour débutants et confirmés testeurs (Rik est formateur accrédité pour les formations certifiantes TMAP, TPI et ISTQB) * Recherche et développement du métier de l’ingénierie qualité et des tests. Rik a contribué à plus de 20 livres sur la qualité et les tests, dont 5 en tant qu’auteur principal et 5 en tant que chef de projet. Son livre le plus récent dans le corpus de connaissances TMAP est “Quality for DevOps teams”. Rik est un conférencier d’honeur et animateur d’ateliers très apprécié lors de conférences (il a présenté lors de conférences dans plus de 15 pays).

Emna Ayadi consltante testing chez Sogeti France. Elle a six ans d’expérience dans différents projets combinées entre des rôles de test et de coaching, elle utilise le concept de gamification et le lie avec les tests lors de l’animation des ateliers. Emna organise des meetups au sein de la communauté Ministry of testing. Elle a contribué à des livres de tests dont la réalisation du « 21st century skills for testers » et la traduction du livre « Agile Testing Consensed » en Français. Son blog emnaayadi.com, où elle partage ses actualités.

Références

https://www.tmap.net