Tests et recette dans les systèmes de gestion : comment ça marche ?

La recette est l’opération par laquelle le client reconnaît que le produit livré par le fournisseur est conforme à sa commande, qu’il est exploitable dans son système d’information et qu’il peut être mis à disposition des utilisateurs finaux.

De manière générale, le recettage se décompose en deux grandes étapes :

• Une phase préparatoire consistant à établir un plan de test, matérialisé par un cahier de recette. Chaque activité est intégrée dans le planning du projet pour garantir son bon déroulement.
• Une phase d’exécution des tests, permettant de remonter tous les bugs et anomalies. Un bilan est effectué afin d’améliorer la prochaine batterie de tests.

Bon à savoir

On distingue :

• La recette provisoire, qui consiste à vérifier que le produit livré correspond aux spécifications du contrat signé avec le client.
• La recette définitive, effectuée ultérieurement, qui consiste à vérifier que le logiciel fonctionne bien dans des conditions proches de son utilisation opérationnelle.

Le cahier de tests (aussi appelé cahier de recette) est un document qui réunit tous les éléments utiles à la maîtrise d’ouvrage du projet informatique.

Il n’existe pas de règle universelle pour rédiger un cahier de recette. Néanmoins, ce document suit généralement la structure suivante :

• La présentation du projet : contexte, objectifs, désignation du chef de projet de recette et des autres responsables…
• Les prérequis pour la recette : périmètre et environnement des tests, équipes impliquées, répartition des missions…
• La liste des tests : description exhaustive des différents tests à effectuer.

La gestion d’un projet de développement implique la réalisation d’une multitude de tests, qui peuvent être de différentes natures. Voici les plus fréquents.

Les tests unitaires ont pour but de tester séparément les différents composants, classes ou modules du logiciel, afin de s’assurer que chaque élément fonctionne comme prévu.

Aussi appelés tests de composants, ils sont assez simples à automatiser et peuvent être exécutés très rapidement via un serveur d’intégration continue.

Les tests d’intégration visent à vérifier le bon fonctionnement des interactions et de l’interface entre les différents composants. Par exemple, ils permettent de tester l’interaction d’un élément avec une base de données.

Pour que ces tests soient réalisables, plusieurs composants de l’application doivent être opérationnels : leur mise en œuvre est donc un peu plus coûteuse.

Les techniques de test fonctionnel se concentrent sur les exigences métier du logiciel. Concrètement, ils ne s’intéressent pas aux états intermédiaires du système lors de l’exécution d’une action, car ils vérifient uniquement la sortie de cette action.

Ces tests nécessitent plusieurs composants opérationnels et capables d’interagir : c’est pourquoi ils sont parfois confondus avec les tests d’intégration. Toutefois, ils vont plus en profondeur que ces derniers.

Par exemple, un test d’intégration permet de vérifier l’interaction d’un élément avec une base de données. En revanche, un test fonctionnel permet d’obtenir une valeur spécifique de la base de données et de la comparer avec les exigences métier du produit.

Les tests d’acceptation permettent de vérifier que le système est en adéquation avec les processus métier du client. Pour les effectuer, l’application doit donc être entièrement opérationnelle.

Ils peuvent être réalisés par des développeurs en simulant le comportement des utilisateurs, mais aussi par les utilisateurs eux-mêmes (par exemple, dans le cadre d’un bêta test).

Répondre aux spécifications techniques ne signifie pas forcément satisfaire les utilisateurs finaux. En effet, le cahier des charges du client est parfois incomplet, sans oublier les problèmes d’ergonomie qui peuvent nuire à l’expérience. Les tests d’acceptation par l’utilisateur permettent donc de s’assurer que le produit correspond bien aux attentes.

À noter

Une méthode Agile ou une méthode en V n’engendrent pas les mêmes méthodologies de tests et n’impliquent pas le client de la même manière.

L’insuffisance des tests et le manque de qualification des testeurs font partie des causes les plus fréquentes de la mauvaise qualité d’un logiciel. En effet, si les bonnes pratiques de test sont connues en théorie, elles ne sont pas toujours appliquées sur le terrain.

Pour y remédier, utiliser de bons outils de test ne suffit pas : la direction des systèmes d’information DSI doit mettre l’accent sur la formation des équipes. Dans ce domaine, la certification ISTBQ (Comité international de qualification du test logiciel) s’est imposée comme une véritable référence au niveau mondial.

Plus précisément, l’organisation propose trois niveaux de certification :

• Le niveau fondamental permet d’obtenir le titre de testeur certifié : réalisation de tests tout au long du cycle de vie logiciel, techniques statiques, conception des tests, gestion des tests, outils de test…
• Le niveau avancé est composé de trois modules distincts, ayant chacun leur propre examen : manager de tests, analyste de tests et analyste technique de tests.
• Le niveau expert aborde les techniques de test les plus poussées.