6 - le processus de recette d'un projet

Enjeux des tests

Les tests visent à vérifier que le logiciel répond aux exigences et à réduire les risques liés à sa mise en production.

Le niveau de test résulte d’un arbitrage entre :

• Les exigences de qualité et de garantie
• Les contraintes client
• La criticité de l’application, notamment en matière de sécurité
• Le délai de mise sur le marché (time-to-market)
• Le respect de la date de livraison
• Les risques de pénalités de retard et de perte de crédibilité

L’exhaustivité des tests est impossible : il faut donc définir un périmètre, des priorités et une stratégie de test.

Types et objectifs des tests

Tests unitaires

Les tests unitaires vérifient individuellement les composants ou modules développés.

• Ils sont réalisés pendant ou juste après le codage.
• Ils sont adaptés à une approche ascendante, module par module.
• Ils peuvent être automatisés.
• Idéalement, leur conception est confiée à un développeur différent de celui ayant développé le composant.

Tests d’intégration technique

Les tests d’intégration technique vérifient le bon fonctionnement des composants lorsqu’ils sont assemblés.

Ils portent notamment sur :

• Les interfaces entre modules
• Les échanges de données
• La cohérence technique de l’ensemble
• Les dépendances entre composants

Ils sont généralement conçus et réalisés par un développeur ou un chef de projet technique.

Tests fonctionnels / recette

La recette fonctionnelle valide la conformité du logiciel aux besoins métier, au cahier des charges et aux spécifications fonctionnelles.

Elle vérifie notamment :

• Les informations gérées
• Les règles de gestion
• Les processus opérationnels
• Les restitutions et reportings
• L’ergonomie et l’utilisabilité

La recette est généralement conçue par un utilisateur, un analyste ou un chef de projet fonctionnel, puis exécutée par des utilisateurs.

Recette d’intégration fonctionnelle

La recette d’intégration fonctionnelle valide le paramétrage et l’enchaînement des processus métier dans une solution intégrée.

Elle concerne notamment :

• Le paramétrage spécifique réalisé pour le client
• L’intégration entre les processus métier
• Les développements spécifiques non couverts par la recette standard de la solution

Elle est généralement conçue par le chef de projet fonctionnel et réalisée par un utilisateur clé ou un chef de projet fonctionnel.

Tests de performance

Les tests de performance évaluent le comportement du système sous différentes contraintes.

Ils portent sur :

• Le temps de réponse
• Le nombre d’accès simultanés
• La durée des traitements
• Le volume de données manipulées
• L’endurance du système
• La stabilité sous charge
• La disponibilité du débit pour les utilisateurs

Ils peuvent nécessiter des outils de simulation d’utilisateurs et des scénarios techniques.

Tests de sécurité et de compatibilité

Les tests techniques spécifiques peuvent couvrir :

• Les risques d’intrusion
• La compatibilité avec les navigateurs et leurs versions
• L’intégrité du poste de travail
• Le comportement en cas de défaillance applicative
• Le fonctionnement en mode dégradé
• Les variations du nombre de connexions
• Les extensions de navigateur ou outils côté serveur

Tests en environnement opérationnel

Les tests en environnement opérationnel interviennent lors de la qualification.

Ils permettent de vérifier le comportement du logiciel dans des conditions proches ou identiques à la production.

Cycles de développement et validation

Étapes principales d’un projet

1. Schéma directeur
2. Étude préalable ou étude d’opportunité
3. Étude détaillée
4. Étude technique
5. Réalisation
   • Programmation
   • Préparation des jeux d’essai
   • Tests unitaires
   • Tests d’intégration
   • Recette client
6. Mise en œuvre
   • Paramétrage
   • Reprise des données
   • Formation
7. Qualification
   • Tests en environnement opérationnel

Modèle en V

Le modèle en V associe chaque phase de conception à une phase de validation ou de vérification.

Phase de conception	Phase de contrôle associée
Étude de faisabilité	Validation
Définition des besoins	Validation
Conception générale	Vérification
Conception détaillée	Vérification
Codage	Tests unitaires
Intégration	Tests d’intégration
Implémentation	Recette

Approche itérative

Dans une approche itérative, les phases suivantes sont répétées plusieurs fois :

1. Analyse des besoins
2. Conception
3. Programmation et tests unitaires
4. Tests d’intégration
5. Livraison d’une version opérationnelle et recette

Chaque itération produit une version testable du logiciel.

Qualité logicielle

Fiabilité

La fiabilité correspond au respect des exigences fonctionnelles définies dans le cahier des charges et les spécifications.

Elle couvre :

• Les données à gérer
• Les règles de gestion
• Les processus opérationnels
• Les reportings

Performance

La performance mesure la capacité du logiciel à fournir le niveau de service attendu.

Critères principaux :

• Temps de réponse
• Nombre d’utilisateurs simultanés
• Durée des traitements
• Volume de données
• Endurance

Utilisabilité

L’utilisabilité concerne la facilité d’utilisation du logiciel.

Elle inclut principalement :

• L’ergonomie
• La clarté des interfaces
• La cohérence des parcours utilisateur
• L’adaptation aux usages réels

Processus de test

Le processus de test se déroule en six étapes :

1. Organiser et planifier l’activité
2. Élaborer les tests et les jeux d’essai
3. Effectuer les tests
4. Analyser et historiser les résultats
5. Définir les corrections à réaliser
6. Corriger et livrer une nouvelle version

Stratégie de test

La stratégie de test définit la méthodologie appliquée pendant les phases de test, selon le cycle de vie et l’avancement du projet.

Elle précise notamment :

• Le périmètre fonctionnel et technique à tester
• Les cycles de test
• Les priorités
• Les modules critiques
• Les ressources nécessaires
• Les outils utilisés
• Les critères d’entrée et de sortie des tests

Approche descendante

Les tests descendants partent des processus utilisateur et vérifient progressivement les composants impliqués.

Cette approche est particulièrement adaptée à la recette fonctionnelle.

Approche ascendante

Les tests ascendants commencent par les modules les plus élémentaires, puis remontent progressivement vers les fonctions globales.

Cette approche est particulièrement adaptée aux tests unitaires et aux tests d’intégration technique.

Préparation des tests

Environnement de test

L’environnement de test doit être préparé avant l’exécution des tests.

Il comprend :

• Les serveurs
• Les postes de travail
• Les bases de données de test
• Les bases de préproduction
• Les outils de test
• Les outils de montée en charge
• Les automates de tests fonctionnels

Planification

Le processus de test doit prévoir :

• Les cycles de test
• Le périmètre de chaque cycle
• Les ressources humaines nécessaires
• Le planning
• Les outils de suivi des anomalies et corrections
• Les modalités de reporting

Cas de test

Selon la norme IEEE 829, un test est un ensemble de cas de test lié à un objectif.

Un cas de test définit :

• L’état de l’objet à tester avant l’exécution
• Les actions à effectuer ou les données à saisir
• Les valeurs ou observations attendues
• L’état attendu après exécution
• Éventuellement, une procédure d’exécution détaillant la séquence des actions

Plan de recette

Le plan de recette organise les tests fonctionnels à effectuer à partir des spécifications fonctionnelles détaillées.

Il permet de :

• Répertorier les cas de test prévus
• Associer chaque test à une exigence ou une spécification
• Définir les prérequis et jeux d’essai
• Décrire les actions à réaliser
• Définir les résultats attendus
• Suivre l’exécution des tests
• Tracer les anomalies détectées

Un plan de recette comporte généralement les informations suivantes :

Élément	Rôle
Identifiant du test	Référence unique du cas de test
Module	Fonctionnalité ou composant concerné
Cas de test	Situation à vérifier
Référence de spécification	Exigence couverte par le test
Pré-requis / jeu d’essai	Données et conditions nécessaires
Actions	Manipulations à réaliser
Résultat attendu	Comportement conforme attendu
Résultat observé	Comportement réellement constaté
Statut	État du test ou de l’anomalie

Jeux d’essai

Les jeux d’essai correspondent aux données préparées pour exécuter les tests.

Ils doivent permettre de vérifier :

• Les cas nominaux
• Les cas limites
• Les règles de gestion
• Les cas d’erreur
• Les contrôles de format
• Les transformations de données
• Les critères de sélection
• Les restitutions et fichiers produits

Les jeux d’essai doivent être cohérents avec les exigences fonctionnelles et les données attendues en production.

Gestion des anomalies

Une anomalie est un écart entre le résultat observé et le résultat attendu.

La gestion des anomalies comprend :

1. La description de l’anomalie relevée pendant le test
2. La transmission à l’équipe de développement
3. Le suivi de la correction
4. La vérification après livraison d’une nouvelle version
5. L’historisation des résultats

Chaque anomalie doit être rattachée à un cas de test et contenir au minimum :

• Un identifiant
• Le cas de test concerné
• La version testée
• Le résultat observé
• La date de détection
• L’auteur de la détection
• Le niveau de criticité
• Le statut
• L’historique des actions et corrections

Niveaux de criticité

Les anomalies peuvent être catégorisées selon leur impact :

Niveau	Signification
Bloquante	Empêche l’utilisation du logiciel ou bloque un processus critique
Majeure	Altère fortement une fonctionnalité importante sans bloquer totalement le système
Mineure	Défaut ayant un impact limité sur le fonctionnement
Cosmétique	Défaut de présentation ou d’ergonomie sans impact fonctionnel significatif

Suivi et pilotage

Le pilotage des tests consiste à comparer l’avancement réel avec l’avancement prévu.

Les principaux indicateurs sont :

• Nombre de tests prévus
• Nombre de tests réalisés
• Nombre de tests réussis
• Nombre de tests échoués
• Nombre de tests bloqués
• Nombre d’anomalies détectées
• Répartition des anomalies par criticité
• Nombre d’anomalies corrigées
• Nombre d’anomalies à retester
• Charge estimée de correction
• État d’avancement par module ou processus

Correction et nouvelle version

Après analyse des anomalies :

1. Les anomalies critiques sont traitées en priorité.
2. La charge de correction est évaluée afin de planifier le cycle suivant.
3. Les corrections sont réalisées selon les priorités et les disponibilités de l’équipe.
4. Une nouvelle version est livrée.
5. Les anomalies corrigées sont retestées.
6. Une note de version (release note) ou un compte-rendu de recette est produit ou mis à jour.

Organisation et responsabilités

Type de test	Conception	Réalisation
Tests unitaires	Développeur, idéalement distinct du réalisateur du développement	Développeur
Tests d’intégration technique	Développeur ou chef de projet	Développeur ou chef de projet
Tests de performance	Chef de projet technique et chef de projet fonctionnel	Chef de projet technique
Tests fonctionnels / recette	Utilisateur ou analyste indépendant du développement	Utilisateur
Recette d’intégration fonctionnelle	Chef de projet fonctionnel	Utilisateur clé ou chef de projet fonctionnel

Outils de test et collaboration

Lorsque plusieurs utilisateurs et développeurs participent à la recette, il faut mettre en place :

• Un workflow de création, mise à jour et validation des fiches d’anomalies
• Un outil de suivi des anomalies (bug tracking)
• Un historique des versions et corrections
• Un reporting d’avancement partagé
• Une gestion claire des statuts et responsabilités

Les outils de suivi doivent faciliter :

• La centralisation des anomalies
• L’affectation aux personnes responsables
• La priorisation
• Le suivi des corrections
• Le retest
• La production d’indicateurs de pilotage