Que ce soit la préparation (définition de la stratégie de recette et des plans de test) ou son exécution, une recette consomme beaucoup de ressources. J'ai souvent vu des projets sur des systèmes critiques pour l'entreprise avec des tests de validation qui représentaient 20% de la charge globale du projet. Ainsi il est important d'optimiser les activités de test.
Demandez à votre MOE un rapport d'exécution des tests unitaires et tests d'intégration
En plus de l'application à tester, votre MOE doit vous livrer un rapport d'exécution des tests unitaires et tests d'intégration. De nombreux outils existent pour faciliter le développement et le reporting de tests unitaires. Il peut être très coûteux de mettre en place des tests unitaires pour une application existante, il faut donc y penser dès le commencement du projet et que les charges de développement prennent en compte le temps nécessaire à la réalisation des tests unitaires. Pour cela, la MOA doit être prête à sponsoriser cette surcharge de travail.
Plan de test
Il faut utiliser un outil ou a minima un fichier Excel pour consigner les plans de test et les réutiliser. Cela doit permettre de spécifier le plan de test, planifier les campagnes de test, suivre l'exécution des tests et effectuer un reporting sur l'avancement des tests. Les tests des nouvelles fonctionnalités deviennent ensuite des tests de non régression, et on peut les réutiliser.
Tests fonctionnels automatisésEt pourquoi ne pas aller plus loin et essayer d'automatiser les tests fonctionnels ? Voici un article intéressant vu sur le blog d'Octo Technology : Démarches de tests fonctionnels. Il y est question de deux outils qui permettent d'automatiser les tests fonctionnels et même de documenter les fonctionnalités du système (d'où le terme de "spécifications exécutables") :
Le principe de ces outils est de décrire le plan de test dans un Wiki sous un format semi structuré (des tableaux). Les données composant le jeux d'essai, les fonctionnalités du systèmes, les résultats attendus, tout est décrit dans un Wiki ce qui est censé offrir de la flexibilité pour documenter et une facilité de prise en main qui permet aux MOA d'écrire les scripts de test. Une fois les tests décrits, il suffit d'exécuter le script de test et la page va s'agrémenter de vert ou de rouge en fonction des résultats des tests. Mais ce n'est pas magique, et il faut coder des "Fixtures" afin de faire le lien entre des outils et les applications à tester. Donc il reste une charge de travail non négligeable côté MOE, à faire en plus des tests unitaires "techniques".
Behavior Driven Development
Le Test Driven Development consiste à commencer par écrire des tests qui vont échouer avant même de développer la fonctionnalité. Au delà de cette approche, Dan North a inventé le concept de Behavior Driven Development :
My response is behaviour-driven development (BDD). It has evolved out of established agile practices and is designed to make them more accessible and effective for teams new to agile software delivery. Over time, BDD has grown to encompass the wider picture of agile analysis and automated acceptance testing.
Introducing BDD - DanNorth.net
Cucumber par exemple est un framework qui permet de décrire en langage naturel comment le système devrait se comporter :
Il existe des applications plus riches qui permettent de décrire les Feature et Scenario plus facilement, comme par exemple Lowdown :
Vous pouvez consulter ce billet sur le blog d'Octo Technology : Cucumber pour la MOA pour aller plus loin.
Testeur - Un vrai expertFinalement, on se rend compte que les techniques de test sont aujourd'hui nombreuses et parfois complexes. Le métier de Testeur est donc devenu un métier en lui-même où l'expertise est dure à obtenir. Si votre structure est trop petite pour avoir une équipe dédiée aux tests, alors il ne faut pas hésiter à faire appel à un expert externe pour aider à la mise en place de bonnes pratiques pour une démarche de test qui doit être intégrée à tout le cycle de vie d'un système.
