Recette d'application
L’élaboration du Cahier de Recette
- La structure d’un dossier de tests est très proche de la structure des données définie dans le modèle conceptuel des données (compréhensible par la MOE ainsi que par la MOA) réalisé pendant les travaux de spécification fonctionnelle.
- Précisément le mode opératoire du scénario de tests sous la forme d’une séquence d’actions à effectuer
- Le résultat attendu à l’issue de l’action pour chaque action du mode opératoire
- La référence au dossier de tests définissant les données métier exploitées en entrée et manipulées au cours du processus
- A chaque étape de vérification d’une fiche de tests (action / résultat attendu) correspond un cas de test identifié dans la matrice de tests. Cette matrice permet de faciliter :
- La lisibilité de la fiche de test par la MOE car rapprochée des spécifications détaillées
- La qualification des problèmes rencontrés au cours de la recette
- La gestion de la recette
- les configurations matérielles et logicielles de la plate-forme
- les valeurs du paramétrage logiciel de façon exhaustive
- Contexte et objectif du document
- Objet de la recette
- Documents de référence
- Responsabilités
- Plate-forme de recette
- Outils de recette
- Présentation générale
- Description de l’arbre de test
- Actions générales
- Liste des fiches
- L’ensemble des points fonctionnels (ou règles de gestion) devant faire l’objet d’une validation
- Les différents cas d’utilisation
- Elle définit le niveau de qualité fonctionnelle souhaité ainsi que le périmètre de la recette
- Elle doit être validée par la MOA
- Les tests de déminage peuvent être établis en collaboration avec la MOA (compétence métier).
- Ces tests permettent de confronter le logiciel très tôt aux futurs utilisateurs.
- Les ressources de la MOA devront être avertis qu’il ne s’agit que d’une aide au développement et non d’une recette d’intégration finale
- Lors de la recette interne, les résultats des tests effectués et les demandes de modification de la MOE sont inscrits dans le cahier de recette en temps réel. Le cahier de recette reflète ainsi l’avancement de la recette en continu
- Il rappelle les éléments indiqués par le cahier des charges
- La MOA pourra accepter ou non les potentielles demandes de dérogation
- Si la MOA accepte, la MOE pourra livrer le logiciel incomplet ou conforme partiellement aux spécifications
- La pré-recette permet à la MOA si la qualité du logiciel est suffisante pour pouvoir être testé. Il faut donc que :
- Tous les livrables convenus sont bien fournis (éléments logiciel et bordereaux de livraison, PV de recette interne, liste des restrictions éventuelles)
- La plate-forme de recette est opérationnelle
- Aucun problème bloquant empêchera le jeu des scénarios
- Elle débouche sur un procès-verbal et annonce le début de la recette fonctionnelle
- La recette provisoire (recette principale) consiste en un contrôle sur la base de l’ensemble des fiches de tests établie par la MOA et validée par la MOE
- Chaque anomalie détectée fera l’objet d’une fiche de fait technique
- Validation : aucune anomalie n’a été détectée, la recette sur site pilote peut alors débuter
- Validation sous réserves : aucune anomalie bloquante n’a été détectée, un PV de validation sous réserve avec la liste des anomalies peut être signé. La MOE s’engage alors à corriger les anomalies avant la livraison sur le site pilote pour recette définitive
- Refus : des anomalies bloquantes ont été détectées ou toutes les exigences. Le PV de recette fera part de ce refus et des raisons. Une fois la phase de correction terminée, la recette provisoire devra être recommencée
- Le groupe de recette est constitué des membres de la MOA ayant si possible participé à la rédaction du cahier des charges et/ou cahier de recette. Lors de la pré-recette, les membres les plus expérimentés évalueront rapidement la qualité générale du logiciel
- Le support technique est composé de membre(s) de la MOE à plein temps. Ils permettent d’assurer la maintenance de la plate-forme et le bon fonctionnement du logiciel (correction des anomalies bloquantes immédiate)
- Le support fonctionnel est représenté par une personne connaissant parfaitement le métier, le cahier de recette et les dossiers de spécifications fonctionnelles. Elle sera responsable de la conduite du changement tout au long de la recette
- Le support méthodologique et organisationnel est assumé par le chef de projet MOA. Il permet d’expliquer comment une fiche de tests doit être interprétée ou bien la façon dont un fait technique doit être rédigé
- Validation, mise en exploitation
- Validation sous réserves, pas d’anomalie bloquante
- Refus, la correction des anomalies donne lieu à la recette provisoire
- La MOE intervient pour l’installation des sous-ensembles logiciels
- La MOA administre la plate-forme
- La même équipe MOA que pour la recette provisoire
- Elle fait suite à la recette définitive
- La mise en exploitation du logiciel devrait révéler de nouvelles anomalies
- Les anomalies remontées font l’objet d’une correction et d’une re-livraison du sous-ensemble logiciel
- Toute modification du logiciel suite à une demande MOA pendant une phase quelconque de la recette donne lieu à un avenant entre les parties
- Il en est de même pour toutes les demandes d’évolution intervenant après l’acceptation du dossier des spécifications logiciel
Comment préparer une bonne recette ?
Une bonne recette se prépare longtemps à l'avance
La recette d'une application est l'étape finale de la réalisation d'un projet informatique mais pour qu'elle soit un succès il faut la préparer dés le début.
Cela commence par la mise au point de la stratégie de precette. Que recetter et comment ? Il s'agit des tests unitaires, de non régressions, d'intégrations, fonctionnels et utilisateurs.
Les tests fonctionnels sont les cas de tests permettant de vérifier les cas utilisateurs (Use Case en UML). Une bonne pratique est de concevoir ces cas en même temps que l'on rédige les cas d'utilisation. En effet il y a très peu d'efforts à fournir puisque les cas d'utilisation décrivent déjà les pré-conditions (état du système avant le déclenchement du cas), les étapes, les règles et les exigances mise en oeuvre et les post-conditions (état du système après l'exécution du cas). Il suffit alors dans le cas de test de copier/coller le cas d'utilisation et de valoriser les données en entrèe, de spécifier les données attendues. L'exécution du cas de test se chargera de comparer les valeurs réellement calculées avec celles attendues. Les experts métier doivent contribuer ou valider les cas de tests.
L'architecture technique doit spécifier les outils pour les tests unitaires (xUnit). Très souvent toutes les entités métiers ne sont pas réalisées, on doit donc bouchonner pour pouvoir simuler les scénarios fonctionnels comme si elles existaient pour de vrai. On parle souvent dans la littérature des "mock" objet. L'architecte identifie les frameworks les plus appropriés, les configure, forme les développeurs.
Le chef de projet met en place une organisation et une politique pour s'assurer que tous les tests unitaires sont bien effectués car très souvent ils sont ressentis comme une lourde contrainte de la part des développeurs.
Le "testeur" technique utilise des outils (Sélénium, QC, ...) pour les tests d'intégration et de non récession. Les cas de tests définis (scénarios métier stratégiques, simulation d'interactions utilisateur avec des écrans, ordonnancement de batchs) sont enregistrés et rejouer à la demande comme par exemple avant la livraison d'une itération ou d'un sprint.(dans la méthode Scrum). Le rapport de livraison contient la liste et les résultats de tous les tests intégration/non régression qui ont été effectués.
Les outils doivent exécuter les étapes en injectant les données en entrée et comparer les résultats obtenus avec les données attendues.
Sinon, des tickets d'anomalies sont créés (Mantis) et on recommence tous le cycle de développement et de tests.
Si toutes les étapes de tests ont été consciencieusement effectuées et si la MOA est restée impliquer à toutes les étapes des itérations, le déroulement des tests d'acceptation par les experts métier devraient être un succès.
Voir aussi le site :