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.
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
Schéma directeur
Étude préalable ou étude d’opportunité
Étude détaillée
Étude technique
Réalisation
Programmation
Préparation des jeux d’essai
Tests unitaires
Tests d’intégration
Recette client
Mise en œuvre
Paramétrage
Reprise des données
Formation
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 :
Analyse des besoins
Conception
Programmation et tests unitaires
Tests d’intégration
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
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 :
Organiser et planifier l’activité
Élaborer les tests et les jeux d’essai
Effectuer les tests
Analyser et historiser les résultats
Définir les corrections à réaliser
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 :
La description de l’anomalie relevée pendant le test
La transmission à l’équipe de développement
Le suivi de la correction
La vérification après livraison d’une nouvelle version
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 :
Les anomalies critiques sont traitées en priorité.
La charge de correction est évaluée afin de planifier le cycle suivant.
Les corrections sont réalisées selon les priorités et les disponibilités de l’équipe.
Une nouvelle version est livrée.
Les anomalies corrigées sont retestées.
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
