Le modèle en V n’est pas le cycle en cascade Pour certaines équipes de développement, le Lean IT, l’Agilité sont de nouvelles méthodes de développement liées aux nouveaux langages de programmation. Le modèle en V est lui souvent vu comme un cycle en cascade. Pourtant ce modèle en V précise simplement qu’à des phases de conception correspondent des phases de test. Et c’est ce que rappelle le syllabus CFTL/ISTQB niveau Fondation, les niveaux de test existent quels que soient les cycles de développement.

Lorsque l’on met en place l’agilité, avec SCRUM le plus souvent, les niveaux, besoins utilisateur, conception et codage existent, et doivent donc être testés. Si pour certains l’Agilité est synonyme de liberté, la qualité logicielle ne pourra être atteinte que si les tests sont correctement réalisés. Les évolutions seront testées de manière exploratoire, en sessions avec ou sans charte de test, les résultats plus ou moins documentés, la régression devra être vérifiée à chaque cycle ou sprint.

Agilité signifie beaucoup tester

Pour cela l’activité de tests devra être automatisée avec des automates. La rentabilité de cette automatisation est vite rencontrée vu le nombre de fois où elle sera effectuée. Le risque est que trop de fonctions soient automatisées en régression. Il est nécessaire de bien réfléchir si les tests exploratoires des évolutions sont directement automatisés ou bien si les tests de non régression doivent être conçus différemment des tests manuels des évolutions. Si trop de tests sont à passer, il faudra du temps au robot pour les exécuter, de plus l’analyse des logs prendra du temps. Dans le cadre de l’intégration continue, le problème se pose rapidement chez ceux qui lancent tous les soirs les tests unitaires du Développement piloté par les tests, les analyses de code, les tests fonctionnels de régression automatisés. Faut-il attendre d’être pied au mur pour faire cette analyse et de concevoir des tests de régression optimisés ? Le temps de re-fabrication de ces tests en cas de trop gros volume coûtera plus cher qu’un plan de test de régression conçu au départ pour obtenir la meilleure couverture possible des fonctions critiques, avec le risque que l’impasse soit faite sur certains tests pour gagner du temps. Donc Agilité signifie en plus de réactivité, réflexion et beaucoup de tests. L’Agilité enrichi le métier de testeur puisqu’elle lui apporte des activités d’automatisation, d’analyse du risque, d’analyse de la couverture des risques et exigences par les tests.

Les syllabus CFTL/ISTQB sont Lean.

Le Lean IT apporte au testeur de nouvelles activités comme le découpage en petites tâches des activités de test et l’analyse de la valeur afin d’éliminer les pertes. Le principe fondamental « Les tests exhaustifs ne sont pas possible » se voit ici pleinement appliqué.

Tout comme la nécessité de réaliser des tests de caractéristiques non fonctionnelles. Le Lean IT mesure la réponse aux attentes explicites et implicites des clients IT. De base les fonctionnalités sont testées, et également l’utilisabilité, l’ergonomie de l’application, ses performances. Un des principes du Lean IT est d’optimiser les temps de traitement et la disponibilité du système. Dès lors la conception et l’exécution de tests opérationnels en exploitation devient incontournable. La valeur ajoutée des activités devant être mesurée, l’activité de tests commence bien au début du projet où il faudra budgéter les tests, et continue en production avec un contrôle des dépenses au long du processus.

A la fin le principe d’amélioration continue permettra d’identifier ce qui cause des pertes dans le processus. Dès lors, l’analyse de la criticité des applications et des fonctions, ou encore le principe du regroupement des défauts s’appliquera. Les principes, méthodes développées dans les syllabus CFTL/ISTQB sont Lean et peuvent s’appliquer soit dans une démarche Lean, soit indépendamment. Former des testeurs et les faire certifier est donc Lean. De même si ITIL est une démarche Lean pour l’exploitation informatique, alors faire certifier des testeurs entre également dans une démarche ITIL.