Tribunes

Améliorer la qualité des logiciels par l'audit informel

L'audit informel des activités de test logiciel constitue un premier pas assuré vers une amélioration de la qualité des logiciels.

PublicitéLe test logiciel est l'un des plus importants facteurs de réussite des projets informatiques, quelle que soit leur taille. Délivrer en temps et en heure des systèmes logiciels de qualité, fiables et fidèles aux attentes des maîtrises d'ouvrage et des utilisateurs finaux, ne peut se faire sans un processus de test professionnel.
Pour vérifier la pertinence d'un processus de test existant, ou pour identifier des axes de progrès dans le domaine du test, et ceci dans des délais courts, l'audit informel des activités de test est une action qui permettra, pour un investissement limité, d'obtenir les informations indispensables à la mise en place d'une amélioration.
Cet article s'attachera à présenter ce type d'audit, et proposera des clefs pour comprendre comment le réaliser et en tirer des bénéfices.

Qu'est ce que l'audit informel ?

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 oeuvre 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 ».
S'il n'existe pas de définition de l' « état de l'art du test logiciel », il correspond néanmoins à un ensemble d'éléments.

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 oeuvre.
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 oeuvre. 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 2 et 3 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.

PublicitéEnfin, l'expérience personnelle de l'auditeur et sa connaissance (...)

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 oeil expert. L'expérience personnelle s'acquiert et s'utilise mais ne se transmet pas. 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 oeuvre 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 ; par exemple ê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 oeuvre chez un sous-traitant ou un fournisseur.

Comment la mise en oeuvre 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 oeuvre à 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 oeuvre 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 oeuvre 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 oeuvre de l'état de l'art du test dans l'entreprise.

Qui rencontrer ?

Qui rencontrer ?

L'audit informel va consister à évaluer la mise en oeuvre 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, loin de là.

Lors de l'audit informel d'un éditeur de logiciel, ici appelé « Devsoft », les profils suivants ont été rencontrés :
·        Responsable des développements logiciels chez Devsoft
·        Responsable de l'équipe de tests pour les produits Devsoft
·        Responsable du Service Qualité
·        Chef de projet face au client principal pour la gamme de logiciels destinés aux entreprises
·        Directeur des Opérations: vente, installation et maintenance des logiciels
·        Chefs de Projet Client sur mySOFT 1 et mySOFT 2 (les deux principaux logiciels développés par Devsoft)
·        Testeurs pour le produit mySOFT 1
·        Chefs de Projet techniques pour mySOFT 1 et mySOFT 2
·        Testeur pour le produit mySOFT 2
·        Clients utilisateurs de mySOFT 1 et mySOFT 2
·        Responsable développement
·        Testeur responsable de l'automatisation
·        Gestionnaire des environnements de test

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'Etat 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

Il peut être intéressant de montrer comment l'état de l'art est couvert par les pratiques de l'entreprise , en affectant une valeur « Pas couvert », « Partiellement couvert » ou « Couvert » à chaque aspect.

L'intérêt de la synthèse ci-dessus est de ne pas se limiter aux éléments spécifiques au test mais au contraire, de prendre en compte d'autres points touchant indirectement au test.

En complément, il est aussi intéressant, même d'une façon très informelle, de montrer à quel niveau de maturité cela correspond, par rapport à un standard comme TMMI. Cela permet de montrer le caractère officiel et incontournable des éléments présentés. Le résultat devra faire passer le même message mais en se limitant au test logiciel tel que vu par le standard.

Passer d'objectifs d'améliorations à un plan d'action concret

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)
-         Revoir l'organisation du test et ses objectifs
Des objectifs d'amélioration Moyen et long terme sont par exemple :
-         Industrialiser les activités
-         Documenter les pratiques
-         Analyser le passé et Améliorer
-         Capitaliser pour réutiliser
-         Mesurer le coût et l'efficacité
-         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 oeuvre du plan d'amélioration des pratiques de test qui devra se l'approprier (compréhension, priorisation) puis le mettre en oeuvre en donnant de la visibilité à tous les services sur l'avancement.
Un autre exemple d'action touchant l'objectif « Automatiser » pourraît ê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 oeuvre.

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.

Article rédigé par

Eric Riou du Cosquer, Trésorier du CFTL (Comité Français des Tests Logiciels)
Eric Riou du Cosquer est Trésorier du CFTL (Comité Français des Tests Logiciels) et Test Manager Senior chez France Télécom

Diplômé de l'Ecole d'Ingénieurs de Brest (Informatique Industrielle), Eric Riou du Cosquer a commencé sa carrière en 2000, en qualité de Chef de Projet au sein des sociétés CSC PeatMarwick, puis Softeam de 2000 à 2003, avant de rejoindre la division R&D de France Télécom, dans le cadre des projets CATI et APSYS. Depuis 2007, Eric exerce en qualité de Consultant et Formateur pour le Centre de Compétences Test de France Télécom (ROSI/DDSI).
Depuis 2002, il a dispensé plusieurs conférences et formations dans le domaine des tests de logiciels. En tant qu'expert, Eric Riou du Cosquer est également membre du groupe de travail international pour la définition du Syllabus Avancé de l'ISTQB, Responsable de la création de la version française et Président du Club utilisateurs de Mercury France.
Il a également participé à la définition et à la mise en oeuvre du processus de qualification de FT division R&D, ainsi qu'à l'audit de l'utilisation des outils de gestion de tests et anomalies sur différents projets, côté fournisseurs.