Et tu n'a jamais de coup de fatigue ? De faute d'inattention ? D'erreur de frappe (oh, j'ai mis == eu lieu de =) ?
> Plus sérieusement, les tests ne sont qu'une toute petite partie d'un processus qualité global.
Alors la, je ne suis pas tu tout d'accord. Bien sur, une bonne conception est essentielle, mais une bonne conception ne va apporter que des garanties de bon fonctionnement globaux (le logiciel pourra faire X ou Y). Il y a toujours un moment ou tu codes et le [1] _seul_ moyen de valider du code, c'est des tests unitaires.
Donc les tests sont une partie essentielle et fondamentale du processus qualite.
Tu peux avoir une conception magnifique UML et tout le bazar, et un logiciel code comme les pieds qui plante toutes les 10 secondes. Oui, la conception etait bonne, mais l'implementation etait a chier.
<<
On sait depuis _très_ longtemps qu'un bug découvert en phase de test coûte _très_ cher. Donc depuis bien longtemps, les bons chefs de projets mise à 90 % sur la conception et le développement.
>>
La, tu dis n'importe quoi. Tu assimiles erreur de conception et bug.
Un bug, c'est une fonctionnalite avec une erreur (= a la place de ==). Dans une bonne approche ou tu codes tes tests avant ou pendant que tu codes tes fonctionnalites, un bug a un cout de correction extremement faible. Tu es dans le code, tu vois tout de suite ce qui ne va pas, personne n'est impacte en dehors de toi, et tu corriges dans la minute ou dans la journee.
Au fur a mesure que tu avances dans la phase de vie du produit, un bug a un cout de correction exponentiel. Sur un produit deja sorti, c'est dramatique.
Je ne sais pas ou tu as vu qu'un bug decouvert en phase de test coutait cher, mais c'est n'importe quoi.
Une erreur de conception en revanche, ca coute tres cher, je suis d'accord. Mais l'avantage des tests unitaires, c'est que ca te permet de corriger ce type d'erreur a moindre cout. En effet, une erreur de conception te conduit a refaire l'architecture de ton soft. Et la, tu sors ta batterie de 300 tests unitaires qui marchait avec l'ancienne architecture. Tu la valides avec la nouvelle acrchitecture et tu es sur que tu n'as perdu aucune fcontionnalite ni introduit aucun nouveau bug. Des certitudes comme ca, ca n'a pas de prix.
1] je sens qu'on va me parler de preuve formelle. Aller, combien d'entre vous savent faire de la preuve formelle sur un logiciel ? Combien ont vu des logiciels libres avec des preuves formelles ? Connaissez vous le cout de mise en place d'une preuve formelle ? La preuve formelle, c'est super mais en pratique, pour des logiciels a la con, c'est pas la panacee.
[^] # Re: ???
Posté par Philippe F (site web personnel) . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 4.
Et tu n'a jamais de coup de fatigue ? De faute d'inattention ? D'erreur de frappe (oh, j'ai mis == eu lieu de =) ?
> Plus sérieusement, les tests ne sont qu'une toute petite partie d'un processus qualité global.
Alors la, je ne suis pas tu tout d'accord. Bien sur, une bonne conception est essentielle, mais une bonne conception ne va apporter que des garanties de bon fonctionnement globaux (le logiciel pourra faire X ou Y). Il y a toujours un moment ou tu codes et le [1] _seul_ moyen de valider du code, c'est des tests unitaires.
Donc les tests sont une partie essentielle et fondamentale du processus qualite.
Tu peux avoir une conception magnifique UML et tout le bazar, et un logiciel code comme les pieds qui plante toutes les 10 secondes. Oui, la conception etait bonne, mais l'implementation etait a chier.
<<
On sait depuis _très_ longtemps qu'un bug découvert en phase de test coûte _très_ cher. Donc depuis bien longtemps, les bons chefs de projets mise à 90 % sur la conception et le développement.
>>
La, tu dis n'importe quoi. Tu assimiles erreur de conception et bug.
Un bug, c'est une fonctionnalite avec une erreur (= a la place de ==). Dans une bonne approche ou tu codes tes tests avant ou pendant que tu codes tes fonctionnalites, un bug a un cout de correction extremement faible. Tu es dans le code, tu vois tout de suite ce qui ne va pas, personne n'est impacte en dehors de toi, et tu corriges dans la minute ou dans la journee.
Au fur a mesure que tu avances dans la phase de vie du produit, un bug a un cout de correction exponentiel. Sur un produit deja sorti, c'est dramatique.
Je ne sais pas ou tu as vu qu'un bug decouvert en phase de test coutait cher, mais c'est n'importe quoi.
Une erreur de conception en revanche, ca coute tres cher, je suis d'accord. Mais l'avantage des tests unitaires, c'est que ca te permet de corriger ce type d'erreur a moindre cout. En effet, une erreur de conception te conduit a refaire l'architecture de ton soft. Et la, tu sors ta batterie de 300 tests unitaires qui marchait avec l'ancienne architecture. Tu la valides avec la nouvelle acrchitecture et tu es sur que tu n'as perdu aucune fcontionnalite ni introduit aucun nouveau bug. Des certitudes comme ca, ca n'a pas de prix.
1] je sens qu'on va me parler de preuve formelle. Aller, combien d'entre vous savent faire de la preuve formelle sur un logiciel ? Combien ont vu des logiciels libres avec des preuves formelles ? Connaissez vous le cout de mise en place d'une preuve formelle ? La preuve formelle, c'est super mais en pratique, pour des logiciels a la con, c'est pas la panacee.