Discussion :

[vdaanen]

Bonjour,

interessant ce debat ...

je ne suis pas d'accord avec toi sur quelques points :

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

Avec 0 doc, comment savoir ce que fait un composant ? En relisant le code ? ayant du faire ca plusieurs fois, je trouve cela anti-productif.
Sans compter qu'on peut tester tout et n'importe quoi et a la limite rien car la fonctionnalité n'est pas expliquée, meme succinctement !

Pour moi, une doc succincte, c'est "Ca doit faire ceci".
si la conception est un peu complexe, quelques diagrammes pour eclairer
et de la on tire le TP (soit papier, soit en direct...)

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.

Pas d'accord non plus. La formation des personnes sur le code est indispensable car on met en peril la societe : quid si la seule personne compétente sur un code (un framework propriétaire par exemple) s'en va. On ne va pas demander au client comment ca marche le jour ou il faut faire une modif ou fixer un bug.

J'ai d'autres exemples issues de mon boulot qui sont aussi "graves"....

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

Les specs/TP/TR (fonctionnelles, techniques, d'archi et U) font partie de la doc d'AQ (au moins dans mon domaine) et sont des livrables du projet tout comme le manuel utilisateur et l'analyse de risque.
Dans le domaine medical, tu dois prouver que tu sais ce que tu dois faire, que tu as analysé les risques patient et utilisateur et matériel et que chaque risque est géré à un niveau de la conception... Toutes les docs citées supra concourent a cela

[hegros]

Avec 0 doc, comment savoir ce que fait un composant ? En relisant le code ? ayant du faire ca plusieurs fois, je trouve cela anti-productif.
Sans compter qu'on peut tester tout et n'importe quoi et a la limite rien car la fonctionnalité n'est pas expliquée, meme succinctement !

Parce que tu ne penses pas fonctionnel. Un composant c'est plutôt technique et un client/utilisateur final n'a que peu d'intérêt de comment marche la mécanique interne et il n'ira surement pas lire le code de toute évidence.

Pas d'accord non plus. La formation des personnes sur le code est indispensable car on met en peril la societe : quid si la seule personne compétente sur un code (un framework propriétaire par exemple) s'en va. On ne va pas demander au client comment ca marche le jour ou il faut faire une modif ou fixer un bug.

Là encore ce sont des questions de pratiques. Il n'y a pas à former le personnel sur le code, c'est tout simplement scandaleux. En suivant XP, le code est une propriété collective donc on casse le problème du super développeur qui est le seul à connaître comment marche un composant et on évite toutes les contraintes que tu cites.

Les specs/TP/TR (fonctionnelles, techniques, d'archi et U) font partie de la doc d'AQ (au moins dans mon domaine) et sont des livrables du projet tout comme le manuel utilisateur et l'analyse de risque.

Pas du tout ou alors donne nous une référence la dessus. Il ne faut pas confondre le processus de fabrication (incluant les doc de spec, archi,..) et le processus d'orchestration/pilotage (incluant les doc comme les revues d'assurance qualité, la planification,...) Souvent les 2 sont mélangés alors que se sont 2 processus différents.

Toutes les docs citées supra concourent a cela

Tu peux en être toi convaincu, pour ma part je n'en suis pas du tout convaincu.

[vdaanen]

Slt,

Parce que tu ne penses pas fonctionnel. Un composant c'est plutôt technique et un client/utilisateur final n'a que peu d'intérêt de comment marche la mécanique interne et il n'ira surement pas lire le code de toute évidence.

Je pense fonctionnel et technique, puisque c'est mon activité principale de faire les 2..

Fonctionnel car les utilisateurs me decrivent grosso-modo la (les) fonctionnalité(s) qu'il souhaitent voir ajouter dans nos produits.
Mais qd je dois ecrire un composant qui va permettre de realiser une partie d'une fonctionnalité demandée, le document décrivant ce composant contient une description fonctionnelle succincte (aide-mémoire) et des points techniques qd le composant "complexe" (calcul, organisation des données, etc..). C'est descriptions sont rédigées non pas comme spec mais comme aide-mémoire. Il me semble que dans le Manifeste Agile, on préfère documenter le code...

Là encore ce sont des questions de pratiques. Il n'y a pas à former le personnel sur le code, c'est tout simplement scandaleux. En suivant XP, le code est une propriété collective donc on casse le problème du super développeur qui est le seul à connaître comment marche un composant et on évite toutes les contraintes que tu cites.

Je pense que ce n'est pas toujours applicable :
par exemple ce cas vecu : une partie de notre techno a ete developpée par un thésard. D'abord c'etait de la faisabilité et ensuite ca s'est complexifié au fur et a mesure qu'il ajoutait des fonctionnalités utiles pour nos produits, il y a un de grande passe de refactoring et de remise a plat du design.
On ne pouvait pas lui demandé de communiquer sur son archi/implementation tous les 8 ou 15 j d'une part. D'autre part, c'etait son boulot, de notre coté, on avait autre chose a faire que d'aller voir son code pour que la propriété soit collective sachant que ca allait probablement changer dans les mois a venir (l'architecture de ce noyau technologique a ete stabilisé assez tardivement)

Pas du tout ou alors donne nous une référence la dessus. Il ne faut pas confondre le processus de fabrication (incluant les doc de spec, archi,..) et le processus d'orchestration/pilotage (incluant les doc comme les revues d'assurance qualité, la planification,...) Souvent les 2 sont mélangés alors que se sont 2 processus différents.

* Norme EN 62304 concernant le cycle de vie des logiciels des dispositifs médicaux -> c'est au fabricant d'assurer que la documentation est en conformité avec le code (en gros ne pas avoir une spec v1.0 et un composant qui fait des choses totalement differentes...). Le terme documentation comprend Spec fonctionnelle, SDS (System Design Spec), Test Plan et ceci a tous les niveaux, notamment "Brique logicielle" qui est le niveau le plus bas (donc composant unitaire)

* Guidelines pour l'accreditation CE ou FDA : selon la classe du systeme ( =dangerosité pour le patient + d'autres critères), tu dois mettre dans le dossier que tu envoies aux agences les documents de conception/validation a tous niveaux (c'est surtout valable pour la FDA) cad ici encore les composants unitaires. Je ne te cache pas que les dossiers peuvent etre tres gros ....

Concernant le doc de revue, la planification, etc.. ca s'est demandé pour etre iso 13485 (iso 9001 "medical")

Tu peux en être toi convaincu, pour ma part je n'en suis pas du tout convaincu.

Comme je l'ai ecrit au dessus, ces docs fonct parties de docs demandées lors d'un depot de dossier. Cela ne releve pas de notre decision, c'est plutot quelque chose qu'on subit ....

V

[souviron34]

@hegros :

d'où ma remarque plus haut sur le fait que la FDA n'avait pas évolué. Il y a 20 ans il fallait déjà fournir ça, de manière obligatoire...

Et d'où ma remarque que c'est totalement inutile - à part le fait que ton dossier soit examiné - car je met ma main à couper que personne (y compris à la FDA) ne lit ces documents....

[hegros]

Je pense fonctionnel et technique, puisque c'est mon activité principale de faire les 2..

Je pense technique pour le fonctionnel pas technique pour la technique bien qu'aujourd'hui j'ai plutôt les 2 casquettes.

Il me semble que dans le Manifeste Agile, on préfère documenter le code...

Non pas du tout en plus tu n'as pas de chance je suis plutôt contre les commentaires dans le code (Souviron se rappellera des échanges que l'on a eu la dessus )

Sinon une documentation sous forme d'aide mémoire comme tu le décris j'aime bien tout comme j'aime bien les CRC card et ce genre de documentation synthétique et très pratique. Donc tu marques un point au moins la dessus. (remarque qu'avec moi c'est dur de marquer des bons points )


@Souviron

Je suis plutôt d'accord avec toi surtout que je me demande bien comment ces organismes font pour vérifier la concordance entre toute cette documentation et le code avec les potentielles mises à jour régulières suite à la découverte de bug. Sans compter les coûts que cela engendre sachant que tout écart entre documentation/code n'a pas forcément un impact significatif.

[ben_ghost]

En suivant le fil de discutions, je me rend compte que ta question est peut être mal interpréter ou mal posée.

Le premier point à voir est de pas comparer les tests Unitaire qui sont eux lié aux code aux test système qui sont liés au règle métier car des tests de niveau différent.

Si les tests unitaires sont bien fait du verra peu de bug dû a un aspect technique par contre il sera toujours possible de voir des bug lié à la situation de test, en gros ça veut dire qu'un test exécuté 2 fois pet donner 2 résultat différent d'où l'importance des tests systèmes.

Tout professionnel du test te le dira : les tests systèmes et plus précisément test fonctionnel doivent être effectué de façon manuel pour une qualité optimal.
Un ordinateur n'est de toute façon pas capable d'intrépreter des résultats de façon autonome.

Quand je parle de test fonctionnel, j’entends les nouvelles fonctionnalités et non les anciennes. car dans ce cas il s'agit de test de non-régression. Qui eux peuvent être automatiser en partant des scénarios déjà exécuté (et dit passant).

Si tu veux automatisé la création des reports, il te faut un référentiel de test qui en règle générale possède cette fonction.

Ensuite j'aimerais revenir sur cette citation :

Citation:
Envoyé par vdaanen Voir le message

Pas d'accord non plus. La formation des personnes sur le code est indispensable car on met en peril la societe : quid si la seule personne compétente sur un code (un framework propriétaire par exemple) s'en va. On ne va pas demander au client comment ca marche le jour ou il faut faire une modif ou fixer un bug.
Là encore ce sont des questions de pratiques. Il n'y a pas à former le personnel sur le code, c'est tout simplement scandaleux. En suivant XP, le code est une propriété collective donc on casse le problème du super développeur qui est le seul à connaître comment marche un composant et on évite toutes les contraintes que tu cites.

je pense que vous avez 2 visions différentes mais que les 2 ne sont pas forcément mauvaise.

En fait, il s'agit tout simplement d'une organisation, car si un développeur créer une bibliothèque (ou framework) il doit la documenter pour permettre sa réutilisation. Après c'est une habitude à prendre que peu de développeur ont. (je suis désolé de le dire, mais c'est mon vécu)
Si cette organisation est bien maintenu, la formation sur l'architecture du code, ainsi que sur les normes de codage a appliqué obligatoire sera plus aisée. Cette organisation doit être respecté quelque soit la méthode (XP ou non)
Dire ensuite que c'est scandaleux est à mon avis un peu extréme car une formation reste toujours obligatoire quelque soit la méthode, si pas d'accompagnement, le développeur pourra éventuellement faire tout et n'importe quoi, c'est au final contre productif pour l'ensemble du projet. Il faut toujours une période d'essai pour voir si celui-ci respect la méthode.

[hegros]

Le premier point à voir est de pas comparer les tests Unitaire qui sont eux lié aux code aux test système qui sont liés au règle métier car des tests de niveau différent.

Cette citation n'est pas très claire. Un test unitaire, aujourd'hui, est un abus de langage lequel désigne tous les niveaux de tests mais de façon automatisé(test unitaire, intégration, système, fonctionnel, non-régression performance, sécurité etc...)

Tout professionnel du test te le dira : les tests systèmes et plus précisément test fonctionnel doivent être effectué de façon manuel pour une qualité optimal.

Est-ce que tu pourrais citer nominativement les noms de ces professionnels ? Parce que je me considère suffisamment pro, et travailler avec des équipes de tests pro, pour dire le contraire notamment dans ma carrière j'ai toujours vu des organisations avec des objectifs comme 70% de tests automatisés (incluant du fonctionnel autant le plus) C'est plutôt les tests systèmes qui ne sont pas aussi facilement automatisable par contre et nécessite des techniques différentes

Cette organisation doit être respecté quelque soit la méthode (XP ou non)

Ah bon depuis quand ? Je te rappelle quand même que c'est la méthode qui détermine justement l'organisation donc si la méthode dit on se moque de la documentation (parce qu'une équipe est peut-être dédié à cela (j'entends équipe de documentaliste pas informaticien)) alors on ne documente pas et/ou on ne respecte aucune norme de codage spécifique (qui en passant est réalisé par un large panel de plugins intégrables dans des EDI)

Quand à la formation sur le code, une fois de plus, c'est une question de pratique car si tu intègres une personne en période d'essai dans une équipe pratiquant XP alors la personne, par les techniques de XP comme le binomage entre autre, se formera sans pour autant qu'on lui fasse une formation dédiée

[ben_ghost]

Cette citation n'est pas très claire. Un test unitaire, aujourd'hui, est un abus de langage lequel désigne tous les niveaux de tests mais de façon automatisé(test unitaire, intégration, système, fonctionnel, non-régression performance, sécurité etc...)

Mouais c'est vrai quand relisant je suis pas super clair
il y a 4 niveaux : unitaire, intégration, système, acceptance. Les tests fonctionnelle ou de non-régression sont des types de test (et non des niveaux). Les tests unitaires sont les premiers tests a être lancer avant même l'intégration. Et donc on ne peut les confondre avec des tests fonctionnels qui eux doivent vérifié les contraintes fonctionnelles et éventuellement métiers. Le fait qu'il sois automatisé est qu'il peuvent être exécuté de façon automatique. (ceci dit j'ai vu des développeurs les faire manuellement ... sisi mais bon c'est pas très productifs et les temps de livraisons sont donc bcp plus long) Les tests unitaires sont en règles générales à la responsabilité des développeurs. Il faut bien pensé que c'est un outil pour eux. une grande couverture (au moins > 70%) est souvent conseillé pour ce domaine. Maintenant je ne suis pas expert dans ce domaine mais j'en ai souvent constaté les bienfaits chez mes différents clients.
j'insiste sur le fait qu'il ne faut pas confondre les tests unitaires avec les tests fonctionnels, c'est la dessus que les développeurs ont tendance a avoir une confusion, le but de ces tests sont complétement différents.

Est-ce que tu pourrais citer nominativement les noms de ces professionnels ? Parce que je me considère suffisamment pro, et travailler avec des équipes de tests pro, pour dire le contraire notamment dans ma carrière j'ai toujours vu des organisations avec des objectifs comme 70% de tests automatisés (incluant du fonctionnel autant le plus) C'est plutôt les tests systèmes qui ne sont pas aussi facilement automatisable par contre et nécessite des techniques différentes

Relis mon post tu aurais vu aussi que je différencie les tests de non-régression (sous entendu fonctionnel) et les tests fonctionnels (qui sont je le répetes 2 type de test différent). si tu veux testé une nouvelle fonctionnalité il faut toujours en premier la faire manuellement (j'insiste la-dessus) ensuite si la stratégie de test de la livraison n+1 indique de l'inclure comme non-régression alors il doit être automatisé. Mais tu ne peux automatisé un test qui est failed car il y a gros risque de revenir dessus.
Maintenant je suis d'accord avec toi, plus il y a de test de non-régression, mieux c'est. Mais il faut aussi penser à la maintenabilité des tests automatisés. Et ça, ça dépend des développeur. D'où l'accompagnement sur les normes. Car pour automatisé une application il faut avoir des critères de description "programmé" qui sont en règle générales sélectionné par les normes de codage. Si un développeur n’est pas formé sur ce sujet ou du moins accompagné (ce terme est plus approprié que formé) sur le sujet, la maintenabilité des test automatisé fonctionnel peut devenir trop forte et donc moins rentable que des tests manuels.
C'est pourquoi, j'insiste sur le fait qu'un accompagnement doit toujours être effectué. (voir aussi le prochain bloc qui est indirectement lié)

on ne documente pas et/ou on ne respecte aucune norme de codage spécifique (qui en passant est réalisé par un large panel de plugins intégrables dans des EDI)

As tu déjà entendu de parlé d'accesiweb ? ou de W3C ? ce sont des normes (ce sont pas vraiment des normes mais bon c'est kifkif) qui peuvent ou non être respecté.
Si tu ne respectes pas ses normes cela veux dire que tu ne respect pas éventuellement les contraintes externes. Maintenant je vois que tu as mis "et/ou" ça veut dire que vous pouvez éventuellement les respecté et donc si une personne vient dans une équipe, il faut lui dire non? ou alors il doit les deviner ? c'est pourquoi je parle d'accompagnement et non forcément de formation ou alors tu considère que ce doit être les testeurs de détecter ces problèmes et ensuite de les remonter comme ano. Dans ce cas c'est couteux car plus l'ano est découverte tard plus elle est couteuse...
Maintenant si tu n'as pas de contrainte externe de ce type, je dirais tant mieux mais mon discourt est générale et non spécifique, si pas de norme, dans ce cas, pas de formation (ça parait logique même si je serais curieux de voir ça mais je suis pas forcément contre l'idée).

Le test aux sens large, est un métier à part entière. il est impacté et impact la méthode de travail. il ne faut pas penser que la qualité d'un produit et issu seulement du service qualité, la qualité doit se mesuré sur tout les processus de fabrication.

@ hegros

Es tu développeur ?

[hegros]

il y a 4 niveaux : unitaire, intégration, système, acceptance. Les tests fonctionnelle ou de non-régression sont des types de test (et non des niveaux).

En disant cela tu t'appuies sur le modèle en V nous sommes d'accord ou alors il est nécessaire que tu précises en donnant une référence d'où tu tiens cette hiérarchisation et ce découpage des tests.

Si c'est le cas, que tu t'appuies sur le modèle en V, sache alors que les tests fonctionnelles sont un niveau au même titre que unitaire, intégration, système et acceptance. Les tests qui ne sont pas des niveaux c'est effectivement les tests de non-régression ou de performance par exemple.

j'insiste sur le fait qu'il ne faut pas confondre les tests unitaires avec les tests fonctionnels, c'est la dessus que les développeurs ont tendance a avoir une confusion, le but de ces tests sont complétement différents.

Justement c'est un abus de langage. Tu différencies les 2 parce que tu te calques, à priori, sur un modèle en V. Si tu prends la suite Microsoft Test, par exemple, tu verras que les tests fonctionnelles(enregistré par script pendant la navigation écran par exemple), peuvent génèrer des 'tests unitaires' si on le souhaite. La différence est que ce test unitaire est en fait un test fonctionnel car dans le code tu vas voir ce qu'il faut pour cliquer sur les zones qui vont bien dans l'écran, saisir des valeurs dans les cases etc...

Dis cela, je préfère parler de tests en boîte blanche pour ce que tu appelles test unitaire et parler de tests en boîte noir pour ce que tu appelles les tests fonctionnelles.

Mais nous sommes d'accord les tests unitaires, dans le sens plus bas niveau en boîte blanche, ne sont pas des tests fonctionnels.

Je te rejoins aussi quand tu dis que c'est un métier à part entière qui a aussi son langage à lui (et qui porte assez à confusion je le reconnais)

Maintenant je suis d'accord avec toi, plus il y a de test de non-régression, mieux c'est.

Je ne vois pas où j'ai écris cela mais je suis d'accord avec toi aussi

C'est pourquoi, j'insiste sur le fait qu'un accompagnement doit toujours être effectué. (voir aussi le prochain bloc qui est indirectement lié)

Nous sommes d'accord la meilleure façon d'écrire des tests est de le faire en binôme au moins.

As tu déjà entendu de parlé d'accesiweb ? ou de W3C ? ce sont des normes (ce sont pas vraiment des normes mais bon c'est kifkif) qui peuvent ou non être respecté.

Il ne faut pas confondre norme et méthode c'est complètement différent. Je parle de méthode quand toi tu parles de normes. Il n'y a aucune norme à ma connaissance qui t'oblige à documenter un produit web d'un point de vue fonctionnel ou technique par contre tu as des normes(W3C par exemple) qui te donnent une direction sur l'implémentation à avoir pour être compatible mais W3C ne te dit pas de documenter les fonctions de ton produit web ou même de commenter ton code(quoique un contre exemple serait bienvenue).

Es tu développeur ?

oui enfin plutôt super développeur.

[vdaanen]

Bonjour,

En suivant le fil de discutions, je me rend compte que ta question est peut être mal interpréter ou mal posée.

Le premier point à voir est de pas comparer les tests Unitaire qui sont eux lié aux code aux test système qui sont liés au règle métier car des tests de niveau différent.

oui effectivement, par tests unitaires, j'entendais "test d'un composant" . Il me semblait que c'etait le terme consacré (dans le cycle en V, pour faire plaisir a Hegros mais dans les autres méthodes aussi je pense ...)

Si les tests unitaires sont bien fait du verra peu de bug dû a un aspect technique par contre il sera toujours possible de voir des bug lié à la situation de test, en gros ça veut dire qu'un test exécuté 2 fois pet donner 2 résultat différent d'où l'importance des tests systèmes.

J'essaie, autant que faire ce peut, d'avoir des composants unitaires deterministes. Maintenant, si une part d'aleatoire doit intervenir, on peut toujours estimer la sortie avec une marge d'erreur ...

Tout professionnel du test te le dira : les tests systèmes et plus précisément test fonctionnel doivent être effectué de façon manuel pour une qualité optimal.
Un ordinateur n'est de toute façon pas capable d'intrépreter des résultats de façon autonome.

Pourtant, dans certains cas, on sait déterminer a l'avance les resuultats des tests fonctionnels et on peut les analyser pour verifier qu'ils sont conformes a ce qu'on avait predit.

La on ca (me) pose plus de pb, c'est si il y a bcp de GUI a tester (c'est mon cas ). Mais il m'arrive de me dire que meme ca pourrait etre autoamtisé mais ca rentre peut etre plus dans la case "test systeme" que dans la case "test fonctionnel"

je pense que vous avez 2 visions différentes mais que les 2 ne sont pas forcément mauvaise.

En fait, il s'agit tout simplement d'une organisation, car si un développeur créer une bibliothèque (ou framework) il doit la documenter pour permettre sa réutilisation. Après c'est une habitude à prendre que peu de développeur ont. (je suis désolé de le dire, mais c'est mon vécu)
Si cette organisation est bien maintenu, la formation sur l'architecture du code, ainsi que sur les normes de codage a appliqué obligatoire sera plus aisée. Cette organisation doit être respecté quelque soit la méthode (XP ou non)
Dire ensuite que c'est scandaleux est à mon avis un peu extréme car une formation reste toujours obligatoire quelque soit la méthode, si pas d'accompagnement, le développeur pourra éventuellement faire tout et n'importe quoi, c'est au final contre productif pour l'ensemble du projet. Il faut toujours une période d'essai pour voir si celui-ci respect la méthode.

En fait, je me rends compte que cette reflexion vient du passif autour de nos bibliothèques qui ont été dev par une personne durant sa thèse. Si on avait pu travailler en collaboration, le pb n'existerait pas. En fait c'est une situation exceptionnelle et il faut qu'on mette des mesures exceptionnelles en place pour la regler

V

[ben_ghost]

@ hegros

En disant cela tu t'appuies sur le modèle en V nous sommes d'accord ou alors il est nécessaire que tu précises en donnant une référence d'où tu tiens cette hiérarchisation et ce découpage des tests.

Si c'est le cas, que tu t'appuies sur le modèle en V, sache alors que les tests fonctionnelles sont un niveau au même titre que unitaire, intégration, système et acceptance. Les tests qui ne sont pas des niveaux c'est effectivement les tests de non-régression ou de performance par exemple.

Je tiens mes infos du CFTL (comité français du test logiciel), donc assez fiable je crois. Pour ce qui est de la méthode, Je parle en générale. je suis adepte du CMMI mais je ne le vends pas à toute les sauces car je considère qu'il n'y a pas de méthode ou de guide idéal, c'est toujours a étudier au cas par cas.

Justement c'est un abus de langage. Tu différencies les 2 parce que tu te calques, à priori, sur un modèle en V. Si tu prends la suite Microsoft Test, par exemple, tu verras que les tests fonctionnelles(enregistré par script pendant la navigation écran par exemple), peuvent génèrer des 'tests unitaires' si on le souhaite. La différence est que ce test unitaire est en fait un test fonctionnel car dans le code tu vas voir ce qu'il faut pour cliquer sur les zones qui vont bien dans l'écran, saisir des valeurs dans les cases etc...

C'est bien ce que je reproche. Déjà tu prend Microsoft comme référence alors qu'il ont pondu Vista qui est une daub (... mais ils se sont rattrapé avec seven quand même je vais pas que les pourrir ) et qu'ils ont attendu IE8 pour prendre enfin compte les normes W3C. pour recentré sur le sujet Unitaire ça veut dire quoi au final pour toi ?
si tu élargis son les test unitaire au métier ce n'est plus du test unitaire mais du test fonctionnel.
C'est pourquoi je répète que les tests unitaire doivent se limiter au test des fonctions de code UNITAIREMENT (le terme a du sens là non ?) et tester une suite de classe comme le permet greenpepper ou fitness (ou d'autre d'ailleurs) est du test fonctionnel, cette technique outre-passe l'aspect ergonomique mais permet de faire de la non-régression fonctionnel.

Il ne faut pas confondre norme et méthode c'est complètement différent. Je parle de méthode quand toi tu parles de normes. Il n'y a aucune norme à ma connaissance qui t'oblige à documenter un produit web d'un point de vue fonctionnel ou technique par contre tu as des normes(W3C par exemple) qui te donnent une direction sur l'implémentation à avoir pour être compatible mais W3C ne te dit pas de documenter les fonctions de ton produit web ou même de commenter ton code(quoique un contre exemple serait bienvenue).

Je ne confonds pas norme et méthodes mais parfois la méthode DOIT prendre en compte les normes.
J'ai déjà vu souvent des associations porté plainte contre certaines sociétés car leur site n'étais pas accessible. de ce fait il ne faut pas négliger ces normes à moins que tu ne veuilles financé cette assos , de plus si ces normes existent c'est qu'il y a une raison, maintenant tout comme la méthode, il faut faire du cas par cas.

oui enfin plutôt super développeur.

c'est bien ce qu'il me semblait. Tu as une vision d'un développeur... (c'est pas forcément une critique, je suis un ancien dév aussi)

@ vdaanen

Pourtant, dans certains cas, on sait déterminer a l'avance les resuultats des tests fonctionnels et on peut les analyser pour verifier qu'ils sont conformes a ce qu'on avait predit.

En fiat c'est le but du test fonctionnel. Mais cela dépend du test fonctionnel ET du détail des spécifications fonctionnels... Il faut simplement être sûr de ne pas devoir revenir sur ton test car une info n'avait pas été prévu où alors tes specs sont impeccable... mais dans ce cas faut que tu me dises où tu bosses pour que je postules .
Si tu veux jouer la sécurité, exécute au moins une fois manuellement ton test en passed et ensuite automatise le. Au moins tu es sûr à quoi t'attendre.

La on ca (me) pose plus de pb, c'est si il y a bcp de GUI a tester (c'est mon cas ). Mais il m'arrive de me dire que meme ca pourrait etre autoamtisé mais ca rentre peut etre plus dans la case "test systeme" que dans la case "test fonctionnel"

heu... pour moi le test fonctionnel est un type de test contenu dans le niveau de test dit systéme... mais si tu sous entend test système = test unitaire Je n'ai qu'une chose à dire... Il faut savoir dépenser 10fr (ou €) pour en gagner 100 (mais plus intéressant avec les € )... Les tests unitaires sont plus stables (et donc plus maintenable) que les tests fonctionnels. De plus il faut d'abord amélioré les process en bout de chaine plutôt qu'en fin... donc je serais toi favorise les tests unitaires, c'est plus long, tu en verra moins rapidement les ROI mais ça aidera au long terme.

[vdaanen]

En fiat c'est le but du test fonctionnel. Mais cela dépend du test fonctionnel ET du détail des spécifications fonctionnels... Il faut simplement être sûr de ne pas devoir revenir sur ton test car une info n'avait pas été prévu où alors tes specs sont impeccable... mais dans ce cas faut que tu me dises où tu bosses pour que je postules .

Spec impeccable !? non du tout. Je bosse dans le domaine médical et mes "clients" sont le plus souvent de medecins pour qui une spec precise est du genre : "pour dessiner l'organe, je le fais a la souris et il faut que ca aille vite" ....

Par contre, cette reflexion vient du fait que nos applis concues et codees sous forme de FSM (ou statechart) et la, en instrumentant l'appli, on peut connaitre l'etat courant et donc savoir que telle evenement doit aire passer l'appli dans tel etat, etc... et ca j'aimerai bien l'automatiser...

Si tu veux jouer la sécurité, exécute au moins une fois manuellement ton test en passed et ensuite automatise le. Au moins tu es sûr à quoi t'attendre.

je pense que c'est probablement ce que je ferai intuitivement mais pour l'instant je n'ai pas trouvé les bons outils par rapport a nos technos

heu... pour moi le test fonctionnel est un type de test contenu dans le niveau de test dit systéme... mais si tu sous entend test système = test unitaire Je n'ai qu'une chose à dire... Il faut savoir dépenser 10fr (ou €) pour en gagner 100 (mais plus intéressant avec les € )... Les tests unitaires sont plus stables (et donc plus maintenable) que les tests fonctionnels. De plus il faut d'abord amélioré les process en bout de chaine plutôt qu'en fin... donc je serais toi favorise les tests unitaires, c'est plus long, tu en verra moins rapidement les ROI mais ça aidera au long terme.

ca fait un bail que j'applique le TU automatisé et effectivement, j'ai gagné un temps fou. En parametrant correctement les dependances, je teste en un "clin d'oeil" tous les composants impactés par une modif.
C'est d'ailleurs une des raisons de mes questions initiales car c'est bien beau de tester en un clic de souris 5 ou 6 composants mais si derriere il faut resaisir le test-report a la main (pour le composant modifié) le TUA perd un peu (mais vraiment un tout petit petit petit peu) de son interet.

[hegros]

Je tiens mes infos du CFTL (comité français du test logiciel), donc assez fiable je crois.

Oui mais le CFTL s'appuie sur quoi, est-ce que tu le sais ? Est-ce que tu as un lien de leur site qui pointe sur le sujet qui nous intéresse parce qu'entre nous le CFTL voilà c'est pas la panacée

C'est bien ce que je reproche. Déjà tu prend Microsoft comme référence alors qu'il ont pondu Vista qui est une daub

Alerte au trolling...

pour recentré sur le sujet Unitaire ça veut dire quoi au final pour toi ?
si tu élargis son les test unitaire au métier ce n'est plus du test unitaire mais du test fonctionnel.
C'est pourquoi je répète que les tests unitaire doivent se limiter au test des fonctions de code UNITAIREMENT (le terme a du sens là non ?) et tester une suite de classe comme le permet greenpepper ou fitness (ou d'autre d'ailleurs) est du test fonctionnel, cette technique outre-passe l'aspect ergonomique mais permet de faire de la non-régression fonctionnel.

Pour un développeur un TU c'est un test de développeur, ce sont les tests que l'on fait au fur et à mesure où l'on écrit du code pour valider sa programmation. Il peut être automatisé ou pas. Remarque qu'en fonction c'est test peuvent être assimilé à des tu, systèmes ou fonctionnels selon V.

Dans ma compréhension un test à l'unité. Mais l'unité c'est quoi ? L'unité cela peut être une classe biensûr mais aussi un composant fonctionnel et/ou technique, un système d'exploitation ou matériel etc...

Bref, la première définition c'est plus pour les débutants et l'autre c'est quand on veut aller un peu plus loin.

Pour information dans fitness bien que se soit orienté test fonctionnel on les appelle aussi des tests unitaires et Ms fait de même (même si tu n'aimes pas Ms à priori et que tu trouves que ce qu'ils font est nul)

J'ai déjà vu souvent des associations porté plainte contre certaines sociétés car leur site n'étais pas accessible. de ce fait il ne faut pas négliger ces normes à moins que tu ne veuilles financé cette assos , de plus si ces normes existent c'est qu'il y a une raison, maintenant tout comme la méthode, il faut faire du cas par cas.

Encore une fois tu mélanges les choses. Les sociétés qui portent plainte pour indisponibilité de service ou ce genre de chose c'est relatif au cahier des charges juridiques pas à une quelconque méthode ou norme.

Pis si tout ce qui existe à une raison d'être forcément on va pas améliorer les choses. De plus pour reprendre un 'dicton' connu dans le développement logiciel on dit que 'les normes sont faites pour être changées'. Tu crois vraiment que HTML5 ne vas pas changer dans les 20 ou 100 ans à venir ?!

. Tu as une vision d'un développeur... (c'est pas forcément une critique, je suis un ancien dév aussi)

Quand je dis super développeur je veux dire Responsable/Manager de projet et Développeur. Ce n'est pas vraiment une critique mais une incompréhension, tu ne perçois tout simplement pas que ma vision est transversale et qu'elle ne se cantonne pas qu'au développement, management et conduite de projet.

Cependant ignorer la partie développement dans sa vision, ce que tu sembles dire l'air de faire, ou la partie managériale ou conduite de projet est d'autant plus une vision limitative.

@vdaanen

En fait c'est quelle technologie que tu utilises d'un point de vue sofware ? .NET, Delphi ? Peut-être que tu l'as dis mais pas envie de tout relire..

[hegros]

Un article intéressant sur les tests

Remarque que les tests selon V en cherchant constamment à séparer unitaire, intégration, système sont très blabla et on le voit le long de ce fil que tout le monde diverge sur forcément des points précis c'est des problèmes de nommage. De plus ce découpage n'est pas forcément très adapté(inventé quand même en 1980) et plutôt assez réducteur de ce qui existe comme visions et techniques de tests

Il faudrait peut-être revenir sur la question initiale et voir si elle est résolue sinon il faudrait recentrer ce post et lister ce qui n'a pas été encore résolu point à point.

[souviron34]

Spec impeccable !? non du tout. Je bosse dans le domaine médical et mes "clients" sont le plus souvent de medecins pour qui une spec precise est du genre : "pour dessiner l'organe, je le fais a la souris et il faut que ca aille vite" ....

là tu mélanges "specs matérielles/logicielles de système" (contraintes floues, et c'est normal), et specs fonctionnelles, qui, elles dovent être précises..

"pour dessiner l'organe", je veux :

• pouvoir tracer des traits
• des points
• des demi-cercles
• des ellipses
• du texte
• changer l'épasseur des traits
• changer la forme des points
• changer le type de trait
• ....

Les specs de contrainte, il est totalement normal que l'utilisateur le définisse dans un cahier des charges comme ceci, et on ne peut en tirer plus, car ça dépend du matériel, et c'est le fournisseur qui le connait... (vitesse de poll de la position de la souris, adapter la mémoire, ajouter un matériel, du multi-processeur......)

Donc "je dessine à la souris et il faut que ça aille vite" = vitesse d'échantlillonage de la position de la souris.

[vdaanen]

là tu mélanges "specs matérielles/logicielles de système" (contraintes floues, et c'est normal), et specs fonctionnelles, qui, elles dovent être précises..

"pour dessiner l'organe", je veux :

• pouvoir tracer des traits
• des points
• des demi-cercles
• des ellipses
• du texte
• changer l'épasseur des traits
• changer la forme des points
• changer le type de trait
• ....

Les specs de contrainte, il est totalement normal que l'utilisateur le définisse dans un cahier des charges comme ceci, et on ne peut en tirer plus, car ça dépend du matériel, et c'est le fournisseur qui le connait... (vitesse de poll de la position de la souris, adapter la mémoire, ajouter un matériel, du multi-processeur......)

Donc "je dessine à la souris et il faut que ça aille vite" = vitesse d'échantlillonage de la position de la souris.

ben malheureusement, je ne confond pas ! Ce que tu listes, c'est a moi de faire des prop et en général, la réponse est toujours "oui, ca serait bien" ou "ca c'est votre problème, c'est technique".

non pas que les medecins y mettent de la mauvaise volonté mais ca ne leur semble pas etre de leur ressort ; ce qu'ils veulent c'est dessiner les limites d'un organe.

[vdaanen]

@vdaanen

En fait c'est quelle technologie que tu utilises d'un point de vue sofware ? .NET, Delphi ? Peut-être que tu l'as dis mais pas envie de tout relire..

On developpe nos applis avec des FSM (propriétaire mais tres proche de boost.Statechart).

Notre "moteur" FSM devrait permettre d'ecouter la FSM pour savoir dans quel etat elle se trouve et a partir de la, determiner les "evenements" admissibles (couplés aux conditions), les déclencher et suivre le parcours dans le graphe d'etat.
Pour certains, ca peut etre fait de maniere unitaire (cad decoupler du reste des graphes) mais pour l'appli dans son ensemble, je reve d'un moyen d'automatiser ces tests (qui sont les tests d'acceptance).

[souviron34]

ben malheureusement, je ne confond pas ! Ce que tu listes, c'est a moi de faire des prop et en général, la réponse est toujours "oui, ca serait bien" ou "ca c'est votre problème, c'est technique".

non pas que les medecins y mettent de la mauvaise volonté mais ca ne leur semble pas etre de leur ressort ; ce qu'ils veulent c'est dessiner les limites d'un organe.

Je ne veux pas en remettre une couche, mais je pense simplement que vous n'avez pas la bonne organisation...

J'ai déjà travaillé plusieurs fois dans le domaine médical, et j'ai toujours eu des specs précises, sur les 2 plans..

• Problème des contraintes :
  
  
  
  • "à la vitesse de la souris" : c'est tout à fait correct comme spec.. Puique la vitesse d'échantillonage dépend du matériel, et que c'est donc au fabricant d'ajuster ses algos/matériels (par exemple utiliser un Array Processor pour des calculs) afin de répondre à cette demande.
    
    
  • j'ai eu aussi "Sauvegarder un an d'images" : tout à fait correct aussi... Sachant que un examen se fait par exemple en 3 minutes, il y a N images par an.. Au fabricant de trouver ce qui permet de stocker ceci avec une vitesse d'accès acceptable, c'est à dire vraisemblablement inférieure à la seconde.
  
  
  
  
• Problème des specs fonctionnelles :
  
  C'est là je pense que votre organisation pêche.. Comme je l'ai déjà mentionné X fois, une approche user-centered, avec un expert métier au sein de la direction du projet, permet aisément d'avoir des specs fonctionnelles précises. Filmer quelques médeciins en train de dessiner des organes aurait donné très rapidement les outils nécessaires. Validées ensuite par le médecin référent.

Je tente continuellement de faire entrer dans les moeurs que ceci est la seule approche possible pour ne pas avoir de mauvaises surprises de part et d'autre : une tête de projet bi-céphale... un informaticien plutôt généraliste et un expert du métier, reconnu par ses pairs.



Visiblement, on ne tente de remédier aux lacunes du passé qu'en se gargarisant de nouveaux termes ou outils, mais en oubliant l'essentiel...