Discussion :

[flure]

Bonjour,

Je suis à la recherche de softs, principalement pour du code java, qui permettent :

- de faire des tests de différentes sortes (unitaires, intégration, mise en valeur de code mort, ...)
- du "controle qualité" avec implémentation de métriques

Tant qu'a faire, si les softs peuvent etre open source, je suis preneur

[qi130]

Bonjour,

Je suis à la recherche de softs, principalement pour du code java, qui permettent :

- de faire des tests de différentes sortes (unitaires, intégration, mise en valeur de code mort, ...)
- du "controle qualité" avec implémentation de métriques

Tant qu'a faire, si les softs peuvent etre open source, je suis preneur

http://www.google.fr/search?hl=fr&q=...e+Google&meta=

Quant au contrôle qualité, je ne voudrais pas casser l'ambiance, mais tu n'auras pas grand-chose à part des contrôles très généraux, sauf si tu trouves un outil dans lequel tu peux implanter tes propres règles (sémantique, indentation,...)

[flure]

Effectivement, avec google, tu trouves moult choses mais dans le contexte où je suis, c'est à dire, petite boite = petit moyen pas facile de trouver son bonheur

Alors, tant qu'à mettre la main a la poche, autant que ça soit pour des softs de qualité...

Pour l'instant, j'ai vu JUnit, JDepend et JavaNCSS mais bon, les deux derniers offrent des métriques assez générales

[tipiak]

petits moyens ==>

pour les TU bah JUNit (et biensure toutes ses extensions Cactus etc etc...)

pour la couverture : Clover http://www.cenqua.com/clover/

sinon pour l'intégration et recette interne perso dans les petits moyens j'ai pas ca en stock ...

(si tu te passe de l'automatisation) pkoi pas faire ca à l'aide d'outils persos
deux trois petites macros qui vont bien en VBA sous excel avec un référenctiel central
pour une exécution à la mano (après tout les outils ne sont qu'un plus qui doivent découler d'une méthode et non l'inverse...)

si tu as un peu plus de sous tu as Mercury ou de rationnal...

pour le controle qualité je me suis rarement plongé dessus mais je pense qu'avant de choisir un outils il convient d'abord de clairement poser sa méthodo (définir les metriques que l'on a besoin, les classer par priorité ... pour ensuite évaluer des produit voir meme se rendre compte qu'aucun produit ne couvre les métriques que l'on souhaite...)

enfin personnelement cela dépend de l'ampleur des projets mais je suis convaincu que sur des petits projets on s'en sort à moindre coût (et à moindre enmerdement) avec des moyens minimes tel qu'une suite office

(eventuellement 4-5 macro pour faire des notifs par mail,
centraliser les infos en Bd,
une checkliste avec grille de notation pour le controle qualité (effectué à la mano...), deux trois p'tits schémas qui passent bien pour décrire les modes opératoires à suivre (pour les exécuter à la main...))

[flure]

Merci pour ces petites précisions

Pour l'automatisation, on utilise Quick Test et bon, c'est clair qu'il fait deja pas mal de choses, voir même, pratiquement le café.

C'est juste qu'entre les tests unitaires et les tests automatiques, je trouve qu'il y a comme un "trou" au niveau de l'outillage...

Au niveau des métriques, l'idéal est d'en implémenter le maximum et de faire le tri ensuite avec les retours d'expérience que l'on peut avoir. J'ai deja ma petite idée des plus pertinentes mais ça demande à être confirmé

[tipiak]

bah perso JUnit pour automatisation des TU ca me convient parfaitement

par contre cela necessite d'étendre le Framework (il y a deja plein d'extentions sur le net) mais le plus souvent pour pouvoir faire tes tests plus facilement tu fais une extention propre à ton projet
(donc il faut évaluer l'investissement de te faire ton extention de framework maison)

par contre QTP pour l'automatisation c'est impécable par contre c'est pas très tests boite blanche (c'est nickel en intégration et en recette interne

sinon pour les métriques je serais éventuellement intéressé par tes retours sur expériences concernant la pertinance de chaque métrique testée

[tipiak]

bah perso JUnit pour automatisation des TU ca me convient parfaitement

par contre cela necessite d'étendre le Framework (il y a deja plein d'extentions sur le net) mais le plus souvent pour pouvoir faire tes tests plus facilement tu fais une extention propre à ton projet
(donc il faut évaluer l'investissement de te faire ton extention de framework maison)

par contre QTP pour l'automatisation c'est impécable par contre c'est pas très tests boite blanche (c'est nickel en intégration et en recette interne

sinon pour les métriques je serais éventuellement intéressé par tes retours sur expériences concernant la pertinance de chaque métrique testée

EDIT : Pardon pour le doublon (connexion capricieuse)

[flure]

Au niveau des métriques, j'aimerais surtout voir si il y a un lien entre "qualité" du code et nombre de bugs, temps de correction, bref, prouver qu'une mauvaise qualité de code ou de conception entraine une perte de temps

[qi130]

Hum....

Je dirais que tu es en train de réinventer l'eau chaude

Tout ce que tu cherches à constater est avéré, et ça ne date pas d'hier

C'est pour cela que les langages objets ont été créés par exemples (ça évite d'additioner des choux et des carottes). C'est aussi pour ça que des méthodes d'analyse existent.

Maintenant, et de manière plus générale, la qualité du code est qq chose de très subjectif dans l'absolu.
La corrélation que tu peux faire dépend avant tout des Normes et des méthodes de ta boîte, car positionner des indicateurs qualité ne sert à rien si tu ne te sers pas des résultats...

Si tu n'as pas de Normes de programmation, tu pourras tenter d'en imposer afin de constater une amélioration globale (moins de bugs, temps de correction en baisse), mais si tu ne constates rien ? est-ce les Normes qui sont à jeter, ou bien les programmeurs qui sont c**s comme des manches ?

Bref, un conseil : si ton job n'est pas la qualité, botte en touche et réfère toi à ce qu'en disent les nombreuses publications sur le sujet, ça t'évitera de devoir te justifier !

D'autant que la qualité à un coût, et je ne suis pas certain que tes "petits moyens en €" suffisent au développement ET à la qualité.

[flure]

Non non, je ne veux pas réinventer l'eau chaude

Juste que pour ce genre de choses, moi, j'en suis convaincu mais pour convaincre les autres personnes, les beaux discours ne suffisent pas toujours
Citer des chiffres et en faire une interprétation, ça attire plus l'attention...

[tipiak]

oui mais bon la qualité a un cout
et la sur-qualité c'est pas top non plus (prix non compétitif par rapport à d'autres qui pratiquent moins de qualité)

donc mettre en place tout ce que tu as cité plus haut (surtt dans le cadre d'une petite entreprise avec de petits moyens) risque de te couter très cher
(la mise en place de tout ca est un projet à part entiere pour lequel tu n'as pas de clients...) donc si tu souhaite monter tout ca il va bien faloir l'imputer quelquepart...

de meme il faut voir en fonction de ce que fait ton entreprise si une telle rigueur qualité correspond à son image et à ce que souhaite ses clients (car forcement c'est eux qui payeront ton projet qualité...)

[flure]

D'accord, la qualité a un cout, mais le fait de ne pas faire de qualité du tout, je me demande si cela n'entraine pas un cout supérieur ...

Après, je n'ai pas une grande expérience dans les sociétés éditrices de logiciel, mais le principe appliqué : on pense, on fait, on vérifie, sans aucun formalisme ni "controle" d'aucune sorte pour voir si on s'améliore ou l'inverse, quelque part, moi ça me gene un peu

[qi130]

Certes, mais il ne faut pas aller d'un extrême à l'autre...

tu as la pseudo-règle des 80-20 (80% du résultat pour 20% du coût) qui s'applique et se vérifie au quotidien, la règle du coût de rectification d'une erreur de conception (1 en conception, 10 en réal), pour ne citer que les + connues.

Ensuite, on trouve des choses beaucoup + trapues et d'une approche à la fois + technique et + conceptuelle : Mac Cab Cyclomatic Complexity Metrics, Halstead Metrics.
Le 1er permet de décrire l'effort de test et plus généralement le niveau de difficulté lié à l'analyse d'un programme.
Le 2nd tente de faire un ratio entre l'algorhytmique du prog par rapport à l'utilisation des finesses du langage, il permet de jauger l'effort de maintenance nécessaire et la facilité de lecture d'un source.

Mais bon, faut trouver les outils qui vont analyser tes sources pour faire ressortir ces métriques, parce que faire ça à la main... ben n'y pense même pas (ou alors juste 1 fois, pour voir).

[flure]

tu as la pseudo-règle des 80-20 (80% du résultat pour 20% du coût)

La fameuse régle Pareto, c'est juste que pour une fois que je connais le nom, je ne vais pas me géner

Des métriques, il en existe des centaines allant des plus générales à celles plutot orientées sur les langages OO, ça je connais.

La où c'est plus vague pour moi, c'est d'une part, les softs les plus utilisés, avec bien sur, le ratio "qualité"/prix et si cela apporte une réelle valeur ajoutée a la conception...

Disons que je cherche des arguments forts pour tenter de faire inscrire la qualité dans le cycle de développement

[tipiak]

bah c'est pas évident

par exemple sur les tests tu peux difficilement quantifier combien tuy gagne à faire un test

(car un test c'est batard, ca te coute du temp et de l'argent et tu y gagne QUE si ca a permi d'eviter une merde plus tard...) donc c'est un gain un peu invisible

après pour convaincre a mon avi plutot que de dépenser pleins d'argent dans un projet

le plus simple est de faire des recherches dans des articles
(voir meme à la riguer d'envoyer tes gars à une formation)

la suite bah ca serait de monter un plan qualité au niveau entreprise (déja la tu y gagne) puis l'outillage...

[flure]

par exemple sur les tests tu peux difficilement quantifier combien tuy gagne à faire un test

ça sert surtout à prouver dans une certaine mesure la fiabilité de l'appli, après, ça sert indirectement à satisfaire le client et ça, ça a un prix (Je sais c'est assez bateau )

(voir meme à la riguer d'envoyer tes gars à une formation)

"Mes" gars ? N'etant que "simple" stagiaire, ça me parait difficile car bizarement, la crédibilité d'un stagiaire est rarement élevée... Allez savoir pourquoi

Disons que je fais un peu les choses à l'envers, d'abord mesurer, ensuite comprendre et après, proposer des améliorations. J'imagine que ma démarche peut etre assez critiquable mais pour l'instant, je ne vois que ça ...

[qi130]

les softs les plus utilisés

De quels softs parles-tu ?

[flure]

Softs dans le même principe que JDepend ou JavaNCSS du coté gratuit ou QStudio, CodeProStudio du coté payant

[Invité]

Bonjour,
lisant tout ceci et ayant + 5 ans d'expérience dans un cellule de test & d'intégration, je me décide à y mettre mon grain de sel

Tout d'abord, tu cibles 2 objectifs distincts :
1° La vérification / validation &
2° La qualité.
Les 2 sont évidemment liés.

Le principal - pour toi ho jeune "Stagiaire" - est d'être pragmatique et d'apporter une plus-value opérationnelle immédiate à ton entreprise.
Tout ce que je vais écrire maintenant ne sera sûrement pas toujours dans un ordre méthodologique mais bon le principal étant de te donner des clés..
1° :
Les test unitaires sont à faire par les équipes de développement.
Ce que tu peux proposer, c'est de mettre en place pour ces équipes des documents type pour les tests unitaires. Documents sur lesquels ils s'appuieront pour tester unitairement (ex simple : tester qu'un champ numérique n'acceptera que du numérique). Cela peut paraître évidemment mais cela ne l'est sûrement pas dans les faits....
Pour les tests d'intégration & recette, proposer de monter des documents sur la vérif & validation fonctionnelle, documents faits par des personnes extérieures à l'équipe qui développent si possible.
Ces documents peuvent (et devraient) être fait en partenariat avec l’équipe de dév. Ils doivent être fait très tôt dans le projet et pas à la livraison pour tests.
Une chose rapide est la mise en place de revue conjointe de validation (fin de phase). Validation des spécifications fonctionnelles (vis-à-vis du CDC), technique, etc. …
Une charte graphique peut être insérée dans ce système amenant à une validation « graphique » et amenant ainsi également de la Qualité.

ISO fait de bonnes descriptions des processus support (vérification & validation)…

2° :
La qualité : des choses simples, comme des documents sur les spécs, l’analyse, les tests, les résultats de test, etc.
Mettre en place une petite PAQ (Plan d’Assurance Qualité).

Demander aux équipes de bien documenter leurs appli & pgm ( docs précités et dans le code/pgm), mais aussi cas de tests, résultats de tests…
Si tu bosses dans l’Objet :
Mettre en place les fondamentaux de conception (OCP, DISP, LSP, etc…)
Sur les Packages :
- L’organisation :
- règle de DISP, ISP,
- GRIN (large sourire)
- Fermeture commune (OCP)
- Réutilisation commune (cohésion forte et couplage faible)
- Fonction commune (par package)
- Pas de cycle (entre package)
- Les métriques :
- Couplage entrant, sortant, abstraction
- Instabilité & distance (courbe)
- Cohésion relationnelle

Je ne parlerai pas d’ici d’outils car ils sont nombreux, et comme tu es « stagiaire », il peut être difficile de faire accepter des outils…. Et comme cela a été écrit précédemment, les outils ne servent à rien si le travail de fond n'existe pas :-)

CARPE DIEM

[flure]

A vrai dire, du coté du 1°, le cycle de développement suit (heureusement) une certaine logique, un cycle en V., avec les documents associés. Bon, c'est pas formalisé, formalisé, mais dans les grandes lignes, c'est à peu près ça.

Les tests unitaires se font selon le bon vouloir des développeurs, il n'y a pas de tests de couvertures mais bon ...

Pour le 2°, la, ça va se corser, sachant que, pour etre crédible, il faut vraiment savoir de quoi on parle... ça me laisse augurer de bonnes nuits de lectures de documentation ça ! en espérant que le jeu en vaille la chandelle

D'ailleurs, en règle général, lorsque l'on parle "qualité" à un développeur ou autre, c'est plutot de gros yeux, genre, "qu'est ce qu'il vient m'emmerder avec ça lui", ou plutot l'air pensif, "ça peut etre intéressant" ?