| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Stop wasting time looking for files and revisions. Connect your Gmail, DriveDropbox, and Slack accounts and in less than 2 minutes, Dokkio will automatically organize all your file attachments. Learn more and claim your free account.

View
 

forum sur TDR

Page history last edited by PBworks 13 years, 1 month ago

Présentation "Forum sur TDR"

 

 

Quel est le niveau d'adoption du Test-driven Requirements/Development ?

 

Aujourd'hui, retour d'expérience sur des projets ayant mis en oeuvre du TDD ou du FTDD, mais pas d'exemple connu d'organisation ayant mis en oeuvre du TDR ni du FTDD + TDD.

 

Utilité de faire du TU si on fait du TF ? Tests unitaires agissent au niveau de la qualité du code et de la conception. Les tests fonctionnels n'ont pas le même effet.

 

Est-ce que l'on peut prendre en compte des notions d'architecture lorsque l'on dirige tout par les tests ?

 

Il existe la possibilité de faire émerger l'architecture au fur et à mesure du refactoring (cf présentation Regis Medina), cela est pris en compte par la notion de refactoring de la pratique TDD.

 

Le test-first permet-il d'adresser les risques le plus tôt possible ? Choisir une brique technique très tôt ne signifie pas forcément d'adresser ses risques très tôt.

 

Sur un projet, l'approche RDD (requirements driven development) n'a pas permi de détecter les problèmes posés par l'intégration en fin d'itération. TDR permet-il d'adresser les exigences non-fonctionnels ?

 

50aine de scenarios dans FITnesse, représentant environ 1000 cas de tests. FITnesse utilisé pour caractériser un bug et pour les tests lancés pdt l'intégration continue (scripts hudson qui lance les tests FITnesse). Les développeurs ont écrit les tests.

 

Expérience d'une équipe ayant utilisée Greenpepper: équipe développement sur 2 sites, livraison en production de l'application en 3 h.

 

Le rôle du business analyste est-il de rester centré sur son métier ? Faut-il contraindre le business analyste dans sa formulation pour des raisons d'outillage ? Est-ce qu'on ne pourrait pas laisser le business analyste exprimer ses besoins dans son langage sans le contraindre par des raisons "techniques". Quelles sont les perspectives d'utilisation du DSL (Domain Specific Language) pour faire du TDR ? Avec DSL on a la possibilité d'intégrer des tests "lisibles" dans le code.

 

Si on arrivait à trouver le formalisme qui permet d'exprimer le besoin sans ambiguité sur un domaine donné on résoudrait le pb des spécifications.

 

Faire émerger un langage formel en "refactorant" ses spécifications. On ne peut pas venir avec le langage formel au départ, ce sont les discussions qui vont permettre de faire émerger le langage commun.

 

Faut-il s'intéresser aux outils pour mettre en place du TDR ? Finalement, ne pourrait-on pas mettre en application le processus sans outil, avant de choisir le bon outil.

 

Le formalisme est le pire des freins pour transmettre l'information, mais le manque de formalisme a un coût qui peut être important.

 

Comment on démarre avec le TDR ? Démarrer avec un outil ne semble pas le moyen d'aborder les choses, car l'outil n'est pas le problème. Le problème est l'organisation en place et comment la modifier.

 

Résumé des idées: l'utilisation d'un DSL permettrait une mise en oeuvre plus élégante du TDR que l'utilisation de FIT/Greenpepper par exemple. On peut commencer à appliquer les pratiques de TDR sans choisir tout de suite un outil, cela peut venir dans un second temps.

Comments (0)

You don't have permission to comment on this page.