[Tests] Comment rédiger un cahier pour la "phase recette" ? exemples ?

Bonjour,

On m'a demandé de rédiger un cahier de recette, mais je ne sais pas trop comment je dois organiser le bazar, ni même quels sont les éléments important qui doivent y figurer. On m'a bien transmis un exemple (ça à l'air super chiant à faire) mais comme je ne connais pas le système sur lequel porte le cahier je ne saisi pas les éléments important de ce dernier. Quelqu'un saurait-il me guider ?

En fait c'est le document papier "cahier de recette" que je sais pas trop comment rédiger... Je sais pas si je suis clair ...

Merci...

dans le sens de la conception (ou plutot des méthodes et process)

il me semble que le cahier de recette "correspond" à un rapport d'exécution des tests, et de livraison d'un projet (la recette)
En gros cela dépend des process et des coutumes de ta boite

mais généralement dans mes documents pouvant s'aparenter à un "cahier de recette"
je mets:
les livrables et composants délivrés (code, composant, documents etc)
et checker avec les documents de spec/conception / cahier des charges etc que tout est la

la description des tests réalisé et leurs rapport exécution


si on devrait faire un amalgamme avec la vie courante,
tu recoit une télévision par livraison, tu check que le carton est en bon état, tu vérifi le bon de livraison, tu check que tout est la (télé, zappette),tu check l'instalation (branchement sur le courant), tu fait des tests utilisateurs (alumer la tv, eteindre, vérifier deux trois chaines), et tu signe (la recette étant souvent liée à une partie contractuelle)

Citation:

---

source: http://phortail.org/webntic/Cahier-de-recette.html
Cahier de recette

Le processus de recette permet au client de valider que la livraison des fonctionnalités développées par le fournisseur (réception du projet), correspond au cahier des charges, issu du processus de conception.

Dans le cadre de la recette fonctionnelle, c’est un document regroupant les scénarios de test ainsi que les jeux de données.

Il est constitué avec des données réelles issues généralement de cas métier et non des données saisies à la volée ou pour leur valeur spécifique. Un choix est fait durant la mise en place de la méthode de test de tout tester, ou de ne tester que ce qui est fonctionnellement utilisé, ou correspondant à des cas métiers réels.

Il est un livrable de la gestion de projets. Ce document peut être complété par la fiche de test

---

Je vais essayer d'être plus clair,

Lors de la réalisation d'une application, on rédige des fiches de test (test unitaire
et test d'intégration) avant la réalisation de ces tests et la mise en recette (qui est réalisé par l'utilisateur).
Le cahier de recette qu'on m'a demandé de réaliser est (apparement) un document qui permet de recenser tous les cas de tests à effectuer sur l'application (donc quelques chose de bien plus complet que les TU et les TI). Mon problème est plus qu'est ce doit y faire figurer,et jusqu'ou doivent aller les cas de tests ( notament par rapport aux TI/TU).
Comme personnelement je n'en ai jamais rédiger et que je n'ai trouvé aucune infos sur le net et que visiblement ça à l'air d'être un document répandu, je cherchais à en savoir plus ...
[/reponse]

Citation:

---

Envoyé par venegan

Je vais essayer d'être plus clair,

Lors de la réalisation d'une application, on rédige des fiches de test (test unitaire
et test d'intégration) avant la réalisation de ces tests et la mise en recette (qui est réalisé par l'utilisateur).
Le cahier de recette qu'on m'a demandé de réaliser est (apparement) un document qui permet de recenser tous les cas de tests à effectuer sur l'application (donc quelques chose de bien plus complet que les TU et les TI). Mon problème est plus qu'est ce doit y faire figurer,et jusqu'ou doivent aller les cas de tests ( notament par rapport aux TI/TU).
Comme personnelement je n'en ai jamais rédiger et que je n'ai trouvé aucune infos sur le net et que visiblement ça à l'air d'être un document répandu, je cherchais à en savoir plus ...
[/reponse]

---

ce que tu dois y mettre en plus des rapports de tests, c'est le contenu de qui est livré
faire des TI et de TU c'est pas la role de la recette
par contre vérifier que les TI ont été effectués et sont passé c'est le role de la recette
idem avec les TU. (TU = test unitaires)

par contre en recette, tu dois logiquement avoir du test End-to-End (test utilisateurs)

et comme les TI ou TU ne se sont surement pas fait sur un environment complet/intégré tu va devoir décrir les conditions d'execution de la recette:
- sur quelle machine
- quels composants, quelles versions
etc ...

mais comme déja dit: ca dépend des coutumes de ta boite
tu peux avoir des sous recette (recette de deployment: pour le déployment de l'appli, recette d'exploitation: pour les tests utilisateurs...)
et le decoupage TU, TI, Test utilisateur n'est pas systématique
(certains font que des TU et d'autres ont 5 ou 6 niveaux de tests différents...)

Pour faire un cahier de recette tel que tu sembles l'entendre, il faut :

- Identifier les cas d'usage de l'application par ses différents "utilisateurs"
- Identifier les cas d'usage classiques et les cas d'usage plus exceptionnels et les cas d'erreur

- Pour chaque cas d'usage, qui va fournir une valeur ajoutée pour l'utilisateur (c'est en ce sens qu'il est "End-to-End" comme l'a dit mon prédecesseur), identifier des cas de test avec les jeux de données permettant de vérifier que le cas d'usage fonctionne correctement. C'est à dire qu'il donne les résultats attendus mais aussi qu'il réagit correctement quand qq chose ne va pas. Tu auras donc au moins un cas de test "positif" et un cas de test "négatif"

Au fait, les cas d'usage dont je parle, on appelle cela les cas d'utilisation !

Bonjour à tous,

A la lecture de vos différents messages, vous présentez plutôt bien la façon de rédiger un dossier de tests, en revanche la façon de concevoir un plan de test sans utiliser d'outil, hormis Excel n'est pas décrite.

Après plusieurs heures de recherche sur la toile, je désespère de trouver un exemple applicable à la recette fonctionnelle d'une application.

Ce que je recherche, c'est un fichier Excel contenant une méthodologie pour présenter l'arborescence des cas, les structurer en scénarii, en bref : les bonnes pratiques en matière de recette fonctionnelle sur la conception de ce type de document.

Merci pour votre aide.

Bonjour je travaille pour une société qui développe des SIG et j'ai une offre qui pourrais peut être vous intéressé... En effet nous recherchons un ingénieur test et validation. Pour consulter l'offre et postuler à celle-ci, vous pouvez vous rendre sur le lien suivant:
http://www.g2c.fr/portail/article.php?id_article=101369

Bonne fin de journée! :ccool:

Bonjour,

En ce qui concerne le plan de test, il suffit de coucher sur papier les différentes étapes qui te permettent de tester chaque fonctionnalité de ton application. Ensuite il faut les structuré dans un outil ou même sur excel pour organiser au mieux les tests de façon à ce que les testeurs les effectuent le plus facilement possible. C'est très important de bien les organiser afin qu'ils soient faciles à réaliser, car c'est une tâche très rébarbative et il faut penser au bien-être mental des testeurs :p.

Ne pas oublier de réaliser des "Smoke Test" qui consiste à donner la main aux testeurs en se baladant sur le site comme le ferait un utilisateur néophyte. Cela permet bien souvent de détecter des bugs qui ne rentrent pas dans le cadre prévu par l'application.

Stéphane
Recettea
Outil d'automatisation du recettage de site web