Le développement piloté par les tests (Par François Darphin, Sogeti)
A l'exception d'Agile, tous les processus de développement débutent par la rédaction de spécifications (techniques et fonctionnelles). L'objectif est double : d'une part, décrire l'application, et d'autre part disposer d'un support permettant aux équipes (métier, développement, d'architectes, exploitation et maintenance) de communiquer.
Une spécification reste toujours interprétable
Chacun sait qu'il faut écrire des spécifications exhaustives et non interprétables, et pourtant cela laisse toujours autant de difficultés en intégration et en production. A cela plusieurs raisons :
L'absence de référentiels à jour qui permettent de partir d'un existant stable (souvent les spécifications ne concernent que les nouvelles parties d'une application) et maîtrisé (et de partager vocabulaire et contextes souvent implicites). Et même avec ces outils, une spécification reste toujours interprétable, du simple fait de l'écart de culture entre les équipes. Même lorsqu'elles sont toutes internes, du même pays et pratiquent la même langue. Externalisation et offshorisation empirent les risques de déception...
Le manque d'anticipation de deux critères déterminants : la faisabilité et la testabilité. La faisabilité comprend l'impact sur les architectures (techniques et fonctionnelles) et les contraintes d'intégration avec l'existant. La testabilité comprend l'impact sur les moyens de tests à mettre en œuvre, à commencer par la possibilité décrire des scénarios et de disposer des outils de simulation, de bouchonnage et des données.
Une description souvent limitée aux règles de gestion, aux processus et aux cycles de vie des données en oubliant les procédures et les cas d'usage de l'application. Ces deux types de description sont pourtant déterminants à l'écriture des scénarii de tests permettant de vérifier l'efficience (adaptation à l'utilisateur) et le cycle de vie de l'application (c'est-à-dire toutes les situations dans lesquelles elle va se trouver) : à commencer par son intégration avec un palier pour constituer une version en production ; mais aussi son lancement, son arrêt, ses situations non nominales, et les comportements types des utilisateurs internes ou externes.
Les besoins évoluent rapidement, ce qui suppose la possibilité de changer les spécifications pendant le processus de développement, au risque de ne plus converger vers une version stable.
Paralléliser avec le processus de développement le test et l'intégration
La solution consiste à paralléliser avec le processus de développement un processus de test et un processus d'intégration, tous deux continus.
Les méthodes Agile proposent de piloter les développements par les tests
Le processus d'intégration fournit au projet un pallier stable et aux limites connues (dont les anomalies) qui complétés de l'environnement de développement permet de fiabiliser dès le départ les développements.
Les modules de l'application sont intégrés entre eux par pallier au fur et à mesure, ce qui offre la possibilité d'avoir en permanence une vision bout en bout. Une phase d'intégration finale permet d'intégrer les applications entres elles et de réconcilier les écarts de paliers vis-à-vis de la mise en production. En usage avancé, il est possible d'utiliser la notion d'"intégrat" comme containers de modules dont les comportements nominaux et non nominaux sont connus et réutilisables pour faciliter l'assemblage de l'application et/ou de la version.
Le processus de test permet d'anticiper la testabilité et la vérification du système (et des différentes applications qui le composent). Des scénarii de description des modes opératoires et des cas d'usage sont suffisants aux vérifications d'intégration de type boites noires ; ce qui fait gagner beaucoup de temps vis-à-vis de l'utilisation des autres types de scénarii cités plus tôt. D'ailleurs, les logiciels écrits à partir de leurs cas d'usage sont plus fidèles et de meilleures qualités que lorsque les tests sont écrits à posteriori à partir des spécifications. La raison est simple : les tests ne sont pas interprétables, car ils sont écrits pour répondre par oui ou par non à une vérification !
Les méthodes Agile proposent de piloter les développements par les tests, en écrivant d'abord les essais à réussir à chaque itération. Anticipée et utilisée comme condition de fin de phase, la conformité du logiciel est garantie par construction. Bien entendu le processus d'intégration continu est ici déterminant pour assembler les différentes itérations, mais aussi pour pouvoir non régresser au fur et à mesure. Notons pour finir qu'Agile permet par la structure d'équipes composées de toutes les parties prenantes, beaucoup plus d'échanges et de compréhension de ce que doit faire le logiciel (tout en apportant la richesse des points de vue de chacun).
L'absence de spécifications ne nuit pas à la maintenabilité grâce aux capitalisations dans les référentiels, en particulier de tests.
François Darphin est National practice manager testing au sein de la société de services Sogeti