> Si t'as une phase de test qui vient plusieurs annees apres la phase de developpement, c'est du suicide.
Mais ça arrive. Je l'ai vécu et ce n'est pas du suicide.
Puis les tests unitaires quand t'as 300 paramètres d'exécutions et tu dépends d'un automate qui t'envois 200 autres paramètres,etc c'est impossible à réaliser. Au mieux tu couvres quelques cas d'utilisations en lancant des tests qui représentent des utilisations "typiques". Il faut aussi un simulateur. C'est généralement ce qui est fait et même dans le proprio.
> Donc on peut reformuler ta phrase "dans le cas ou un projet ne respecte aucune methodologie qualite et fait des tests 3 ans apres le dev, on sait depuis tres longtemp qu'un bug decouvert en phase de test coute tres cher".
Dans certain cas tu n'as pas le choix. Une équipe développe l'applis, une autre bosse sur un automate qui va utiliser des appareils à plusieurs millions d'euro qui sera disponible que lorsque les développements sont terminés.
Certe tu peux toujours faire des tests unitaires etc. Mais je ne me vois pas demander au boss d'avoir 6 mois de plus pour faire des tests unitaires exautifs sans que ça apporte un réel intérêt.
Dans ces cas, il faut s'appuier sur une bonne architecture. Il faut alors que les éléments critiques soient simples. Ainsi tu peux "blinder" les tests unitaires et faire des tests exautifs sur les éléments critiques.
J'utilise les tests unitaires. Mais les tests unitaire systématique et pour tout c'est l'enfer.
"Mieux" pour les grosses applis c'est rarement fait car c'est pratiquement impossible sans faire exploser le budget.
Je te donne une mission :
- Faire un (ou des) test unitaire complet pour gecko
Combien de temps il te faut ?
Un fois que c'est fait combien de ressource il te faut pour maintenir les tests à jours et suivre les développements de gecko ?
Une fois que tu as évaluer les ressources nécessaires interroges si un développeur de plus uniquement pour faire de l'audit de code n'est pas un meilleur investissement.
> Donc il faut tester tres tot et plutot que de sortir une anerie pour decredibiliser les tests (les bugs decouverts en phase de test coutent cher)
Tu le fais exprès ?
Si je fais un module et que je le teste dans la semaine il n'y effectivement pas de problème pour corriger les bugs. Mais parfois un module développé n'est utilisé que bien des mois après.
Si les tests ont été exautifs (impossible sauf pour des trucs simples) il n'y a effectivement pas de problème. Mais suppose que les formats d'entrés aient légèrement changé et que lors des tests (pas des tests unitaires) ça plante un module développé il y a quelque mois. Ces "bricoles" ça arrive.
Ça arrive car les tests peuvent être erronés ou incomplet, car il y a eu un manque communication lors de l'évolution d'un module, etc.
C'est _courrant_.
Toi t'es dans le rève ou il n'y a pas d'erreurs de conception, il n'y a pas de manque de communication, le projet est parfaitement géré, les tests sont tous exautifs et parfait, les spécifications sont complètes et n'ont raté aucuns scénarios, etc.
Voilà pour ton rève.
Ton cauchemard : Ces abrutis de développeurs qui n'arrêtent pas de faire des conneries.
Dans la "vraie vie" ça ne se passe pas comme ça.
> je pense que tu devrais integrer cette notion de tester le plus tot possible dans une demarche de qualite globale
T'es gentil.
Mais je vais te montrer un cas "spécial" et qui va te montrer que je ne suis pas contre les tests unitaires lorsque ça a un sens.
J'avais un projet sur 8 mois et ça me semblait impossible à tenir (je n'étais pas le seul à le penser). Heureusement tous les données étaient disponibles (ficher de test, moyen pour les générer, etc).
J'ai fait la conception du programme sur papier.
J'ai réalisé les procedures de tests exautives (car c'était possible et ça permettait aussi de faire le recette auprès du client).
J'ai fait validé les procédures de tests par le client.
J'ai réalisé les fichiers .h.
J'ai fait audité la conception et les fichiers .h.
J'ai "pissé" du code durant 6 mois sans rien compiler/exécuter ! Le code était blindé d'assert.
J'était en retard sur le planning car les 8 mois était écoulé. J'ai compilé, corrigé les tonnes d'erreur de syntaxe, etc qui restait.
J'ai exécuté. Corrigé les cas où le programme plantait sur les asserts.
J'ai passé les tests exautifs, corrigé les bugs. L'applis a été recetté par le client. Retard : 15 jours. Le client ne s'est jamais plaint d'un bug. Tous les tests ont été réalisés à la *fin* car pour *ce* projet c'était une bonne méthode.
Il n'y a pas de démarche qualité universel et il faut bien faire avec les ressources disponibles.
[^] # Re: ???
Posté par fabb . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 2.
Mais ça arrive. Je l'ai vécu et ce n'est pas du suicide.
Puis les tests unitaires quand t'as 300 paramètres d'exécutions et tu dépends d'un automate qui t'envois 200 autres paramètres,etc c'est impossible à réaliser. Au mieux tu couvres quelques cas d'utilisations en lancant des tests qui représentent des utilisations "typiques". Il faut aussi un simulateur. C'est généralement ce qui est fait et même dans le proprio.
> Donc on peut reformuler ta phrase "dans le cas ou un projet ne respecte aucune methodologie qualite et fait des tests 3 ans apres le dev, on sait depuis tres longtemp qu'un bug decouvert en phase de test coute tres cher".
Dans certain cas tu n'as pas le choix. Une équipe développe l'applis, une autre bosse sur un automate qui va utiliser des appareils à plusieurs millions d'euro qui sera disponible que lorsque les développements sont terminés.
Certe tu peux toujours faire des tests unitaires etc. Mais je ne me vois pas demander au boss d'avoir 6 mois de plus pour faire des tests unitaires exautifs sans que ça apporte un réel intérêt.
Dans ces cas, il faut s'appuier sur une bonne architecture. Il faut alors que les éléments critiques soient simples. Ainsi tu peux "blinder" les tests unitaires et faire des tests exautifs sur les éléments critiques.
J'utilise les tests unitaires. Mais les tests unitaire systématique et pour tout c'est l'enfer.
"Mieux" pour les grosses applis c'est rarement fait car c'est pratiquement impossible sans faire exploser le budget.
Je te donne une mission :
- Faire un (ou des) test unitaire complet pour gecko
Combien de temps il te faut ?
Un fois que c'est fait combien de ressource il te faut pour maintenir les tests à jours et suivre les développements de gecko ?
Une fois que tu as évaluer les ressources nécessaires interroges si un développeur de plus uniquement pour faire de l'audit de code n'est pas un meilleur investissement.
> Donc il faut tester tres tot et plutot que de sortir une anerie pour decredibiliser les tests (les bugs decouverts en phase de test coutent cher)
Tu le fais exprès ?
Si je fais un module et que je le teste dans la semaine il n'y effectivement pas de problème pour corriger les bugs. Mais parfois un module développé n'est utilisé que bien des mois après.
Si les tests ont été exautifs (impossible sauf pour des trucs simples) il n'y a effectivement pas de problème. Mais suppose que les formats d'entrés aient légèrement changé et que lors des tests (pas des tests unitaires) ça plante un module développé il y a quelque mois. Ces "bricoles" ça arrive.
Ça arrive car les tests peuvent être erronés ou incomplet, car il y a eu un manque communication lors de l'évolution d'un module, etc.
C'est _courrant_.
Toi t'es dans le rève ou il n'y a pas d'erreurs de conception, il n'y a pas de manque de communication, le projet est parfaitement géré, les tests sont tous exautifs et parfait, les spécifications sont complètes et n'ont raté aucuns scénarios, etc.
Voilà pour ton rève.
Ton cauchemard : Ces abrutis de développeurs qui n'arrêtent pas de faire des conneries.
Dans la "vraie vie" ça ne se passe pas comme ça.
> je pense que tu devrais integrer cette notion de tester le plus tot possible dans une demarche de qualite globale
T'es gentil.
Mais je vais te montrer un cas "spécial" et qui va te montrer que je ne suis pas contre les tests unitaires lorsque ça a un sens.
J'avais un projet sur 8 mois et ça me semblait impossible à tenir (je n'étais pas le seul à le penser). Heureusement tous les données étaient disponibles (ficher de test, moyen pour les générer, etc).
J'ai fait la conception du programme sur papier.
J'ai réalisé les procedures de tests exautives (car c'était possible et ça permettait aussi de faire le recette auprès du client).
J'ai fait validé les procédures de tests par le client.
J'ai réalisé les fichiers .h.
J'ai fait audité la conception et les fichiers .h.
J'ai "pissé" du code durant 6 mois sans rien compiler/exécuter ! Le code était blindé d'assert.
J'était en retard sur le planning car les 8 mois était écoulé. J'ai compilé, corrigé les tonnes d'erreur de syntaxe, etc qui restait.
J'ai exécuté. Corrigé les cas où le programme plantait sur les asserts.
J'ai passé les tests exautifs, corrigé les bugs. L'applis a été recetté par le client. Retard : 15 jours. Le client ne s'est jamais plaint d'un bug. Tous les tests ont été réalisés à la *fin* car pour *ce* projet c'était une bonne méthode.
Il n'y a pas de démarche qualité universel et il faut bien faire avec les ressources disponibles.