Les exigences sont essentielles à la qualification

Avant de tester un produit, il est essentiel d’en connaître ses fonctions. En effet, il faut savoir comment un logiciel va être utilisé pour pouvoir définir une bonne stratégie de test. Cette démarche découle d’un constat simple : il est impossible de tout tester. Cela impliquerait en effet des coûts (délais, budgets) trop importants, quelque soit le logiciel testé, car le nombre de configurations possibles est trop important.

Il s’agit alors de faire des choix, et classifier les fonctionnalités les plus importantes à tester.

La manière dont un logiciel va être utilisé peut être défini par ses exigences : elles vont caractériser les spécifications du logiciel. Elles doivent être non ambigües et être testables. Elles sont les pré-requis indispensables aux étapes de conception et de développement d'un produit.

Sur le terrain, pas toujours idéal

Idéalement, les spécifications du logiciel définies lors de la création du logiciel sont explicitées dans un document. L’équipe qualification devrait donc pouvoir débuter sa mission en transformant les spécifications en exigences, puis en concevant les plans de test.

Malheureusement, ce cas idéal est rare. Dans la pratique, l’équipe de qualification se retrouve souvent confrontée à deux situations :

•  Il n’y a pas de documents listant les spécifications

C’est le cas le plus clair : tout est à faire !

Les spécifications ont peut être été définies lors de la conception du logiciel, mais pour des raisons diverses (manque de temps, perte de documents…) elles ne sont pas disponibles pour l’équipe de qualification.

La première étape de la phase de qualification est donc de redéfinir spécifications, puis les exigences. Elles découlent de données variées, que l’équipe de qualification va devoir recouper.

• Les documents listant les spécifications sont inexploitables

La qualification n’étant pas encore considérée comme essentielle au cycle de vie d’un logiciel (et bien à tort…), les documents délivrés à l’équipe qualification sont soit de mauvaise qualité, soit incomplets.

Plusieurs événements peuvent être à l’origine de cette mauvaise qualité. Le chef de projet peut en effet abandonner la mise à jour du document des spécifications fonctionnelles du fait de :

• Le client changeant ses exigences en cours de projet
• Contraintes temporelles
• Contraintes juridiques
• Des équipes de développement évoluant en permanence (changement d’équipe, et donc actualisation des documents de travail compliquée)
• Ressources provisoires
• …

Définir les exigences

Un travail de recherche est donc nécessaire pour redéfinir les spécifications, et par la suite les exigences. A partir de là seulement une stratégie de qualification pourra être conçue. Afin d’y parvenir, beaucoup de rigueur et un gros travail d’investigation seront nécessaire.

L'approche doit se décomposer en deux principales étapes :

Étape 1 – Rassembler les données d’entrée

L’objectif de cette étape est de lister tous les choix de conception du logiciel. Les moyens pour y parvenir sont variés, et il est recommandé de recouper les informations obtenues selon différents vecteurs d’information :

• Exploiter les documents de base listant les exigences utilisateurs, s’ils existent
• Lire la documentation générale concernant le logiciel (cahier des charges, planning…)
• Etudier l’architecture du logiciel (dossier d’architecture technique)
• Naviguer sur le logiciel
• Enquêter auprès des développeurs et du chef de projet : la communication joue un rôle essentiel pour la recherche d’informations
• Participer au maximum de réunions possibles (pour autant que la présence soit acceptée)
• …

Il faut éviter d'adopter une attitude moralisatrice (« Vous n’avez pas bien fait votre travail », « Je n’ai pas les données dont j’ai besoin », …).

Les relations avec les différents acteurs du projet doivent être les plus agréables possibles, afin de pouvoir collecter le maximum d’informations dans le temps. Un développeur, par exemple, peut se souvenir quelques jours après votre visite qu’il a des documents sous format électronique: il sera plus enclin à vous les envoyer s’il vous a trouvé sympathique…

Par ailleurs, il faut garder à l’esprit que les choix qui ont déterminé la conception du logiciel ont été faits par différents services : marketing, développement… Vous êtes une des rares personnes à avoir une vue d’ensemble sur le projet : d’où l’importance de faire une synthèse des informations recueillies, et veiller à ce que chaque participant ait été pris en considération afin d’être le plus exhaustif possible.

Étape 2 – Traduire les choix de conception en exigences

Une fois que les choix effectués sont déterminés, il faut les transformer en exigences. Ces exigences vont correspondre aux étapes de vérification qui seront effectuées par l’équipe de qualification.

Elles sont donc reliées aux spécifications, et doivent retranscrire la notion de testabilité et de non-ambiguïté.

Définir la Stratégie de Test

Une fois les exigences définies, la phase de définition de la stratégie de test peut débuter.

Définir les priorités

Les exigences étant le fruit de choix de conception, un logiciel est souvent relié à des centaines d’exigences. L’exhaustivité n’est donc jamais un objectif réalisable pour une équipe de qualification : on définit des priorités dans leur traitement.

En effet, certaines d’entre elles ne sont pas essentielles au bon fonctionnement du logiciel : elles ne doivent être testées que si le budget et les délais le permettent, et si l’action menée apporte une plus-value par rapport à la qualification des éléments déjà identifiés.

La deuxième étape consiste donc à définir un degré de couverture. Ce degré est intimement lié à la notion de risque : plus le degré de couverture est grand, moins le risque est important.

Définir la qualité

Une fois définies les exigences et leurs priorités, il faut à présent déterminer la qualité que l’on va délivrer.

Une procédure de test peut être plus ou moins fine selon le niveau de qualité requis. Il en résultera un effort de test, et par conséquent un coût (délais, budget), plus ou moins important.

Un exemple de paramétrage de mesure de la qualité peut être :

• Minimiser le temps d’introduction sur le marché

On livre le produit le plus rapidement possible

• Maximiser la satisfaction du client

On livre un produit avec un maximum de caractéristiques

• Minimiser le nombre d’erreurs

On livre un produit avec le moins d’erreurs possible

Lors de la définition du niveau de qualité, l’un de ces trois axes est privilégié. En fonction du choix effectué, la stratégie de test n’est pas la même.

Définir un plan de test avec ses critères de fin de test

Tous les éléments sont disponibles pour créer un plan de test.

Il est important de considérer toutes les exigences définies auparavant dans leur ensemble, et de décider ce qui sera et ne sera pas testé. Des scénarios pourront être développés, en spécifiant pour chaque test ses critères de fin.

La recette en elle-même peut commencer !