Pour vérifier la pertinence d’un processus de test existant, l’audit informel permet d’obtenir des informations indispensables à la mise en place d’une amélioration. Comment procéder ?
A la différence d’un audit formel, basé sur un modèle et des pratiques formalisés, CMMI par exemple, l’audit informel est plus souple à mettre en œuvre et se basera, non pas sur un modèle mais plutôt sur l’« état de l’art du test logiciel », appliqué par un expert reconnu à un « contexte particulier », sur un « périmètre précis » et avec des « objectifs spécifiques ». Des normes et standards apportent des éléments précis sur le test logiciel.
On peut citer par exemple, les normes IEEE 830 sur la gestion des exigences, IEEE 829 sur la documentation des tests, IEEE 1028 sur les revues logicielles, IEEE 1044 sur la classification des anomalies ou encore l’ISO 25000 sur la qualité des produits logiciels. Même sans être appliquées à la lettre, elles apportent une meilleure connaissance des activités de test et offrent des outils, comme des modèles de documents, permettant de professionnaliser leur mise en œuvre.
Des modèles d’évaluation de la maturité des entreprises sur différents aspects du développement logiciel et du test permettent d’identifier les principales composantes d’un test logiciel efficace et de mesurer leur mise en œuvre. Lors d’un audit informel ce n’est qu’une partie du contenu des modèles qui est exploitée et le processus de conduite d’audit selon le modèle n’est pas suivi. Considérer CMMI (www.sei.cmu.edu/cmmi) et ses domaines de processus vérification et validation, ou encore les niveaux deux et trois de TMMI (www.tmmifoundation.org) permet de couvrir en grande partie les bases du test logiciel.
Des organismes de définition et certification des compétences des métiers du test apportent, en plus d’une vue détaillée sur les différentes pratiques, des moyens d’évaluer les compétences des personnes. L’ISTQB et le CFTL sont, à l’étranger et en France, incontournables. Le contenu de ces programmes de certification alimente l’état de l’art du test.
Enfin, l’expérience personnelle de l’auditeur et sa connaissance de nombreux retours d’expérience sont de précieux éléments qui vont lui permettre d’apprécier chaque situation avec un œil expert. Les retours d’expériences peuvent être partagés par le biais d’associations telles le club utilisateur mercury ECUME (www.lecume.org) ou encore le comité technique du CFTL, qui réunissent des responsables en test logiciel opérant dans différents types de sociétés.
L’audit peut se dérouler dans différents « contextes » et « périmètres » différenciés principalement par la maturité des activités de test, par l’efficacité de leur mise en œuvre et par les acteurs impliqués. Le contexte d’un audit peut être celui d’une entreprise qui souhaite professionnaliser ses activités de test, celui d’un projet qui se prépare à démarrer, celui d’un projet en cours, celui d’une partie d’un projet localisée chez un sous-traitant, celui d’un fournisseur de logiciel ou encore celui d’un vaste projet informatique faisant intervenir différentes sociétés dans différents pays.
Plusieurs objectifs peuvent conduire un chef de projet ou une direction informatique à organiser un audit : être rassuré sur la maturité des activités de test de l’entreprise, évaluer les activités de test sur un projet particulier ou encore évaluer et contrôler les compétences en test mise en œuvre chez un sous-traitant ou un fournisseur.
Comment la mise en œuvre de l’état de l’art du test se concrétise-t-elle ?
L’ensemble des éléments constitutifs de l’état de l’art du test vont se décliner sur différents aspects dans l’entreprise qu’il conviendra d’appréhender durant l’audit. L’organisation de l’entreprise et la coopération entre les différents acteurs ou services doivent permettre et faciliter des interactions entre différents profils d’acteurs afin d’anticiper au maximum ce qui peut l’être.
Par exemple, des architectes techniques ou fonctionnels pourront être impliqués tôt dans des revues de spécifications d’exigences ou de dossier de conception. Une documentation précise mais strictement limitée à ce qui est utile doit permettre de : présenter les objectifs définis pour le test, décrire une façon de faire commune, décrire ce qui est fait sur chaque projet, donner de la visibilité sur l’avancement, capitaliser, réutiliser, s’améliorer.
Différentes mesures sont nécessaires pour évaluer les coûts des tests, coûts permanents et coûts récurrents mais également pour mesurer la progression des activités de test et la qualité des produits ou systèmes testés. Ces mesures, comparées à des objectifs ou KPI sont nécessaires au pilotage d’un projet de test ou d’une entité chargée d’accomplir une ou plusieurs activités de tests.
Différentes activités de test doivent être mises en œuvre à plusieurs niveaux. Par exemple, l’activité d’exécution de tests au niveau intégration doit être précédée par des activités d’analyse et de conception de ces tests. Des environnements et données de tests doivent être gérés pour permettre l’exécution et la réexécution de tests dans un environnement précisément identifié. Les personnes impliquées directement dans le test doivent maîtriser des méthodes et compétences spécifiques au test.
Un test manager doit par exemple maîtriser la gestion des risques liés au test alors qu’un analyste de test doit maîtriser différentes techniques de conception des tests. Des outils et logiciels de test sont absolument nécessaires pour mettre en œuvre efficacement le processus de test ; notamment des outils de gestion des exigences, tests et anomalies. Des processus connexes comme la gestion de projet, la gestion de configuration ou encore la gestion des exigences devront être correctement mis en œuvre et interfacés avec le processus de test.
Enfin, un soutien fort et visible de la hiérarchie est un prérequis indispensable au bon déroulement des activités de test. Le point de vue des décideurs ou « sponsors » de projets dans l’entreprise et leur investissement pour promouvoir et soutenir les activités de test sont donc également des aspects correspondant à la mise en œuvre de l’état de l’art du test dans l’entreprise.
Qui rencontrer ?
L’audit informel va consister à évaluer la mise en œuvre des éléments identifiés ci-dessus en interrogeant différentes personnes de l’entreprise pour recueillir leurs explications mais aussi des preuves et démonstrations. Les acteurs ayant un rôle particulier à jouer dans le test sont nombreux et l’audit ne se limitera pas aux testeurs.
Lors de l’audit informel d’un éditeur de logiciel, ici appelé « Devsoft », les profils suivants ont été rencontrés : un responsable des développements logiciels, un responsable de l’équipe de tests, un responsable du service qualité, un chef de projet face au client principal pour la gamme de logiciels destinés aux entreprises, un directeur des opérations vente etc…
Comment présenter un rapport d’audit informel ?
Le rapport d’audit, même informel, ne devra contenir que des éléments justifiables, soit par des propos recueillis lors des entretiens, soit par des pratiques constatées sur le terrain, soit par des documents recueillis. Un plan classique peut être : rappel de l’objectif de l’audit ; précautions et mise en garde ; liste des personnes rencontrées avec leurs rôles ; rappel sur ce qu’est l’état de l’art du test logiciel et comment il se met en application ; les bonnes pratiques identifiées ; les axes d’amélioration identifiés.
Passer d’objectifs d’améliorations à un plan d’action concret
A partir des résultats de l’audit, il est possible d’identifier des objectifs d’amélioration et des actions associées, ce qui permet de bâtir un plan d’action concret. Des objectifs d’amélioration « court et moyen terme » sont par exemple : stabiliser les bonnes pratiques existantes sur un projet puis les généraliser ; introduire de nouvelles pratiques sur des projets pilotes puis les généraliser ; introduire sur l’ensemble des projets, avec un soutien, des améliorations simples et rapidement rentables (Gestion des tests, Reporting, Pilotage transverse, Coopération entre les acteurs) ; analyser le passé et améliorer ; capitaliser pour réutiliser ; mesurer le coût et l’efficacité et automatiser.
En face de chaque objectif, une ou plusieurs actions sont identifiées, ce qui permet d’obtenir un plan d’actions précis. La première action, à mettre en face de l’objectif « industrialiser les activités » sera sans doute d’identifier un responsable de la mise en œuvre du plan d’amélioration des pratiques de test qui devra se l’approprier (compréhension, priorisation) puis le mettre en œuvre en donnant de la visibilité à tous les services sur l’avancement.
Un autre exemple d’action touchant l’objectif « automatiser » pourrait être d’identifier les outils d’exécution de test unitaire à utiliser pendant le développement, de les présenter aux équipes de développement avec des recommandations d’usage et un support pour la mise en œuvre. A partir d’un « état de l’art du test logiciel », un expert en test pourra conduire un audit qui, même informel, débouchera sur un plan d’actions d’amélioration concret.
Cela permettra incontestablement à l’entreprise ou au projet de s’améliorer efficacement et ceci, pour un coût initial peu élevé. Néanmoins, pour professionnaliser cette amélioration, pour mieux la piloter et pour viser des objectifs mesurables et affichables, il est souvent intéressant, après une première phase d’amélioration, de faire conduire un audit plus formel respectant un modèle d’amélioration de processus comme TMMI.
Cet article a été écrit par Eric Riou du Cosquer (Comité Français des Tests Logiciels).