Un avis ? Un commentaire ?
Cet espace est pour vous.
En 1987, David Gelperin et Bill Hetzel publiaient l’article scientifique The growth of software testing dans la revue Communications of the ACM. Un article dans lequel, regardant en arrière, ils définissaient différents seuils où le métier du test a évolué.
Quel est donc ce découpage temporel ?
Les processus de test ne sont pas traités en tant que tels ; les tests sont effectués de manière ad hoc essentiellement, et les succès ne sont guère reproductibles puisqu’ils dépendent avant tout du bon vouloir et du talent d’individus isolés.
Pour résumer, on teste pour prouver que le logiciel fonctionne.
Ca fait peur, non ? Cela veut dire tout simplement que cette période est marquée par le cliché (toujours vivant) des QA qui sont là pour « tout casser » ! Même si, on le sait, le test logiciel met plutôt en lumière ce qui est déjà cassé.
L’activité de test donne lieu à des métriques. On la suit de manière formelle.
L’objectif principal des tests est d’éviter en premier lieu l’apparition des anomalies, et ce grâce à des méthodes statistiques.
Ce découpage en périodes historiques a fait date ; il est toujours mentionné notamment dans les documents relatifs au modèle TMMi. En effet, les 5 niveaux de maturité TMMi font écho aux 5 époques mentionnées par les auteurs de l’article.
Mais, bien que ce soit fort intéressant, ce n’est pas le sujet le plus croustillant de cet article ! 😃
Une partie un peu moins connue de cet article fait en effet référence à un sondage diffusé à l’occasion de la 4ème conférence internationale sur le test logiciel, qui s’est tenue à Washington en 1987. Préparez-vous à un voyage dans le temps !
Il faut garder à l’esprit que les personnes ayant répondu au sondage participaient à un congrès sur le test logiciel. Elles avaient donc a minima un intérêt pour le sujet. Cet état des lieux représente donc certainement les pratiques des entreprises les plus à la pointe dans le domaine à l’époque !
Tout en reconnaissant que les pratiques de 1987 avaient aussi, potentiellement, des atouts que nous avons peut-être perdu en cours de route, ces résultats de sondage ne sont-ils pas rafraîchissants ?
De retour au XXIème siècle, comment vous sentez-vous après avoir fait ce petit saut dans le passé ?
Et surtout, d’après vous, lesquelles de nos pratiques sembleront désuètes aux QA de 2059, dans 36 ans ?
Le voyage dans le temps n’est pas fini et nous devons continuer de perfectionner nos pratiques ! 😃
Crédit image : Midjourney
Cet espace est pour vous.
Louvrier Romuald says:
Bonjour.
Le point 19 me gène beaucoup. Il sous-entend que tout est spécifié à la lettre avant de coder. Mon expérience, auparavant en tant que développeur, désormais en tant que testeur, est que le développement est une activité de l’invisible. Le développeur passe son temps à tomber sur des imprévus, et une spécification exhaustive sera forcément fausse.
Par conséquent, « écrire le test avant le développement », ça sous-entend que le livrable sera tel qu’imaginé au départ. Ce qui est fort rare. Ca me parait, par conséquent, illusoire et couteux, pour un gain méthodologique qui reste à prouver. Une approche adaptative, qui gère les surprises comme faisant partie normale et inhérente du process complet de création du logiciel, permet, contrairement aux apparences, de bien mieux maitriser ce qui se passe. C’est d’ailleurs en partie la logique derrière les cycles courts des méthodes à Gilles.
Le point le plus important et qui me parait le plus négligé de nos jours est le point 15. Le cout des tests n’est pas mesuré, pas maitrisé, et donc pas piloté par le management qui n’est donc pas en mesure de décider, et encore moins d’implémenter, un pilotage de l’effort de test.
hightest says:
Bonjour Romuald,
Ce sondage donne beaucoup de grain à moudre ! Merci d’apporter votre retour en tant que « devsteur » 😉 Vous avez eu la possibilité de voir les situations depuis deux points de vue qui ne se comprennent pas toujours à 100 %, et c’est d’autant plus intéressant.
Pour le point 19, la formulation est assez ambiguë. Certains tests ou tous les tests ? Des scénarios complets ou de simples points à vérifier ? Et puis, quels types de tests ? Il serait anachronique d’entendre « tests unitaires », pourtant de nos jours le point 19 pourrait être une mesure de qualité (avec une implémentation fructueuse du TDD).
En contexte agile, il est toujours intéressant d’avoir au moins une liste minimale de tests d’acceptance qui permettent de se mettre d’accord en amont du développement, sans que cela veuille dire que tout est écrit et prévu au millimètre.
Le point 6 est d’ailleurs tout autant ambivalent quand on lit ces mots en 2023. Séparer le test du développement, alors qu’on tend à intégrer de plus en plus le test à chaque étape des projets, ne sonne pas comme une bonne pratique si on entend « monter des équipes de test bien séparées des autres » ou « consacrer une phase bien distincte pour les tests, après le développement ». Mais si on entend ça comme une séparation conceptuelle (porter une attention particulière au test, lui consacrer des moyens dédiés, etc), c’est tout de suite + pertinent.
Bonne journée,
L’équipe Hightest