> les phases de tests qualité c'est bien gentil [...] ça marche très mal dès que la combinatoire est importante
C'est l'argument typique des mecs qui ne veulent pas tester. On parle de test unitaire. Si ta fonctionnalite unitaire a plus de 50 etats possibles, il y a un tres tres gros probleme de conception et je te conseille de separer ta fonctionnalite dans plusieurs classes contenant chacune des fonctinnalites elementaires. On appelle ca de l'encapsulation dans le monde de la programmation objet.
C'est pas toi qui parlait de bonne conception ?
> dès que le logiciel en question peut être mis en oeuvre dans des situations très variées
Si le logiciel doit etre soumis a des situations tres tres variees, il y a de grandes chances que le cerveau du developpeur n'arrive pas a lui tout seul a ecrire du code qui resistera a toutes ces situations. Dans ce cas, il est imperatif:
- d'essayer d'isoler separement la variation de ces situations (en general, c'est possible)
- de mettre en place des tests pour reproduire ces differentes situation. Dans un cas aussi complexe que tu le decris, il est naif de se dire "le developpeur a pense a tout", alors que le developpeur lui-meme sera bien plus rassure si il est en mesure de tester son code dans les situations variees.
> dès que la latitude des utilisateurs est très importante.
Ben voyons. Comme l'utilisateur peut tout faire, tu ne peux rien tester ? L'utilisateur fonctionne par taches elementaires donc tu peux tester chacune des taches elementaires.
> Combien de milliers de pages faudrait-il pour décrire un plan de test complet sur un client de messagerie façon Thunderbird ou sur
> Open Office Writer ? Quelques millions ? Et combien d'environnements de test ?
Un seul environnement de test suffit. Tu decoupes tes tests en hierarchie de facon a pouvoir selectionner ceux que tu veux faire tourner pendant que tu touches a une fontionnalite specifique.
Pour thunderbird, c'est plutot facile. Tu decoupes en fonctionnalite:
- les filtres: je cree un filtre X, un message qui doit etre filtre et un message qui doit passer a traver, je verifie que c'est le cas.
- recherche de msg : laisse a titre d'exemple
- pop3: tu montes un serveur pop3 de test ou mieux, tu en simules un (quelques lignes de python suffisent) et tu verifies que un message stocke sur le serveur est bien rapatrie par ton client, et surtout, qu'il a envoye les bonnes requets dans l'ordre. Apres, tu elabores, sur ton serveur pipo, tu mets un mauvais message, tu supprimes le message, tu reponds des conneries au requetes et tu verifie que thunderbird ne perd pas les pedales.
- smtp : tu montes un serveur smtp ou tu en ecris un reduit. Tu verifies que si tu envoies un message, il arrive bien sur le serveur smtp
- imap: idem
....
Pour OpenOffice, c'est pareil. Le seul truc que tu ne peux pas tester, c'est le rendu exact d'une police a l'ecran et a l'impression. En dehors de ca, tu peux tout tester. Je te donne des exemples de test:
- je selectionne un texte dans un paragraphe, je lance "mise en italique" et je verifie quand dans la representation interne du document, ce morceau de texte est mis en italique
- je selectionne un texte avec un style donne dans mon document et j'active la fonction "appliquer au style courant". Je verifie ensuite que les parametres de style du style courant ont ete mis a jour avec le style que j'ai selectionne
- j'ouvre un document sxw, je le sauve en word, je le recharge en word, je le re-sauve en sxw: le document final et le document initial doivent avoir le meme contenu modulo un nombre de champs _identifies_ qui ne sont pas pris en compte dans le format word
- j'ecrie un mot mal orthographie, je verifie que la fonction de correction va me sortir un mot correctement orthographie du dictionnaire.
etc, etc.
Comme tu vois, rien d'insurmontable.
Apres, sur l'explosion combinatoire des tests, ca ne s'applique pas aux tests unitaires : d'une part les fonctionnalites testees sont petites, d'autre part c'est le developpeur qui ecrit le test. Il sait quelle partie de son code il faut cibler pour lui chercher des embrouilles.
En terme de quantite de code, j'ai en general autant de code de teste que de code de programme. Mais ca ne me prend pas plus de temps a ecrire qu'un programmeur normal, car le programmeur normal aussi fait des tests. Sauf que les siens ne sont pas automatises et integre dans le projet.
C'est sur que tester un projet existant, c'est dur puisque tu as perdu tous les tests ecrits par le developpeur pendant sa phase de dev. Mais integrer les tests au dev, ca ne coute pas grand chose.
Le gain vient surtout au fur a mesure que le projet avance, ou tu peux completement te reposer sur les test unitaires. De facon non surprenantes, quand je decide de ne pas faire de test unitaire sur un morceau de programme, c'est justement la que je vais trouver des bugs par la suite et regrette ma decision.
> Après il faut faire des choix : les ressources consommées par l'assurance qualité seraient-elles mieux utilisées à faire des revues de codes, des re-codage le cas échéant, le tri et l'analyse des rapport de bogues ?
Non. Le cout de correction d'un bug croit exponentiellement en fonction du temps entre lequel il est decouvert et le moment ou la fonctionnalite a ete codee. On gagne donc un temps precieux a detecter les bugs tres tot et a s'eviter des rapports de bug qu'il faut gerer, reproduire, discuter, fermer.
J'ajoute que quand tu as des suites de tests unitaires, il est facile de s'appuyer dessus pour faire des suites de tests fonctionelles. Quand on te reporte un bug, au lieu de corriger, tu construits d'abord un test dans ta suite fonctionelle pour mettre le bug en evidence, puis tu corriges. Tu es sur que le bug ne reviendra _jamais_, tu as un test pour le prouver.
Qui plus es, tu as mentionne la notion de logiciel actif et bien maintenu. Un logiciel qui bouge, c'est un logiciel dont l'architecture evolue souvent dans le temps. Tu peux meme voir que tous les projets majeurs sont re-ecrits tous les deux ou trois ans (Gnome 1 -> Gnome 2, KDE 1 -> KDE 2, gimp1 -> gimp2, apache -> apache2, ...). Les tests unitaires prennent alors une valeur encore plus grande : on peut tout peter a l'architecture, en garantissant que les fonctionnalites sont encore la.
<< A titre d'info, je trouve les dernières versions de la suite bureautique d'un-grand-éditeur-américain-que-nous-connaissons-bien _truffées_ de bogues
>>
Je ne peux pas dire, je ne l'ai pas utilisee depuis deux ans.
[^] # Re: Complexité
Posté par Philippe F (site web personnel) . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 3.
C'est l'argument typique des mecs qui ne veulent pas tester. On parle de test unitaire. Si ta fonctionnalite unitaire a plus de 50 etats possibles, il y a un tres tres gros probleme de conception et je te conseille de separer ta fonctionnalite dans plusieurs classes contenant chacune des fonctinnalites elementaires. On appelle ca de l'encapsulation dans le monde de la programmation objet.
C'est pas toi qui parlait de bonne conception ?
> dès que le logiciel en question peut être mis en oeuvre dans des situations très variées
Si le logiciel doit etre soumis a des situations tres tres variees, il y a de grandes chances que le cerveau du developpeur n'arrive pas a lui tout seul a ecrire du code qui resistera a toutes ces situations. Dans ce cas, il est imperatif:
- d'essayer d'isoler separement la variation de ces situations (en general, c'est possible)
- de mettre en place des tests pour reproduire ces differentes situation. Dans un cas aussi complexe que tu le decris, il est naif de se dire "le developpeur a pense a tout", alors que le developpeur lui-meme sera bien plus rassure si il est en mesure de tester son code dans les situations variees.
> dès que la latitude des utilisateurs est très importante.
Ben voyons. Comme l'utilisateur peut tout faire, tu ne peux rien tester ? L'utilisateur fonctionne par taches elementaires donc tu peux tester chacune des taches elementaires.
> Combien de milliers de pages faudrait-il pour décrire un plan de test complet sur un client de messagerie façon Thunderbird ou sur
> Open Office Writer ? Quelques millions ? Et combien d'environnements de test ?
Un seul environnement de test suffit. Tu decoupes tes tests en hierarchie de facon a pouvoir selectionner ceux que tu veux faire tourner pendant que tu touches a une fontionnalite specifique.
Pour thunderbird, c'est plutot facile. Tu decoupes en fonctionnalite:
- les filtres: je cree un filtre X, un message qui doit etre filtre et un message qui doit passer a traver, je verifie que c'est le cas.
- recherche de msg : laisse a titre d'exemple
- pop3: tu montes un serveur pop3 de test ou mieux, tu en simules un (quelques lignes de python suffisent) et tu verifies que un message stocke sur le serveur est bien rapatrie par ton client, et surtout, qu'il a envoye les bonnes requets dans l'ordre. Apres, tu elabores, sur ton serveur pipo, tu mets un mauvais message, tu supprimes le message, tu reponds des conneries au requetes et tu verifie que thunderbird ne perd pas les pedales.
- smtp : tu montes un serveur smtp ou tu en ecris un reduit. Tu verifies que si tu envoies un message, il arrive bien sur le serveur smtp
- imap: idem
....
Pour OpenOffice, c'est pareil. Le seul truc que tu ne peux pas tester, c'est le rendu exact d'une police a l'ecran et a l'impression. En dehors de ca, tu peux tout tester. Je te donne des exemples de test:
- je selectionne un texte dans un paragraphe, je lance "mise en italique" et je verifie quand dans la representation interne du document, ce morceau de texte est mis en italique
- je selectionne un texte avec un style donne dans mon document et j'active la fonction "appliquer au style courant". Je verifie ensuite que les parametres de style du style courant ont ete mis a jour avec le style que j'ai selectionne
- j'ouvre un document sxw, je le sauve en word, je le recharge en word, je le re-sauve en sxw: le document final et le document initial doivent avoir le meme contenu modulo un nombre de champs _identifies_ qui ne sont pas pris en compte dans le format word
- j'ecrie un mot mal orthographie, je verifie que la fonction de correction va me sortir un mot correctement orthographie du dictionnaire.
etc, etc.
Comme tu vois, rien d'insurmontable.
Apres, sur l'explosion combinatoire des tests, ca ne s'applique pas aux tests unitaires : d'une part les fonctionnalites testees sont petites, d'autre part c'est le developpeur qui ecrit le test. Il sait quelle partie de son code il faut cibler pour lui chercher des embrouilles.
En terme de quantite de code, j'ai en general autant de code de teste que de code de programme. Mais ca ne me prend pas plus de temps a ecrire qu'un programmeur normal, car le programmeur normal aussi fait des tests. Sauf que les siens ne sont pas automatises et integre dans le projet.
C'est sur que tester un projet existant, c'est dur puisque tu as perdu tous les tests ecrits par le developpeur pendant sa phase de dev. Mais integrer les tests au dev, ca ne coute pas grand chose.
Le gain vient surtout au fur a mesure que le projet avance, ou tu peux completement te reposer sur les test unitaires. De facon non surprenantes, quand je decide de ne pas faire de test unitaire sur un morceau de programme, c'est justement la que je vais trouver des bugs par la suite et regrette ma decision.
> Après il faut faire des choix : les ressources consommées par l'assurance qualité seraient-elles mieux utilisées à faire des revues de codes, des re-codage le cas échéant, le tri et l'analyse des rapport de bogues ?
Non. Le cout de correction d'un bug croit exponentiellement en fonction du temps entre lequel il est decouvert et le moment ou la fonctionnalite a ete codee. On gagne donc un temps precieux a detecter les bugs tres tot et a s'eviter des rapports de bug qu'il faut gerer, reproduire, discuter, fermer.
J'ajoute que quand tu as des suites de tests unitaires, il est facile de s'appuyer dessus pour faire des suites de tests fonctionelles. Quand on te reporte un bug, au lieu de corriger, tu construits d'abord un test dans ta suite fonctionelle pour mettre le bug en evidence, puis tu corriges. Tu es sur que le bug ne reviendra _jamais_, tu as un test pour le prouver.
Qui plus es, tu as mentionne la notion de logiciel actif et bien maintenu. Un logiciel qui bouge, c'est un logiciel dont l'architecture evolue souvent dans le temps. Tu peux meme voir que tous les projets majeurs sont re-ecrits tous les deux ou trois ans (Gnome 1 -> Gnome 2, KDE 1 -> KDE 2, gimp1 -> gimp2, apache -> apache2, ...). Les tests unitaires prennent alors une valeur encore plus grande : on peut tout peter a l'architecture, en garantissant que les fonctionnalites sont encore la.
<< A titre d'info, je trouve les dernières versions de la suite bureautique d'un-grand-éditeur-américain-que-nous-connaissons-bien _truffées_ de bogues
>>
Je ne peux pas dire, je ne l'ai pas utilisee depuis deux ans.