Bonjour,
Je vous fournis ci-dessous une réponse générale, pour vous guider (il n'y a pas de définition officielle, chaque entreprise/standard ayant des caractéristiques qui peuvent différer ici ou là).
La notice d'utilisation est un document destiné aux utilisateurs de l'application (avec comme vous l'indiquez les instructions à suivre pour installer ou utiliser le logiciel correctement et efficacement).
= une liste d'actions possibles et de leurs conséquences sans valeurs/données précises
Le cahier de recette est un document qui réunit tous les points permettant de vérifier que tous les besoins de l'utilisateur (ou une sous-liste clairement identifiée) sont couverts par la solution proposée, et que ces éléments sont bien présents à la livraison du logiciel. Chaque élément doit être vérifiable par le client (il faut que les éléments soient mesurables/vérifiables). Par exemple "logiciel ergonomique" n'est pas vérifiable, a contrario "logiciel ergonomique : tous les écrans principaux sont atteints en moins de 3 clics" + une liste de clic à faire et d'écran auquel on aboutit par ces clics est bien vérifiable.
On peut commencer à écrire le cahier de recette dès que les spécifications sont faites.
Le plan de test contient une liste de tests bien identifiés qui comportent à minima :
- un nom unique / un identifiant
- la fonctionnalité à vérifier (si on fait les choses rigoureusement, les fonctionnalités ont également un nom unique / identifiant à indiquer ici)
- la liste des actions à faire et données précises à utiliser au cours de ces actions pour lancer le test
- la description du résultat attendu
- un ensemble de correspondant aux lancements successifs du test
= une liste de tests d'utilisation avec des valeurs/données précises à utiliser et des actions précises à effectuer pour reproduire un test
Le cahier de test est souvent inclus (et parfois identique dans les cas simples) dans le cahier de recette avec la dernière valeur de date/n° de version / résultat du test.
On doit également l'accompagner d'information sur les bugs connus (ceux qui sont en échec dans le cahier de test) pour indiquer si c'est un bug bloquant / qu'il est prévu de corriger / qui peut être contourné par une utilisation différente ou des précautions particulières.
Il est fortement conseillé d'écrire le cahier de recette à partir des spécifications et non pas à partir du code ou de ce que l'on a fait (souvent on donne la tâche de rédaction à quelqu'un qui ne développe pas ou n'a pas encore développé le logiciel pour éviter tout biais).
Dites moi si la logique derrière ces termes est plus claire après ces petites informations (il y a beaucoup de littérature disponible en ligne également !). L'idée est de toujours pouvoir prouver ce que vous faites et d'indiquer la méthodologie utilisée pour l'obtention de ce que vous avez fait.
Cordialement,
Emmanuel Promayon
Je vous fournis ci-dessous une réponse générale, pour vous guider (il n'y a pas de définition officielle, chaque entreprise/standard ayant des caractéristiques qui peuvent différer ici ou là).
La notice d'utilisation est un document destiné aux utilisateurs de l'application (avec comme vous l'indiquez les instructions à suivre pour installer ou utiliser le logiciel correctement et efficacement).
= une liste d'actions possibles et de leurs conséquences sans valeurs/données précises
Le cahier de recette est un document qui réunit tous les points permettant de vérifier que tous les besoins de l'utilisateur (ou une sous-liste clairement identifiée) sont couverts par la solution proposée, et que ces éléments sont bien présents à la livraison du logiciel. Chaque élément doit être vérifiable par le client (il faut que les éléments soient mesurables/vérifiables). Par exemple "logiciel ergonomique" n'est pas vérifiable, a contrario "logiciel ergonomique : tous les écrans principaux sont atteints en moins de 3 clics" + une liste de clic à faire et d'écran auquel on aboutit par ces clics est bien vérifiable.
On peut commencer à écrire le cahier de recette dès que les spécifications sont faites.
Le plan de test contient une liste de tests bien identifiés qui comportent à minima :
- un nom unique / un identifiant
- la fonctionnalité à vérifier (si on fait les choses rigoureusement, les fonctionnalités ont également un nom unique / identifiant à indiquer ici)
- la liste des actions à faire et données précises à utiliser au cours de ces actions pour lancer le test
- la description du résultat attendu
- un ensemble de correspondant aux lancements successifs du test
= une liste de tests d'utilisation avec des valeurs/données précises à utiliser et des actions précises à effectuer pour reproduire un test
Le cahier de test est souvent inclus (et parfois identique dans les cas simples) dans le cahier de recette avec la dernière valeur de date/n° de version / résultat du test.
On doit également l'accompagner d'information sur les bugs connus (ceux qui sont en échec dans le cahier de test) pour indiquer si c'est un bug bloquant / qu'il est prévu de corriger / qui peut être contourné par une utilisation différente ou des précautions particulières.
Il est fortement conseillé d'écrire le cahier de recette à partir des spécifications et non pas à partir du code ou de ce que l'on a fait (souvent on donne la tâche de rédaction à quelqu'un qui ne développe pas ou n'a pas encore développé le logiciel pour éviter tout biais).
Dites moi si la logique derrière ces termes est plus claire après ces petites informations (il y a beaucoup de littérature disponible en ligne également !). L'idée est de toujours pouvoir prouver ce que vous faites et d'indiquer la méthodologie utilisée pour l'obtention de ce que vous avez fait.
Cordialement,
Emmanuel Promayon