Ecrire des test avant de développer ?

**kisitomomotene** · 18/08/2006, 21h10

Salut à tous.

Si je ne m'abuse, la methode XP préconise d'écrire des test avant de développer (développer=analyse+conception+codage), et qu'en plus c'est l'utilisateur qui devrait écrire les test.

Comment un utilisateur (et même un développeur) peut il écrire des tests précis lorsqu'il n'a même pas une idée de l'architecture de l'application? je pense par exemple que la description d'un scénario peut radicalement changer en fonction du type d'interface utilisateur ( web, swing, "ligne de commande", imode, vocale etc..), or le choix d'une interface utilisateur est le résultat d'une conception, l'utilisateur (et même le développeur) doit avoir une expérience sur l'utilisation d'un type d'architecture donné pour pouvoir écrire des tests fiables.

Donc de mon point de vue la démarche pour les tests doivent être: analyse+conception+écriture des tests+codage+exécution des tests.

Ou alors j'aimerais avoir plus d'éclaircissement.

**Matthieu Brucher** · 18/08/2006, 21h14

En fait, le client te dit ce que le système doit retourner à la fin selon une certaine suite d'actions - le cas d'utilisation par exemple -.
A partir de là, tu construis ton architecture logicielle. Puis, quand tu développes réellement, tu sais comment tu vas arriver au résultat, tu connais les résultats intermédiaires. C'est là-dessus que tu feras tes tests élémentaires, puis des tests plus complexes, ...
Kent Beck a écrit un excellent livre à ce sujet : http://conception.developpez.com/livres/#L0321146530

**kisitomomotene** · 19/08/2006, 08h57

Envoyé par Miles

En fait, le client te dit ce que le système doit retourner à la fin selon une certaine suite d'actions

En fait je pense que les tests doivent allez plus loin qu'une simple descrition des données attendus en retour à une suite d'action. Un test doit décrire le comportement même du système. Par exemple les tests ne doivent pas se contenter de dire que "lorqu'on entre les valeurs x, y, z...", mais "lorsqu'on coche les champs x, y, z.." c'est plus précis et cette dernière formulation suppose qu'on est en face d'une interface graphique, donc qu'une partie de l'architecture est déjà faite ( car le choix même du type d'UI fait partie de l'architecture).

Donc au moment de la formulation des cas d'utilisation on peut écrire "si on entre les valeurs x, y ,z ..."
mais pour les tests on doit être plus précis en disant par exemple "si on coche les champs x, y, z ..."

**Matthieu Brucher** · 19/08/2006, 09h19

Dire qu'on utilise des checkbox et ou des lineedit ne dit rien sur l'architecture.

**kisitomomotene** · 19/08/2006, 10h17

Envoyé par Miles

Dire qu'on utilise des checkbox et ou des lineedit ne dit rien sur l'architecture.

ça ne dit rien sur l'architecture mais c'est une consèquence d'un choix architectural. Je crois que le choix du type d'UI à utiliser pour une application incombe à l'architecte.

**Matthieu Brucher** · 19/08/2006, 10h24

Je ne vois pas le rapport entre ce qu'on met dans l'interface et l'architecture.

**kisitomomotene** · 19/08/2006, 16h00

Envoyé par Miles

Je ne vois pas le rapport entre ce qu'on met dans l'interface et l'architecture.

Je pense qu'on doit recentrer le débat (sinon on va ouvrir un débat sur l'architecture ce qui n'est pas l'objet du post initial). Le problème fondamental est celui ci: avec une interface A très riche que j'ai conçu (je dis bien conçu, pas programmer) je peux en un seul click obtenir une information donnée. Sur une interface B très pauvre je dois faire une serie de saisie-validation pour obtenir le même resultat.
Le programme de test pour l'interface A ne sera pas le même que pour l'interface B. L'utilisateur ne peut pas savoir à priori si on va utiliser l'interface A ou l'interface B (ni même le programmeur d'ailleur), donc il ne peut pas écrire des tests fiables avant le développement. Voila c tout!

**Matthieu Brucher** · 19/08/2006, 16h52

Personnellement, si tes tests sont tellement dépendants de ton interface graphique, il y a un problème.
Dans toute interface graphique, on pourra mettre les mêmes infos, sous une forme plus ou moins identique.

**kisitomomotene** · 19/08/2006, 18h23

Envoyé par Miles

Personnellement, si tes tests sont tellement dépendants de ton interface graphique, il y a un problème.
Dans toute interface graphique, on pourra mettre les mêmes infos, sous une forme plus ou moins identique.

Bon un exemple concret. Je veux obtenir une liste d'abonnés.
L'interface A est une interface riche (swing, ajax ou win form), je peux dérouler à l'interieur de la fenêtre toutes les information: les informations disparaissent d'un côté de nouvelle information apparaisse d'un autre côté.
L'interface B est HTML, les informations arrivent paginées avec les numéros de page 1, 2 et 3.

Avec l'interface B je dois tester si la pagination fonctionne correctement. avec l'interface A c'est pas la peine, puisque jes reçus toutes les informations (il n'y a pas de pagination quoi)

**Matthieu Brucher** · 19/08/2006, 18h30

L'interface est un niveau, le travail derrière est un autre niveau, les 2 modules communiquent, mais le deuxième doit être indépendant du premier, donc l'interface ne joue pas sur le test en lui-même - déjà, les tests automatiques ne s'effectuent pas avec l'utilisateur qui rentre des données, j'ai oublié de le préciser, ce sont des tests qui sont exécutés automatiquement, c'est d'ailleurs pour ça qu'il est si difficile de tester une interface, et là je suis d'accord avec toi -.

**tipiak** · 21/08/2006, 14h50

cela dépend aussi du niveau de test:

Test acceptance utilisateur : applicatif Vs besoins utilisateurs:
validité par rapport au fonctionnel (à ce point la on ne parle pas d'architecture ni même de technique) ils s'acrivent à partir des documents fonctionnels
system: (tests sur le system intégré) on se base sur la conception technique (intégration des différents sous ensemble) la tu as besoin d'avoir une architecture...
intégration: validation des interfaces entre composants
et les unitaires....
et j'en passe

biensure c'est de la théorie. lors de la définition de la stratégie de tests (en fonction de chaque projet, archi contraintes) tu définis quelles sont les phases de tests à faire ( ainsi que l'ensemble de la strategie de qualification: capacity planning, etc etc...)

les inputs nécéssaire à la rédaction d'un plan de tests ne sont pas toujours un dossier de conception... cela dépend du niveau de tests...

**kisitomomotene** · 21/08/2006, 15h08

Envoyé par tipiak

cela dépend aussi du niveau de test:

Test acceptance utilisateur : applicatif Vs besoins utilisateurs:
validité par rapport au fonctionnel (à ce point la on ne parle pas d'architecture ni même de technique) ils s'acrivent à partir des documents fonctionnels
system: (tests sur le system intégré) on se base sur la conception technique (intégration des différents sous ensemble) la tu as besoin d'avoir une architecture...
intégration: validation des interfaces entre composants
et les unitaires....
et j'en passe

biensure c'est de la théorie. lors de la définition de la stratégie de tests (en fonction de chaque projet, archi contraintes) tu définis quelles sont les phases de tests à faire ( ainsi que l'ensemble de la strategie de qualification: capacity planning, etc etc...)

les inputs nécéssaire à la rédaction d'un plan de tests ne sont pas toujours un dossier de conception... cela dépend du niveau de tests...

Puis je avoir une référence où je peux avoir un exemple de dossier de test complet pour une application?
Merci

**tipiak** · 22/08/2006, 12h07

Envoyé par kisitomomotene

Puis je avoir une référence où je peux avoir un exemple de dossier de test complet pour une application?
Merci

un example de test plan sur google:
http://www.developsense.com/testing/TestPlanOutline.doc
apres pour avoir quelque chose de plus utile et de plus précis il faut voir avec l'existant de ton entreprise:
car il doit être adapté aux processus de ta boite ainsi qu'à son organisation

de même pour le capacity planning ou la strategie de tests , on rentre dans tes infos bcp plus privée pour chaque context (ces documents sont donc bcp moins génériques qu'un template de test plan...)

**Eowyn** · 24/08/2006, 17h20

Il faut voir de quel type de tests tu parles...

pour le 'technique', cela a déjà été traité ce me semble.
Pour les tests 'user', si le travail d'analyse et de spécifications a été fait avec des use-cases, de fait tu as d'ores et déjà écrits tes test-cases.
non ?!

**Myrrhias** · 16/10/2007, 08h01

EDIT:Oops, je n'avais pas vu que le post datait de un an pris dans mon élan. Bon je laisse on sait jamais ca peut interesser quelqu'un. Si je dois supprimer un mp suffira.

Je travaille sur un projet actuellement qui suit la methode Agile, peut etre qu'en decrire le fonctionnement apportera des éléments.

Je m'excuse auprès de ceux qui connaissent par coeur tout le blabla qui va suivre.

Les intervenants sur le projet vont du personnel métier sans aucune technique, aux développeurs sans aucune connaissance métier. Le relai est assuré par le responsable de la maitrise d'ouvrage en pont avec le responsable de la maitrise d'oeuvre.

Le projet est d'ampleur et vise à progressivement remplacer les multitudes d'applications déjà utilisées dans les services par une seule. C'est donc très sensible, car durant la réalisation du projet, les utilisateurs doivent basculer progressivement de leurs applications historiques vers une seule.

Treve de bavardages:
MOA comprend :
- utilisateurs experts
- Responsable du projet
- Responsable des tests

MOE comprend:
- Architecte technique
- Responsable projet
- Developpeurs

Le projet s'etend sur plusieurs années et est découpé en paliers, eux meme découpés en versions.

Les spécifications générales sont écrites avec les utilisateurs, qui recensent le besoin. Un plan d'urbanisation réparti les fonctionnalités sur les paliers.

Immédiatement des spécifications détailles découpent le besoin en CU (cas d'utilisation)

Ce sont ces cas d'utilisations qui seront utilisés par l'équipe de développement.
Et dans le même temps, ils servent à écrire les tests.

Il n'y a donc aucun besoin de connaitre l'architecture technique pour écrire les fiches de test, il suffit d'avoir des CU très précis, décrivant le fonctionnement nominal et les secondaires, les entrées sorties, les regles de gestion. Pour écrire la fiche de test, il suffit de tester chacune de ces informations.

Il est toutefois à noter que les CU sont validés par l'équipe technique avant l'écriture des tests. Et pour cette validation, l'équipe technique doit déjà savoir quelles technologies elle mettra en place pour couvrir le besoin.

Voilà en ce qui concerne les tests fonctionnels sur cette méthode.

**keb83** · 01/02/2009, 18h16

salut a tous,
oui, encore un étudiant qui parle de son projet...
MAIS! un étudiant qui veut vraiment le faire dans les règles de l'art.

pour un projet en université, celui ci est pas mal gros, plus de 1100 heure réparties sur huit étudiant.

avec l'équipe, on a choisi de suivre une approche itérative et incrémentale, mais je reste sur un truc qui peux vous sembler un détail mais qui m'obsede:

ecrir les testes avant de développer, ok, et pour une GUI? comment on peut écrir des dests automatisés?

j'ai eu beau cherché (oui deux jours ce n'est pas beaucoup, mais quand même!)
rien trouvé de tel, ou alors les tests de l'interface graphique ne peuvent t il peut etre pas etre (facilement) automatisés?

**Matthieu Brucher** · 01/02/2009, 18h20

C'est faisable. Par exemple Qt propose une interface pour tester sa GUI

**keb83** · 01/02/2009, 19h46

merci, je vais voir de suite ce qui en est....

**keb83** · 03/02/2009, 01h46

pas eu le temps de répondre hier...
Qt, tout un framework!!! pas vraiment le bon moment en début de projet de changer de framework...
dommage, à défaut de trouver un outil pas trop compliqué à appréhender et qui pemet des tests automatisés de GUI java, on s'en tiendra aux bons vieux scénarios et captures écran!
merci encore

Ecrire des test avant de développer ?

Test

Discussions similaires

Partager

Partager