Discussion :

[vdaanen]

Bonjour tout le monde,

je bosse dans le domaine medical et dans ce domaine, les scenarios de tests (et les tests report) font partie intégrante des dossiers de conception a fournir a certaines autorités (marquage CE ou FDA) pour obtenir le droit de vendre un produit.

A ce jour, au niveau "composant unitaire", nous travaillons de la facon suivante :
Spec / Test Plan / Codage des tests / codage fonctionnalité(s) composant / test report.

Le Test Plan est rédigé avec un traitement de texte et une fois que tous les tests passent, on edite un document "Test Report", qu'on remplit de manière mécanique date/qui/resultat (=ok)...

Parfois, on lève une non-conformité et on doit ajouter des tests cases pour vérifier que les modifications apportées corrigent la non-conformité -> il ne faut pas oublier de modifier le TestPlan et il faut rééditer le TestReport pour les maintenir a jour.

Je me disais que puisqu'il existe des outils pour générer de la doc a partir de code source (C++/Java -> diagramme UML par exemple), pourquoi n'existe-t-il pas d'outils capable de parser un code source (qui respecterait un syntaxe, comme pour doxygen par exemple) et d'en tirer un test plan dans un format quelconque

Idem pour génére les test reports : récupération de la sortie d'un programme de test U et parsing pour voir si on trouve des "errors".

Que pensez-vous de l'utilisation de tels outils ?
Il me semble que ca permettrait un gain de temps ("redaction" des tests plans et du prog de test plan en meme temps) mais aussi ca induit le "risque" de ne plus reflechir au test (genre ecrire les tests le nez dans le clavier sans prendre le temps de la reflexion ...)

quelqu'un a-t-il l'experience de tels outils ou pratiques ?

Merci de vos avis

V

[hegros]

Ce qui me déplaît dans cette démarche c'est clairement le cycle en V que tu sembles décrire hors le cycle en V c'est prouvé (statistique à l'appui) que cela conduit à des échecs.

Question pratique, je ne vois pas d'intérêts de parser un code source pour en sortir des tests d'acceptance puisque les tests d'acceptance doivent être écrits AVANT le code source car c'est totalement en abstraction par rapport à l'implémentation.

Et cela n'existe pas 'd'écrire un TU la tête dans le guidon sans réfléchir' puisque par essence lors de l'écriture d'un TU on se pose pleins de questions et donc on réfléchit, voir pour cela comment se pratique le TDD et le ATDD

[vdaanen]

Bonjour,

Ce qui me déplaît dans cette démarche c'est clairement le cycle en V que tu sembles décrire hors le cycle en V c'est prouvé (statistique à l'appui) que cela conduit à des échecs.

Effectivement, nous sommes sur un cycle en V. il faut savoir que dans certaines industries, c'est un des moyens les plus surs permettant d'obtenir les accréditations permettant de vendre les produits; nous sommes dans ce cas, cela ne dépend pas de nous, c'est une nécessité réglementaire... au moins d'un point de vue documentaire.
Toutefois, ceci n'est pas le sujet de conversation.

Question pratique, je ne vois pas d'intérêts de parser un code source pour en sortir des tests d'acceptance puisque les tests d'acceptance doivent être écrits AVANT le code source car c'est totalement en abstraction par rapport à l'implémentation.

Effectivement, dans certains cas, les tests nécessitent une réflexion approfondie et dans ce cas, le parsing d'un code n'est pas adapté, nous sommes d'accord. Toutefois, il nous est tous arrivé d'écrire une classe, je dirai, succincte. Aussi simple soit-elle, elle nécessite tout de même un document de spec (qu'est ce que ce composant est sensé faire), un test plan et un test report. Parfois, le test plan est très simple et on peut coder les tests sans avoir besoin de passer par un test plan rédigé au préalable. Dans ce cas, parser le programme de test peut permettre de gagner du temps.

Prenons un exemple : un composant "Version" qui permet de définir la version d'une appli ou d'une structure de données susceptible d'évoluer au cours de la vie d'une appli et nécessitant des procédures de mise a jour par exemple.

Ce composant a 3 membres Major, Minor et Revision de type uint32 (size_t en C++)

il faudra tester : les constructeurs, les operateurs de copie, les operateurs de comparaison (==, <), l'export en string et l'import en string pour la sauvegarde.

Je pense que dans ce cas, on peut se passer d'un document "test Plan" redigé a l'avance et le "créer" par reverse_engineering sur le code du programme de test.... C'est ce que j'appelais "écrire un TU le nez dans le guidon" ,le "sans réfléchir" était de trop ....

Venons en maintenant au Test reports. Executer un programme de test, verifier qu'il n'y a pas d'erreur et générer un TestReport (qui n'est bien souvent ni plus ni moins qu'un tableau) peut, il me semble, avoir un intérêt.
Par exemple, dans mes projets, j'execute systématiquement toutes les tests U (boost.test) qd je créée le binaire candidat a la mise en production. Ca me permettrait d'avoir mes TestReports corrects automatiquement sans trop d'effort.

Et cela n'existe pas 'd'écrire un TU la tête dans le guidon sans réfléchir' puisque par essence lors de l'écriture d'un TU on se pose pleins de questions et donc on réfléchit, voir pour cela comment se pratique le TDD et le ATDD

oui, j'applique le TDD (connait pas le ATDD par contre )

V

[hegros]

Faire de la rétro-ingénierie de tests existants si je comprends bien ? Dans ce cas pour l'aspect documentaire cela peut effectivement être intéressant et faire gagner du temps. Il est même envisageable d'avoir plusieurs aller retour (itération):

1-Rétro-ingénierie de tests existants et génération d'un plan de tests
2-Modification du plan de tests généré pour le faire coller aux spécifications
3-Modification des tests existants (puis recommencer depuis l'étape 1 jusqu'à satisfaction)

ATDD ce sont des tests d'acceptance que l'on peut aussi implémenter sous forme de test unitaire sauf que ces tests d'acceptance se concentrent sur les tests qui sont sensés valider un logiciel d'un point de vue utilisateur/client, ce sont les tests finaux (dans le cycle en V c'est le niveau de test le plus haut )

Tu trouveras pleins de documentations en tapant ATDD dans un moteur de recherche.

[vdaanen]

Faire de la rétro-ingénierie de tests existants si je comprends bien ?

oui

Dans ce cas pour l'aspect documentaire cela peut effectivement être intéressant et faire gagner du temps. Il est même envisageable d'avoir plusieurs aller retour (itération):

1-Rétro-ingénierie de tests existants et génération d'un plan de tests
2-Modification du plan de tests généré pour le faire coller aux spécifications
3-Modification des tests existants (puis recommencer depuis l'étape 1 jusqu'à satisfaction)

C'est comme cela que j'imaginais la chose. J'imagine bien un outil qu'on peut "declencher" apres execution du programme de test et qui genere le TP et le TR seulement si tous les resultats sont "au vert"

ATDD ce sont des tests d'acceptance que l'on peut aussi implémenter sous forme de test unitaire sauf que ces tests d'acceptance se concentrent sur les tests qui sont sensés valider un logiciel d'un point de vue utilisateur/client, ce sont les tests finaux (dans le cycle en V c'est le niveau de test le plus haut )

Tu trouveras pleins de documentations en tapant ATDD dans un moteur de recherche.

ok, des tests de verifs automatiques. Je me suis renseigné et je trouve que les outils existants pour cela sont tres orientés "Internet"... mais dans mon domaine d'activité, comme on a bcp d'interaction avec l'utilisateur ca serait un peu delicat a mettre en oeuvre..

V

[hegros]

ok, des tests de verifs automatiques. Je me suis renseigné et je trouve que les outils existants pour cela sont tres orientés "Internet"... mais dans mon domaine d'activité, comme on a bcp d'interaction avec l'utilisateur ca serait un peu delicat a mettre en oeuvre..

V

je ne suis pas sûr de te comprendre..il ne s'agit à aucun moment de tester toutes les interactions avec l'utilisateur, il s'agit de couvrir des fonctions qui permettront de dire à l'utilisateur/client final "on accepte le produit"

D'autant plus qu'un test d'acceptance peut aussi être écrit de la même façon qu'un test unitaire à la différence qu'il se concentre purement sur ce qu'attends l'utilisateur/client final à contrario d'un test unitaire (qui n'est pas un test d'acceptance) C'est clair ce que je dis ?


Pour revenir sur le cycle en V, même si ce n'est pas le fond du sujet, j'ai travaillé pendant une période dans l'industrie médicale et d'après les meilleures pratiques de cette industrie il n'y avait pas autant de documentation à fournir (je me rappelle même d'une pratique d'ingénierie logicielle dans le médical qui stipulait 'aucune documentation')

Donc attention, V est un modèle de développement pas un cycle de vie logiciel.

[vdaanen]

je ne suis pas sûr de te comprendre..il ne s'agit à aucun moment de tester toutes les interactions avec l'utilisateur, il s'agit de couvrir des fonctions qui permettront de dire à l'utilisateur/client final "on accepte le produit"

oui mais quasiment toutes les fonctions requièrent une interaction utilsateur. Quand bien meme des fonctions ne necessitent pas d'interaction (on en a quelques unes), elles sont critiques et necessitent un controle utilisateur pour valider/invalider le resultat (gestion des risques patients...)

D'autant plus qu'un test d'acceptance peut aussi être écrit de la même façon qu'un test unitaire à la différence qu'il se concentre purement sur ce qu'attends l'utilisateur/client final à contrario d'un test unitaire (qui n'est pas un test d'acceptance) C'est clair ce que je dis ?

Oui. J'avais commencé a réfléchir a ca mais les seules solutions que j'ai trouvées sont un peu trop intrusives a mon gout. Mais je cherche...

Pour revenir sur le cycle en V, même si ce n'est pas le fond du sujet, j'ai travaillé pendant une période dans l'industrie médicale et d'après les meilleures pratiques de cette industrie il n'y avait pas autant de documentation à fournir (je me rappelle même d'une pratique d'ingénierie logicielle dans le médical qui stipulait 'aucune documentation')

Alors ca j'aimerai bien en savoir plus sur cette pratique. Dans toutes les experiences que j'ai pu avoir, on devait prouver qu'on avait des etapes de specifications et redaction de TP avant de coder. C'est surtout la FDA (organisme qui te donne l'autorisation de proposer ton dispositif medical aux US) qui exige ca

Donc attention, V est un modèle de développement pas un cycle de vie logiciel.

je vais lire ca ...

V

[souviron34]

C'est surtout la FDA (organisme qui te donne l'autorisation de proposer ton dispositif medical aux US) qui exige ca

Je ne savais pas qu'ils avaient gardé ça... J'ai bossé pour un soft comme ça (soft de contrôle d'une machine d'IRM) il y a maintenant un peu plus de 20 ans et c'était le cas à l'époque..

Visiblement ils ont un temps de réaction pour le moins.. lent..


Et je trouve qu'en particulier les documents de conception détaillée et de tests unitaires sont absurdes...


Comme je l'ai cité dans un autre thread, l'ingénieur bio-médical responsable de l'agrément AP à l'époque m'avait donné un conseil (et c'est comme ça qu'il avait testé le soft chez nous) :

Déjà passer 2 jours à cliquer, taper sur le clavier, etc, sans regarder l'écran...

Il m'avait dit "si on passe ça, on a déjà passé 70%"...



Après, le test de la fonctionalité...

Mais je trouve aberrant que a FDA n'ait pas modifé ses demandes, en particulier par rapport aux tests unitaires et conceptions détaillées..

En 28 ans de carrière, je n'ai JAMAIS vu un tel document à jour et/ou significatif...

Comme tu le signales, il est aberrant de fournir un document pour la fonction toto qui fait a+b.. Sur de gros logiciels, le nombre de telles fonctions est tel, et leur simplicité est telle, que la masse de papier générée est forcément INUTILISEE et SANS SIGNIFICATION aucune...



Maintenant, par rapport à la question que tu soulèves, j'avoue que je ne vois pas bien comment cela serait possible :

• Pour les fonctions liées à l'IHM, comment à partir du code déduire un comportement "aberrant" de la part de l'utilisateur ???
  
  
• Pour ces mêmes fonctions, comment à parir du code déduire des tests "asynchrones", c'est à dire correspondants aux clics "aléatoires" de l'utilisateur ? (par "aléatoire j'entend qui interrompent tel traitement pour basculer sur tel autre)
  
  
• Pour des fonctions non-liées à l'IHM comment à partir du code déduire des tests si par exemple on a affaire à des tableaux de taille non définie ?
  
  
• Pour des fonctions non-liées à l'IHM comment à partir du code déduire des tests si par exemple on a affaire à des mécanismes style callbacks, ou à des événements style arrivée d'un signal (sur un socket ou autre) ?

Enfin, en remarque, j'avoue que je reste très perplexe quand je lis

oui mais quasiment toutes les fonctions requièrent une interaction utilsateur. Quand bien meme des fonctions ne necessitent pas d'interaction (on en a quelques unes), elles sont critiques et necessitent un controle utilisateur pour valider/invalider le resultat (gestion des risques patients...)

Je pense qu'il y a dans ce logiciel un problème de conception fondamentale... Si 90% du soft est basé sur l'IHM, ou alors ce n'est qu'un logiciel de présentation de données, mais sinon cela me semble aberrant et signe d'une (très très) mauvaise conception...

Qu'advient-il si quelqu'un (un client, le marketing, le DI) décide de changer d'outil de visualisation ?????

[jabbounet]

Déjà passer 2 jours à cliquer, taper sur le clavier, etc, sans regarder l'écran...

Il m'avait dit "si on passe ça, on a déjà passé 70%"...

schlarf test?
C'est le nom que donnais un ancien collègue a ce type de test en raison du bruit du clavier quand on pose tous ses doigt a peu près en même temps dessus.

[souviron34]

schlarf test?
C'est le nom que donnais un ancien collègue a ce type de test en raison du bruit du clavier quand on pose tous ses doigt a peu près en même temps dessus.

: voui pkoi pas ?

Moi j'appelle ça "crash test", parce que c'est relativement immanquable qu'on crashe un certain nombre de fois...

Mais c'est réellement très très très efficace...

Parce qu'une fois qu'on est sûr de la robustesse de ce type, tester la fonctionalité c'est très nettement plus facile....

Mais en général quand on développe on fait plutôt à l'envers.. Et d'ailleurs il ne prend son sens que quand tout est "prêt" et branché..

[vdaanen]

Je ne savais pas qu'ils avaient gardé ça... J'ai bossé pour un soft comme ça (soft de contrôle d'une machine d'IRM) il y a maintenant un peu plus de 20 ans et c'était le cas à l'époque..

Visiblement ils ont un temps de réaction pour le moins.. lent..


Et je trouve qu'en particulier les documents de conception détaillée et de tests unitaires sont absurdes...


Comme je l'ai cité dans un autre thread, l'ingénieur bio-médical responsable de l'agrément AP à l'époque m'avait donné un conseil (et c'est comme ça qu'il avait testé le soft chez nous) :

Déjà passer 2 jours à cliquer, taper sur le clavier, etc, sans regarder l'écran...

Il m'avait dit "si on passe ça, on a déjà passé 70%"..

Après, le test de la fonctionalité...

Mais je trouve aberrant que a FDA n'ait pas modifé ses demandes, en particulier par rapport aux tests unitaires et conceptions détaillées..

En 28 ans de carrière, je n'ai JAMAIS vu un tel document à jour et/ou significatif...

Comme tu le signales, il est aberrant de fournir un document pour la fonction toto qui fait a+b.. Sur de gros logiciels, le nombre de telles fonctions est tel, et leur simplicité est telle, que la masse de papier générée est forcément INUTILISEE et SANS SIGNIFICATION aucune... .

Et oui ..
Je pense que c'est un travers des guidelines edités par la FDA. Ces guidelines concernent tout les dispositifs pour la santé, que ce soit médicaments ou appareil d'imagerie ou autres. Nous sommes dans un cas particulier mais on est tombé sur la case "radiology" donc on doit avoir un dossier équivalent a un échographe (c'est ce dont on s'approche le +) alors qu'on ne fait que de la visu de données ...

Maintenant, par rapport à la question que tu soulèves, j'avoue que je ne vois pas bien comment cela serait possible :

• Pour les fonctions liées à l'IHM, comment à partir du code déduire un comportement "aberrant" de la part de l'utilisateur ???
  
  
• Pour ces mêmes fonctions, comment à parir du code déduire des tests "asynchrones", c'est à dire correspondants aux clics "aléatoires" de l'utilisateur ? (par "aléatoire j'entend qui interrompent tel traitement pour basculer sur tel autre)
  
  
• Pour des fonctions non-liées à l'IHM comment à partir du code déduire des tests si par exemple on a affaire à des tableaux de taille non définie ?
  
  
• Pour des fonctions non-liées à l'IHM comment à partir du code déduire des tests si par exemple on a affaire à des mécanismes style callbacks, ou à des événements style arrivée d'un signal (sur un socket ou autre) ?

Tout ce qui est GUI est testé par des utilisateurs humains. Mes propos se limitent aux composants unitaires qui peuvent etre testés par de TU automatisés..



Enfin, en remarque, j'avoue que je reste très perplexe quand je lis

Je pense qu'il y a dans ce logiciel un problème de conception fondamentale... Si 90% du soft est basé sur l'IHM, ou alors ce n'est qu'un logiciel de présentation de données, mais sinon cela me semble aberrant et signe d'une (très très) mauvaise conception...

Qu'advient-il si quelqu'un (un client, le marketing, le DI) décide de changer d'outil de visualisation ?????

en fait, chez nous on ne change pas d'outil de visu ! On fabrique des dispositifs medicaux donc on vend un systeme complet (PC/soft) qui permet de visualiser des données medicales en manière "augmentée". Le client ne peut rien changer.
Bien sur, derriere la visu, il y a bcp de calculs ,etc mais c'est totalement invisible pour le client. Lui a juste a regarder des images et entrer quelques données..

V

[souviron34]

en fait, chez nous on ne change pas d'outil de visu ! On fabrique des dispositifs medicaux donc on vend un systeme complet (PC/soft) qui permet de visualiser des données medicales en manière "augmentée". Le client ne peut rien changer.

je ne parlais pas de ça...

Je parlais : vous avez développé un soft pendant X mois / années avec un outil graphique Y.

Vraisemblablement environ 90% de la fonctionalité que vous fournissez peut se faire avec un autre outil graphique Z... (par exemple sous Linux avec X11alors que l'original est avec ... sous Win) (et même si c'était avec le même (comme Java) des 2 côtés)...

Ce qui veut dire que ces 90% sont le coeur de votre savoir-faire, et indépendants de la plateforme et de l'outil graphique ... (par exemple comme un moteur physique.. quand tu parles "réalité augmentée", il y a vraisemblablement l'équivalent..)

D'où mon questionnement....


Mais, si vous en êtes contents, tant mieux pour vous...

[hegros]

Alors ca j'aimerai bien en savoir plus sur cette pratique.

J'avoue ne plus me souvenir du nom que porte cette 'bibliothèque/norme' de best practice qui a été établie par des médecins et qui est spécifique au développement logiciel dans le milieu médical/pharmaceutique. Il faudrait faire une recherche la dessus dans ce sens...


Mais comme le dit un peu Souviron, la raison de cette pratique vient probablement du fait que les documentations sont dans 90% des cas incomplète, pas mise à jour, inexacte et/ou non significatif et d'autant plus difficile à maintenir à jour.

[vdaanen]

je ne parlais pas de ça...

Je parlais : vous avez développé un soft pendant X mois / années avec un outil graphique Y.

Vraisemblablement environ 90% de la fonctionalité que vous fournissez peut se faire avec un autre outil graphique Z... (par exemple sous Linux avec X11alors que l'original est avec ... sous Win) (et même si c'était avec le même (comme Java) des 2 côtés)...

Ce qui veut dire que ces 90% sont le coeur de votre savoir-faire, et indépendants de la plateforme et de l'outil graphique ... (par exemple comme un moteur physique.. quand tu parles "réalité augmentée", il y a vraisemblablement l'équivalent..)

D'où mon questionnement....


Mais, si vous en êtes contents, tant mieux pour vous...

Effectivement mais je pense que tu sais que dans une entreprise, soit on veut etre multiplateforme, etc ou on choisit une plateforme pour une raison x ou y et on developpe dessus. On est dans ce 2eme cas. A tort ou a raison, l'avenir le dira ...

[vdaanen]

J'avoue ne plus me souvenir du nom que porte cette 'bibliothèque/norme' de best practice qui a été établie par des médecins et qui est spécifique au développement logiciel dans le milieu médical/pharmaceutique. Il faudrait faire une recherche la dessus dans ce sens...


Mais comme le dit un peu Souviron, la raison de cette pratique vient probablement du fait que les documentations sont dans 90% des cas incomplète, pas mise à jour, inexacte et/ou non significatif et d'autant plus difficile à maintenir à jour.

Je vois un autre pb a cette pratique : qui dit absence de doc dit impossible de faire evoluer a moins de passer a chaque fois un temps important a re-comprendre ce qui a ete fait...

Bref, ca ne me semble pas vraiment viable tant pour obtenir les certifs que pour la perenité de l'entreprise ou du produit.

V

[hegros]

Je vois un autre pb a cette pratique : qui dit absence de doc dit impossible de faire evoluer a moins de passer a chaque fois un temps important a re-comprendre ce qui a ete fait...

Il y en a forcément un minimum, l'idée derrière le 'aucune documentation' je pense que c'est cela un minimum (moins plutôt que plus). Le problème va être qu'est-ce qui est minimum et suffisant ? On va se dire c'est du gros lourd logiciel alors il faut des pavés de 10000pages et dans ce cas on retombe dans le travers de la documentation.

Ce qui importe vraiment pour comprendre ce n'est pas vraiment la documentation c'est plutôt les formations et le transfert de connaissance

Bref, ca ne me semble pas vraiment viable tant pour obtenir les certifs que pour la perenité de l'entreprise ou du produit.

Dans les méthodes agiles la documentation n'est pas une des premières préoccupations (voir le manifesto agile) car dans l'absolu un logiciel bien conçu(design, ergonomie, navigabilité,...) devrait être facile à apprendre, à utiliser et intuitif.

On devrait pouvoir en grande partie et la majorité du temps se passer de la documentation (je vois mal un médecin ouvrir une documentation en pleine opération chirurgicale pour retrouver une fonction du logiciel dont il a besoin)

[souviron34]

Tout ce qui est GUI est testé par des utilisateurs humains. Mes propos se limitent aux composants unitaires qui peuvent etre testés par de TU automatisés..

tu n'as pas répondu aux points que je soulevais :

• Pour les fonctions liées à l'IHM, comment à partir du code déduire un comportement "aberrant" de la part de l'utilisateur ???
  
  
• Pour ces mêmes fonctions, comment à parir du code déduire des tests "asynchrones", c'est à dire correspondants aux clics "aléatoires" de l'utilisateur ? (par "aléatoire j'entend qui interrompent tel traitement pour basculer sur tel autre)
  
  
• Pour des fonctions non-liées à l'IHM comment à partir du code déduire des tests si par exemple on a affaire à des tableaux de taille non définie ?
  
  
• Pour des fonctions non-liées à l'IHM comment à partir du code déduire des tests si par exemple on a affaire à des mécanismes style callbacks, ou à des événements style arrivée d'un signal (sur un socket ou autre) ?

[vdaanen]

tu n'as pas répondu aux points que je soulevais :

tu n'as pas répondu aux points que je soulevais :

uhm.... je ne sais pas.. Je ne me suis pas encore posé ces questions...

Mais il y a peut-etre une non-comprehension de ma presentation initiale : comme je l'ai ecrit dans le post initial, mon idée etait de parser un code source documenté (a la javadoc par exemple) et d'en deduire le TestPlan .

Par exemple le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
/** @TEST_CASE 1-1
*    @DESCRIPTION Read file <linebreak> Fill Model from file
*    @NEEDS Data/ModelFile.dat
*    @EXPECTED_RESULT Model.NbVertices = 8
*                                  Model.Vertices[0] = Point3D(-1.,-1,-1)
*/

permettrait de créér un tableau (désolé pour le rendu)..

Test Case Id | Description | Needs |Expected Result
------------------------------------------------------------------------------------------------------------
1-1 |Read file | Data/Modelfile.dat |Model.NbVertices = 8
|Fill Model from file | |Model.Vertices[0] = Point3D(-1.,-1,-1)
------------------------------------------------------------------------------------------------------------

V

[vdaanen]

Il y en a forcément un minimum, l'idée derrière le 'aucune documentation' je pense que c'est cela un minimum (moins plutôt que plus). Le problème va être qu'est-ce qui est minimum et suffisant ? On va se dire c'est du gros lourd logiciel alors il faut des pavés de 10000pages et dans ce cas on retombe dans le travers de la documentation.

effectivement. L'idée est qu'il vaut mieux une documentation synthétique et bien faite plutot que doc exhaustive mais incomprehensible.

Ce qui importe vraiment pour comprendre ce n'est pas vraiment la documentation c'est plutôt les formations et le transfert de connaissance

oui mais malheureusement, on ne prévoit pas de temps pour le transfert de connaissance et la formation a certaines parties du code (tout passe par des discussions qd il y a un bug ou un comportement que quelqu'un ne comprend pas) dans nos projets et on se retrouve a avoir un code sur lequel une seule personne peut intervenir, ce qui est dangereux finalement..

Dans les méthodes agiles la documentation n'est pas une des premières préoccupations (voir le manifesto agile) car dans l'absolu un logiciel bien conçu(design, ergonomie, navigabilité,...) devrait être facile à apprendre, à utiliser et intuitif.

On devrait pouvoir en grande partie et la majorité du temps se passer de la documentation (je vois mal un médecin ouvrir une documentation en pleine opération chirurgicale pour retrouver une fonction du logiciel dont il a besoin)

Je ne suis pas sur qu'on entende la meme chose par documentation.
En ce qui me concerne, la doc ce sont les documents de spec, TP et .. TR.

Le manuel utilisateur est ailleurs car la, ca passe effectivement par la formation des utilisateurs

V

[hegros]

effectivement. L'idée est qu'il vaut mieux une documentation synthétique et bien faite plutot que doc exhaustive mais incomprehensible.

Reste à définir synthétique mais dans l'idée je pense que c'est plus un minimum (donc quasiment rien 'zéro documentation')qu'une doc synthétique

oui mais malheureusement, on ne prévoit pas de temps pour le transfert de connaissance et la formation a certaines parties du code (tout passe par des discussions qd il y a un bug ou un comportement que quelqu'un ne comprend pas) dans nos projets et on se retrouve a avoir un code sur lequel une seule personne peut intervenir, ce qui est dangereux finalement..

Je parle de la formation des gens du métiers (MOA/utilisateur) sur l'utilisation du produit pas des gens de l'informatique sur le code.

Je ne suis pas sur qu'on entende la meme chose par documentation.
En ce qui me concerne, la doc ce sont les documents de spec, TP et .. TR.

Le manuel utilisateur est ailleurs car la, ca passe effectivement par la formation des utilisateurs

Je parle de toutes les documentations (hors gestion de projet (donc sans inclure l'assurance qualité)) des specs jusqu'à la doc utilisateur