Discussion :

[ego]

Bonjour à tous,.......c'est pour un sondage

1- Utilisez-vous les cas d'utilisation pour réaliser vos tests fonctionnels / recette utilisateur ?

2- Comment identifiez-vous les scénarios de test devant être joués ? Comment vous assurez-vous de leur exhaustivité au regard de votre stratégie de test ?

merci à vous

[kiza44]

Voici un élément important de l'organisation des tests : le cahier des recettes.

Ce document doit a pour source les spécifications fonctionnelles, donc les cas d'utilisation.

Ceci répond je pense à une partie de ta question.

[ego]

Ben le nom d'un document n'a jamais dit ce que l'on mettait dedans ni comme on fait pour mettre ce que l'on a à y mettre.

Donc merci pour ton intervention mais non, cela ne répond pas aux questions

[Philippe Bastiani]

Ben le nom d'un document n'a jamais dit ce que l'on mettait dedans ni comme on fait pour mettre ce que l'on a à y mettre.

Donc merci pour ton intervention mais non, cela ne répond pas aux questions

Ce document doit a pour source les spécifications fonctionnelles, donc les cas d'utilisation.

kiza44 t'indiquait que les cas d'utilisations sont UN de tes points d'entrée de ton document de validation. En d'autres termes, chaque test fonctionnel va avoir une référence à un UC.

Pour chaque UC, tu vas avoir :
- un test pour le cas nominal
- un test pour chaque scénario alternatif
- un test pour chaque exception

Bonne rédaction
a+
Philippe

[ego]

Merci pour ton intervention......toi tu ne m'as pas parlé de doc mais bien d'une piste pour savoir quels tests faire à partir de mon UC.

J'aimerai par contre en savoir plus. Comment faites vous concretement pour lister les scénarios, tous les scénarios d'un cas d'utilisation ?
Prenez-vous en compte la "profondeur" de l'algorithme de chaque réaction du système (de l'application). Comme prenez-vous en compte les règles de gestion ? Est-ce que la manière dont sont formulées ces règles influe sur votre facilité pour trouver les scénarios ?

Merci d'avance pour votre retour d'expérience

[Philippe Bastiani]

J'aimerai par contre en savoir plus. Comment faites vous concretement pour lister les scénarios, tous les scénarios d'un cas d'utilisation ?

Concrêtement Tout dépend de la granularité de ton analyze... En gros, s'il y a beaucoup de scenarii, c'est que tu as mal positionné ton curseur. La description d'un UC ne doit pas faire 50 pages... Un UC doit rester lisible pour le client, les architectes techniques, les développeurs, les valideurs ! Brefs, les acteurs qui ne parlent pas la même langue.

Prenez-vous en compte la "profondeur" de l'algorithme de chaque réaction du système (de l'application). Comme prenez-vous en compte les règles de gestion ? Est-ce que la manière dont sont formulées ces règles influe sur votre facilité pour trouver les scénarios ?

Une règle de gestion enrichit ton UC; il n'en reste pas moins, que tu devrais proposer des tests pour chaque régle ou association de règles: s'il s'agit d'exigences fonctionneles qui ont un impact sur l'exécution de ton UC, il faut en effet décrire les scénarii associés et écrire des tests pour chaque scénario.

Note: il faut en faire de même pour les exigences techniques. Tu peux ici proposer des UCs purement techniques ayant pour référence l'UC fonctionnel et des tests associés; ou, directement (i.e. à partir de ton UC fonctionnel) proposer des tests pour ces exigences techniques.

Bref, celà peut devenir très compliqué... et, auquel cas c'est peut-être que le périmètre fonctionnel de l'UC en question a été mal défini.

a+
Philippe

[ego]

ok merci pour toutes ces précisions.

Mais tu te rends bien compte que l'on peut dire le user fait ceci, le système répond cela, si la réponse est "1" le UC est terminé si la réponse est "2" le user fait truc puis le système répond bla bla et c'est terminé.

A première vue il y a 2 chemins ici : la décision 1 ou 2. Mais si on regarde le détail de la réponse du système, celle qui va dire 1 ou 2, on se rend compte que si on avait décrit comment le système répond 1 ou 2 on se serait rendu compte qu'il y a plusieurs combinatoires qui amènent à répondre 1 ou 2.
Donc il y a en fait probablement plus de 2 chemins si on regarde de plus près.
Ma question est alors, avez vous une règle, pratique qui dit s'il faut aller plus ou moins loin dans l'identification des "chemins".
Si on ne va pas plus loin que ce que j'ai dit au départ (2 chemins), il faudra jouer avec les jeux de données pour tester tous les cas où l'on prend le chemin 1 et tous les cas où l'on prend le chemin 2.

J'espère ne pas être trop obscure dans mon explication

[Philippe Bastiani]

Déjà un UC ce n'est pas un algorithme. Sa rédaction doit être le plus synthétique possible pour être accessible à tous... sa rédaction doit être précise mais des racourcis sont acceptables !

Pour en revenir a tes scénarii: effectivement tu peux avoir XX résultats et YY chemins pour y parvenir... Imagines que tu es l'UC "jouer une partie d'échec" -> il est évident que tu ne pourras pas définir l'ensemble des chemins possible pour arriver aux PATs et MATs... Par contre, tu pouuras remarquer que l'UC est très lié à une liste de règles ! Alors que faire:

-1- les chemins ont un sens fonctionnel dans leur ensemble => il est évident qu'il faut les décrire avec précision. La validation les prendra tel quel pour les tests. Biensûr, si il y a trop de chemins, c'est que la granularité choisie est trop grande; et, il est conseillé de scinder ton UC.

-2- les chemin n'ont pas un sens fonctionnel fort (cas de la partie d'échec)... ici, ce sont des séquences de tes règles de gestion qui ont un sens fonctionnel fort => la description va se focaliser sur ces séquences; et, tu vas inciter la validation à faire en faire autant. Ici aussi, si il y a trop de séquences, c'est que la granularité choisie est trop grande; et, il est conseillé de scinder ton UC. Le choix des jeux de test sera pas évidente à mettre en place...

Cdlt,
Philippe

[ego]

En fait, être précis est nécessaire car sinon on ne sait pas quoi tester. Par contre il y a une dualité entre une description précise, algorithmique de la réponse du système et une description d'un niveau "moins précis" avec des règles de gestion moins formelles ou tout au moins exprimées avec un moyen qui ne permet pas facilement d'en analyser la complexité (en texte en fait).

Dans le premier cas, on pourra avoir "facilement" les chemins et chaque chemin correspondra à une combinatoire de données restreint. Dans le second cas, on aura moins de chemins car on ne pourra pas tous les identifier comme cela mais en contre partie on devra jouer sur les jeux de données.

Dans tous les cas, on aura à tester le même logiciel mais dans le premier cas où les choses sont plus formelles, il est plus facile d'identifier l'ensemble des tests à mener. Dans le second cas, l'effort est plus important.


En fait je pose cette question car j'ai fait dans ma boite un truc qui calcule tous les chemins d'un algorithme modélisé en UML (diagramme d'activités). Et on se rend compte que cette identification aide beaucoup les testeurs qui savent alors quels sont les scénarios de test à mettre en place. Mais si l'algo, ici une séquence d'actions utilisateur / réaction du système, est "grossier", on ne peut pas en tirer grand chose côté test. La condition pour aider au mieux le testeur est de mieux formaliser (modéliser) les choses. Cette formalisation n'est d'ailleurs pas faite que pour le testeur en réalité car elle aide aussi à être précis et aide la suite pour la conception même de l'application.