Pour mettre en place les tests dans un processus d’intégration continue il faut mettre en place une campagne solide de test vitaux (ou test d’admissibilité). Je parle ici de campagne de tests vitaux pour plusieurs raisons :
· La couverture de test est faible car les limitations en temps sont fortes
· Les tests sont très régulièrement exécutés (chaque fusion de branche)
· Les changements sont en théorie minimes
Voici les étapes de mise en place des campagnes de tests vitaux que je propose dans le cadre de l’intégration continue :
Je tiens à préciser que c’est un processus que j’ai déjà mis en place lors d’une mission. Des tests étaient déjà en place mais pas intégré au processus d’intégration continue. Le processus peut donc s’appliquer à des solutions d’intégration continue déjà en place même si dans l’idéal il est toujours mieux d’implémenter les tests et le processus d’intégration continue en même temps.
1. Convaincre l’équipe du besoin de ces tests
L’étape la plus importante pour l’implémentation d’une campagne de tests vitaux est de convaincre de sa nécessité.
Pour cela il faut insister sur :
– La pertinence de ces tests
– La détection rapide de bugs majeurs et donc un coût de correction faible
– Aucun nouveaux cas (sélectionné parmi les cas déjà existant)
– Exécution rapide (l’argument qui a le mieux fonctionné vis-à-vis des développeurs)
– Pas en concurrence avec les autres campagnes
– Ce sont les tests à exécuter si on veut implémenter du déploiement continu
2. Se contraindre aux caractéristiques d’une campagne de tests vitaux
Une campagne de tests vitaux doit pouvoir être exécutée très régulièrement et ne remonter que des informations « vitale » pour l’application c’est pourquoi chaque campagne de tests vitaux doit :
– Durer moins de 15 minutes pour l’ensemble des tests (fonctionnels ou non)
– Être exécutée à chaque déploiement sur n’importe quel environnement
– Un cas en échec revient à un bug majeur (ou critique) sur l’application, cela bloque tout processus de fusion
– Ces cas sont exécutés automatiquement au minimum à chaque fusion de branche.
3. Faire une sélection appropriée des tests fonctionnels
Peut-être la partie la plus délicate.
A noter : On commence par les tests fonctionnels pour deux raisons. La principale c’est que les tests fonctionnels sont les plus visibles d’un point de vue client. La seconde est plus pragmatique, ce sont les tests fonctionnels qui sont les plus facilement mis en place et acceptés par les équipes de développement (car des tests de régression sont généralement déjà existant et leurs plus-value et plus simple à mettre en avant).
Une campagne de tests vitaux doit couvrir toutes les fonctionnalités principales d’une application et donc au moins 1 cas de test par fonctionnalité principale. Il est évidemment possible d’avoir plusieurs cas de test pour une fonctionnalité vitale.. L’idée est de toujours rester dans le cadre d’une campagne de tests vitaux exprimé au point précédent.
La sélection doit être faite à partir des tests de régressions qui doivent être hiérarchisés. La hiérarchisation se fait à partir :
– Des métriques si elles existent
– Des demandes marketing
– Des prévisions d’utilisation
4. Automatiser obligatoirement les tests sélectionnés s’ils ne le sont pas encore
La campagne de tests vitaux est exécutée très régulièrement (idéalement plusieurs fois par jour). Il est donc nécessaire d’automatiser ces tests, sinon ils ne seront pas (ou mal) exécutés car demanderont trop de temps aux personnes chargées de les exécuter.
5. Ajouter de la campagne au processus d’intégration continue
Après avoir sélectionné les tests vitaux fonctionnels et les avoir automatisés il faut les ajouter au processus d’intégration continu : ils doivent être exécutés automatiquement à chaque merge de code et un bilan remontant les résultats des tests doit être envoyé au minium à la personne ayant enclenchée le processus.
Une régression d’un des cas de test vitaux doit annuler le déploiement et être fixé avant toute autre action par les développeurs. Une fois la correction réalisée, il est préférable de relance une campagne de tests avant de redéployer notre environnement cible.
6. Mettre en place des bilans générés et envoyés automatiquement à la fin de chaque exécution.
Exécuter les tests régulièrement est indispensable, par contre si aucune analyse ni bilans ne sont ajoutés suite à cette exécution alors cette dernière ne sert à rien.
Des bilans automatiques doivent être communiqués après chaque exécution de campagne.
7. Ajouter des tests de sécurité et de performance (adaptés aux contraintes)
L’étape suivante est la mise en place de tests vitaux de sécurité et de performance. Ces tests sont plus compliqués à mettre en place car nécessitent des outils et environnements adéquats. En effet, pour les tests de sécurité un outil comme Fortify est nécessaire et pour les tests de performances (Benchmark) il faut mettre en place les bouchons nécessaires (pour ne pas impacter les environnements des partenaires), et faire des configurations adaptées aux contraintes des tests vitaux.
8. Travailler sur la visibilité de ces tests et processus.
Enfin, après avoir mis en place toutes ces campagnes il faut mettre en valeur ces processus et communiquer dessus.
Pour cela différents indicateurs peuvent être utiles soit pour l’équipe avec des indicateurs opérationnels soit pour le management.
Les bilans doivent également être facilement accessibles à toute personne travaillant sur le projet. L’exécution des tests vitaux fonctionnels doit idéalement être exécutable par toute personne travaillant sur le projet qui aura donc un bilan pour son exécution.
Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !
N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
