L'audit informel des activités de test logiciel, un premier pas assuré vers une amélioration de la qualité des logiciels
Le test logiciel est l’un des plus importants facteurs de réussite des projets informatiques. Délivrer en temps et en heure des systèmes logiciels fiables et fidèles aux attentes des maîtrises d’ouvrage et des utilisateurs, exige un processus de test professionnel.
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.
Cette chronique 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 œ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 ».
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 œ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 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.
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. 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 œ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 ; 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 œ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, 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’é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.
Il
peut être intéressant de montrer, comme dans l’exemple ci-dessous, 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 :
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
œ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 » 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 œuvre.
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.
|
|