Discussion :

[FMJ]

Le point de vue de ma petite lorgnette, dans le cadre du dev d'une appli "standard" (je ne parle donc ni d'un SAP, ni d'une appli embarquée aéronautique, etc.)
> Testeur est un job à part entière. Quand je développe, je teste toujours mal car avec des oeillères ! Il faut avoir du recul par rapport au codage
> 3 objectifs : vérifier que l'appli réponde aux besoins fonctionnels demandés, qu'elle soit conviviale, fonctionnelle et performante, et qu'elle soit exempte de bug et de faille de sécurité autant que possible.
> Le testeur doit définir ses tests sur la base du cahier des charges fonctionnels + la vérif des inputs : il n'a pas à mettre le nez dans le code
> Ordre d'importance qui a ma préférence : tests manuels du coeur de l'usage de l'appli + tests automatiques pour la complétude du reste.

[LSMetag]

Attends on va faire une pause, je réponds initialement à quelqu'un qui disait qu'il ne fallait pas du tout que les devs testent. Je ne prétends pas qu'il ne faut pas du tout de tests en dehors des devs, bien évidemment que c'est pas interdit d'ouvrir des tickets après les devs, et qu'une QA peut être utile en complément des tests des devs, je dis que c'est pas raisonnable de laisser la QA gérer entièrement le testing parce que la QA coutent atrocement plus cher que l'automatisation et que donc si on doit sacrifier l'un ou l'autre c'est tout vu c'est les salaires des QA qui passent à la trappe.

Et je maintiens que oui les techs devraient pouvoir poser un veto sur une livraison.

C'est ce qu'on essaie de dire depuis un moment. Les 2 sont importants.

Les dev créent des tests unitaires, qui justement se chargent d'évaluer le bon fonctionnement d'un maximum de processus métiers qu'ils ont développé. On vérifie en général que la fonctionnalité fonctionne comme dans les cas d'utilisation indiqués par celui qui a donné la tache, qu'il n'y a pas de bug apparent et que ça build.

Le QA, eux, se mêle très peu de technique. Ce n'est viable que pour les projets à sprint courts (agile). Ils ont passé plus de temps que le dev sur le fonctionnel, ont comme tâche de tester en profondeur l'application finale que le client utilisera (ou tester les commits au fur et à mesure). Ils ont passé leur temps à mûrir leurs cas de test, car leur but est de faire planter l'appli (ou la rendre incohérente) en tant qu'utilisateurs lambda. C'est leur travail à plein temps. Ils ne bossent généralement pas que sur un seul projet à la fois ou alors ont un plus grand champ d'action (genre dialoguer avec les clients, participer aux réunions, aux livraisons,...). En général un testeur pour 2 gros projets ou 4 petits projets.
C'est pratique aussi pour détecter les effets de bords et les problèmes de données.

Imaginez un client qui rapporte un plantage pour un transfert d'utilisateurs (référentiel) d'une bases à l'autre. Il ne saura pas forcément dire comment il l'a provoqué. Genre que la conversion du champ "Nom" de l'ERP en "Nom" + "Prenom" de la base destination a planté parce qu'un des nom était composé avec une apostrophe (simple quote, caractère spécial). Pas facile à débugguer quand on a pas un jeu de test prévu pour ça...

Bref, ça coûte plus cher à la base, mais ça coûte moins cher en TMA (qui chez nous est déjà en surcharge (centre de service avec au moins 15 projets à la fois)). En terme de valeur ajoutée, il y a le facteur réputation et fidélisation. Le client est satisfait d'emblée. Il ne rapporte que très peu de bugs. On les détecte et corrige avant.
Sans parler également des effets de bord difficiles à voir au niveau métier.

Les 2 sont complémentaires, en particulier sur les gros projets. Il vaut mieux voir un bug avant, qu'avoir un client mécontent qui le rapporte et de manière vague.

[el_slapper]

(.../...)le budget qualite d'un projet informatique doit representer environ 30% du budget de developpement pour atteindre les standards de notre industrie(.../...)

D'accord avec le reste, mais pas avec ça. Ca, ça dépend de l'activité. Pour prendre deux exemples sur lesquels j'ai travaillé : doit-on fournir le même effort de test sur une moulinette qui doit détecter les erreurs de saisie sur les noms de ville(Cean au lien de Caen), et sur un module qui soigne des nourrissons par intraveineuse?

[mister3957]

"Tester c'est douter", "J'ai pas besoin de tests, je ne fais jamais de bugs", etc.

Voilà ce que j'ai pu entendre pendant de nombreuses années, souvent de la part de jeunes développeurs se surestimant un peut trop.

Il y a différents types de tests :
- Les tests unitaires. Je pense qu'un développeur peut le faire mais que ça ne soit pas lui qui doit également faire le dev de l'unité à tester. Si il peut le faire avant que le dev n'implémente, c'est mieux. Et si le dev qui implémente n'a pas accès au test, c'est encore mieux. Bien évidemment tout ça doit être automatisé avec également l'outillage analytique qui va bien pour checker la couverture de code, refuser une mise en prod si elle est trop faible, cibler le code non testé etc. sinon ça sert à rien.

- Les tests d'intégration. Dans les TU on utilise des mocks, des bouchons etc. pour ne tester que l'unité concerné et qui ne sont pas forcément représentatifs du comportement réel des briques qu'il y a derrière. Là je pense que le mieux serait un architecte ou un OPS dépendant des cas. Automatisé toujours, ne serait-ce que pour faire une montée de version d'une dépendance et voir si les contrats / comportements n'ont pas changés au sein de l'application.

- Puis les tests fonctionnels. Là il faudrait un mec orienté métier qui sait interpréter les facteurs métiers et connait parfaitement les attentes des utilisateurs et leurs besoins, pas le choix.

- On pourrait rajouter les tests de déploiement (des installeurs quand on livre du client lourd, de containers quand on livre des containers soit aux clients soit à l'hébergeur).

Ça coûte cher c'est sûr, mais il en va de la qualité des livrables et aussi du confort de tout le monde. Travailler avec parachutes, ceintures et bretelles, il n'y a rien de plus agréable, et sans, c'est très stressant quand on clic sur le bouton "pousser en prod".

[Daranc]

je me rappelle une autre discussion, les utilisateurs finaux sont ils des idiots?
un vaste débat
alors si on a une connerie a faire sur l'utilisation d'un programme ...on peut être sûr que la réalisation de la dite connerie sera faite.
en tant que développeur le véritable but du programme est de s'adapter à la façon de travailler des opérateur et non à eux de se mettre en phase avec la façon dont le programmeur pense que d'autres doivent travailler
dont pour moi il est certain que le test ne peut se faire qu'en cours d'utilisation. avec remonter des infos

[Luckyluke34]

1 - le budget qualite d'un projet informatique doit representer environ 30% du budget de developpement pour atteindre les standards de notre industrie, c'est a dire 1 QA pour 3 DEV

Says who? Ca dépendrait pas un peu du contexte aussi ?

L'ensemble de cet article et des commentaire me fait realiser que la France a reellement 15 ans de retard en ce qui concerne la mise en oeuvre d'une reelle demarche de qualite dans les projets informatiques.

Ouais enfin y a quand même pas mal de commentaires qui soulignent l'importance d'une QA dédiée hein.

Faut pas s'etonner que l'Inde, les US et les entreprise de developpement off-shore aient un tel succes ... eux sont deja en phase avec les dernieres normes et pratiques de notre industrie.

Dans mon expérience de l'offshore indien, ils n'arrivent pas à la cheville de ce qui se fait en Europe au niveau QA. Maintenant, ça a peut-être changé depuis.

Et la boîte dont il est question dans l'article est aussi américaine... si ça marche bien chez eux, on peut difficilement contre-argumenter juste en disant "c'est pas comme ça que ça devrait être" et en faisant du name dropping de certifications qualité...

[martopioche]

Et je maintiens que oui les techs devraient pouvoir poser un veto sur une livraison.

Admettons, mais une question : en tant que lead dev à ce que je comprends, consentirai à ce que si tu a un droit de veto, ton salaire soit redéfini à ce que 30% de celui-ci soit une prime au résultat et que celle-ci, tu ne l'a que si tu livre et que c'est en prod' pour le 23 novembre ? Veto sur livraison => pas de prime…*?

1 - le budget qualite d'un projet informatique doit representer environ 30% du budget de developpement pour atteindre les standards de notre industrie, c'est a dire 1 QA pour 3 DEV
2 - la qualite est une activite a part entiere qui requiers des professionnels confirmes qui prennent en charge l'ensemble des activites de qualites
3 - confier les tests aux memes developpeurs qui l'ont developpe, c'est le niveau 0 de la qualite
4 - la qualite ce n'est pas que executer des tests, ou meme les automatiser, c'est un ensembles d'activites qui s'exercent a toutes les etapes du processus de developpement
5 - la qualite informatique est reconnue et documentee dans un certains nombre de norme internationnellement appliquees: IIIS, ISO, CMMI, ISTQB

Grand fou… Je n'ai trouvé ce sujet qu'une semaine après, mais je n'avais qu'une question pour les premiers commentaires (qui finalement l'est pour tous) : qu'est ce que vous entendez par "qualité"… Car pour beaucoup de rituels, je cherche encore le rapport avec la "qualité" dans nombre d'équipes et d'interventions… Alors leur parler de IIIS, CMMI, ISO…

[Marco46]

Admettons, mais une question : en tant que lead dev à ce que je comprends, consentirai à ce que si tu a un droit de veto, ton salaire soit redéfini à ce que 30% de celui-ci soit une prime au résultat et que celle-ci, tu ne l'a que si tu livre et que c'est en prod' pour le 23 novembre ? Veto sur livraison => pas de prime…*?

Ça n'aurait aucun sens. Le taf du tech lead c'est d'abord et avant tout de s'assurer d'une qualité (point de vue code et archi logicielle) minimale permettant d'éviter une baisse de la vélocité et une hausse des couts dans la durée. Tu ne peux donc pas lui demander également de garantir un scope fonctionnel arbitraire et un délai arbitraire.

Cela reviendrait à donner une prime au mauvais travail, c'est vraiment un non-sens !

[martopioche]

"Tester c'est douter"

Celle là, je l'adore tellement que je l'ai mise en accroche de la partie "tests" de mes formations

Parce que mine de rien, elle est vrai…*Et que si le dev n'est pas prêt à accepter que l'on doute de son résultat, c'est qu'il doit avoir un plus gros ego que de compétence…

Il y a différents types de tests

Voilà la réflexion qui manque dans l'article…

- Les tests unitaires. Je pense qu'un développeur peut le faire mais que ça ne soit pas lui qui doit également faire le dev de l'unité à tester. Si il peut le faire avant que le dev n'implémente, c'est mieux. Et si le dev qui implémente n'a pas accès au test, c'est encore mieux. Bien évidemment tout ça doit être automatisé avec également l'outillage analytique qui va bien pour checker la couverture de code, refuser une mise en prod si elle est trop faible, cibler le code non testé etc. sinon ça sert à rien.

Dans un monde idéal, les tests devraient être écris par quelqu'un d'autre. Sauf que lorsqu'on descends au niveau du test unitaire, on test les fonctions/méthodes… Or à moins que le dev ne soit qu'un pisseur de code qui complète les signatures imposées par ceux qui ont fait la modélisation, il est le premier à connaitre ces structures. Sinon, c'est ceux qui ont fait la modélisation. Donc, si, ça reste à lui de faire ces tests.

Et oh, oui, la couverture du code par les tests, belle métrique. Tiens, un jour, j'ai fais passer celle-ci de 80 à 100% dans une équipe qui ne jurait que par celle-ci et se la jouait "qualité". Plus rien ne marchait (j'avais supprimé les lignes de code inutiles…), mais je ne sais pas trop pourquoi vu qu'ils m'avaient dit qu'ils étaient "au top" niveau tests…

Les autres tests sont évidemment loin du scope du dev…

Ouais enfin y a quand même pas mal de commentaires qui soulignent l'importance d'une QA dédiée hein.

La plupart des commentaires soulignent surtout une incompréhension de la notion de "qualité". Et d'ailleurs…

Dans mon expérience de l'offshore indien, ils n'arrivent pas à la cheville de ce qui se fait en Europe au niveau QA. Maintenant, ça a peut-être changé depuis.

Je ne vois pas le rapport… Ce soit-disant manque de qualité de leur part est surtout un manque d'exigence et donc d'AQ chez vous…

[martopioche]

avant tout de s'assurer d'une qualité (point de vue code et archi logicielle) minimale

Oh…*Si tu me parle de "qualité archi logicielle", tu a donc tous les documents décrivant actuellement l'architecture de votre logiciel ?

[martopioche]

Deuxième question :

Le taf du tech lead c'est d'abord et avant tout de s'assurer d'une qualité (point de vue code et archi logicielle) minimale permettant d'éviter une baisse de la vélocité et une hausse des couts dans la durée. Tu ne peux donc pas lui demander également de garantir un scope fonctionnel arbitraire et un délai arbitraire.

Quel est le rapport avec une mise en production au 23 qui n'a rien d'arbitraire ? En quoi éviter une hausse des couts dans la durée (quelle durée) a plus de conséquence que de ne pas mettre en prod' le 23 ?

[Luckyluke34]

Je ne vois pas le rapport… Ce soit-disant manque de qualité de leur part est surtout un manque d'exigence et donc d'AQ chez vous…

Mauvaise pioche. On parlait justement de la QA chez les Indiens. Je répondais à

la France a reellement 15 ans de retard en ce qui concerne la mise en oeuvre d'une reelle demarche de qualite dans les projets informatiques

Faut pas s'etonner que l'Inde, les US et les entreprise de developpement off-shore aient un tel succes ... eux sont deja en phase avec les dernieres normes et pratiques de notre industrie.

[WinNew]

Deuxième question :


Quel est le rapport avec une mise en production au 23 qui n'a rien d'arbitraire ? En quoi éviter une hausse des couts dans la durée (quelle durée) a plus de conséquence que de ne pas mettre en prod' le 23 ?

Lorsque Marco évoque "les coûts dans la durée", il fait référence aux conséquences de la "dégradation du code".

Je ne vais pas décrire ici ce qu'est un bon code, car ce n'est pas le sujet de la discussion. Ce qu'il faut retenir, c'est le point suivant : pour "tenir une date", le développeur peut être obligé de "dégrader le code". Ce faisant, il rend le logiciel rapidement, mais, en contrepartie, il "hypothèse sur l'avenir". Comprenez par là que le logiciel devient de plus en plus difficile à faire évoluer et le risque de voir apparaître des bugs grimpe en flèche.

Donc, oui, une date peut être "arbitraire" par rapport aux impératifs techniques.

Et l'individu qui impose une date "arbitraire" par rapport aux impératifs techniques doit être considéré comme responsable des difficultés techniques qui ne manqueront pas de survenir dans l'avenir.

Si c'est le patron qui impose une date "arbitraire" par rapport aux impératifs techniques, alors c'est le patron qui est directement responsable des futures difficultés techniques. Si c'est un commercial (pour toucher sa prime), alors c'est le commercial qui doit être tenu pour responsable.

Le problème est que trop souvent, c'est le développeur qui est tenu responsable des conséquences des décisions des "non techniques" (commerciaux, direction...).

La conséquence est que les développeurs finissent par "lâcher l'affaire". C'est normal ! On leur reproche des choses pour lesquelles ils ne sont pas responsables... alors, au bout d'un certain temps, ils ne s'impliquent plus dans leur travail. Ils se foutent de la qualité... et tout se dégrade.

[martopioche]

Mauvaise pioche. On parlait justement de la QA chez les Indiens. Je répondais à

Ben non, tu réponds par vos exigences…

[martopioche]

Lorsque Marco évoque "les coûts dans la durée", il fait référence aux conséquences de la "dégradation du code".

Merci, je sais très bien à quoi il fait référence.

Ce qu'il faut retenir, c'est le point suivant : pour "tenir une date", le développeur peut être obligé de "dégrader le code".

Peut-être, et point intéressant, mon intervention part de l'opinion de Marco comme quoi les devs devraient pouvoir poser "leur veto" sur une livraison. À priori, Marco connait la vélocité de son équipe, donc est censé "tenir la date sans 'dégrader le code'"…*Sinon, à quoi sert la métrique de la vélocité…

Ce faisant, il rend le logiciel rapidement, mais, en contrepartie, il "hypothèse sur l'avenir". Comprenez par là que le logiciel devient de plus en plus difficile à faire évoluer et le risque de voir apparaître des bugs grimpe en flèche.

Donc, oui, une date peut être "arbitraire" par rapport aux impératifs techniques.

Et l'individu qui impose une date "arbitraire" par rapport aux impératifs techniques doit être considéré comme responsable des difficultés techniques qui ne manqueront pas de survenir dans l'avenir.

Si c'est le patron qui impose une date "arbitraire" par rapport aux impératifs techniques, alors c'est le patron qui est directement responsable des futures difficultés techniques. Si c'est un commercial (pour toucher sa prime), alors c'est le commercial qui doit être tenu pour responsable.

Alors c'est à nouveau là que ça deviens intéressant : à nouveau, ma date n'a rien d'arbitraire. Et je ne sais pas dans quel contexte vous travaillez, dans le service public ou en associations, un objectif d'impératifs techniques est certainement une finalité, mais dans un contexte d'entreprise, la finalité est commerciale. Lorsque le "le commercial touche sa prime", il permet aussi une facturation. C'est cette facturation qui permet de financer des trucs aussi futiles comme…*les salaires des développeurs. De ce fait, si le développeur estime qu'il doit avoir son mot à dire sur la partie commerciale, il doit à mon sens prendre également la responsabilité de la conséquence (je suis indépendant, je l'applique à chaque décision…). Bref, cette considération est très intéressante, mais elle ne réponds pas à ma question :

Quel est le rapport avec une mise en production au 23 qui n'a rien d'arbitraire ? En quoi éviter une hausse des couts dans la durée (quelle durée) a plus de conséquence que de ne pas mettre en prod' le 23 ?

[Luckyluke34]

Ben non, tu réponds par vos exigences…

De quoi tu parles ? Tu es sur le bon thread là ? Je n'ai jamais parlé d'exigences ni de nos exigences... nos = qui d'ailleurs ?

De ce fait, si le développeur estime qu'il doit avoir son mot à dire sur la partie commerciale

On te parle pas de commercial mais d'estimation d'une réalisation technique. D'un développeur qui voit que les délais ne pourront pas être tenus à moins de livrer un produit buggé jusqu'à l'os qui fera perdre du temps voire des données aux utilisateurs et engendrera de gros surcoûts de maintenance. C'est le commercial qui corrige les bugs et maintient l'appli ? Pas que je sache. Ne mélangeons pas tout.

En tout cas drôle de discours pour quelqu'un qui prétend corriger "une incompréhension de la notion de qualité" dans "la plupart des commentaires".

[el_slapper]

(.../...)On te parle pas de commercial mais d'estimation d'une réalisation technique. D'un développeur qui voit que les délais ne pourront pas être tenus à moins de livrer un produit buggué jusqu'à l'os qui fera perdre du temps voire des données aux utilisateurs et engendrera de gros surcoûts de maintenance. C'est le commercial qui corrige les bugs et maintient l'appli ? Pas que je sache. Ne mélangeons pas tout..

Encore une fois, les contraintes techniques ne sont pas les seules existantes. Et des fois, on peut prendre de la dette technique volontaire. Du temps ou le blog de Steve Yegge était facile à trouver, il racontai ses aventures chez amazon. Et bien Jeff Bezos a sciemment pris de la dette technique - beaucoup - pour être sur le marché avant les autres. Le résultat est une montagne de merde inmaintenable, mais Amazon a phagocyté le marché. Ceux qui ont fait les choses bien ont mis la clef sous la porte.

Beaucoup de commerciaux ne savent pas ce qu'ils font, mais Jeff Bezos, lui, savait. Et il l'a fait quand même, parce-que chaque jour d'avance était vital pour griller la concurrence. Quand, en 2005, on vient me voir et on me dit, emmerdé, "el_slapper, on a un problème - on avait prévu 10 jours pour faire un programme, et tu en as 2", on a aussi conscience qu'on prend des risques avec les bonnes pratiques. Et que certaines conséquences fort désagréables risquent d'exploser plus tard. Mais on le fait quand même, parce-que les contraintes externes(contractuelles, dans ce cas précis) étaient plus forte que le risque.

Bon, et j'ai quand même fait un truc à peu près propre, mais bon, disons que moi je m'y retrouverais facilement. Un autre, je ne sais pas . Par chance, ça n'avait pas vocation à beaucoup changer.....

[mister3957]

Encore une fois, les contraintes techniques ne sont pas les seules existantes. Et des fois, on peut prendre de la dette technique volontaire. Du temps ou le blog de Steve Yegge était facile à trouver, il racontai ses aventures chez amazon. Et bien Jeff Bezos a sciemment pris de la dette technique - beaucoup - pour être sur le marché avant les autres. Le résultat est une montagne de merde inmaintenable, mais Amazon a phagocyté le marché. Ceux qui ont fait les choses bien ont mis la clef sous la porte.

Beaucoup de commerciaux ne savent pas ce qu'ils font, mais Jeff Bezos, lui, savait. Et il l'a fait quand même, parce-que chaque jour d'avance était vital pour griller la concurrence. Quand, en 2005, on vient me voir et on me dit, emmerdé, "el_slapper, on a un problème - on avait prévu 10 jours pour faire un programme, et tu en as 2", on a aussi conscience qu'on prend des risques avec les bonnes pratiques. Et que certaines conséquences fort désagréables risquent d'exploser plus tard. Mais on le fait quand même, parce-que les contraintes externes(contractuelles, dans ce cas précis) étaient plus forte que le risque.

Bon, et j'ai quand même fait un truc à peu près propre, mais bon, disons que moi je m'y retrouverais facilement. Un autre, je ne sais pas . Par chance, ça n'avait pas vocation à beaucoup changer.....

Il y a effectivement la stratégie d'entreprise à prendre en compte, lié à l'investissement (l'argent en propre ou l'argent dette), l'effort initial, le marché et ses études à un instant T et prédictives à quelques mois, etc.

C'est pareil à niveau particulier quand on achète de la pierre, est-ce que j'empreinte avec ce que ça coûte ou est-ce que j'attends 15 ans pour l'acheter cash ? Ben ça dépend des études de marchés, des contraintes, des possibilités etc.

Mais je pense que le sujet suggérait le contexte bonnes pratiques en matière de tests sur un fleuve bien tranquille en vitesse de croisière, orienté routine et non pas les questions à la Nostradamus qui sont aussi réelles que prédictives

[zaventem]

Mais je pense que le sujet suggérait le contexte bonnes pratiques en matière de tests sur un fleuve bien tranquille en vitesse de croisière, orienté routine et non pas les questions à la Nostradamus qui sont aussi réelles que prédictives

Je pense qu'il y a plus de monde qui a croisé une licorne que des projets comme ceux-là

[martopioche]

De quoi tu parles ? Tu es sur le bon thread là ? Je n'ai jamais parlé d'exigences ni de nos exigences... nos = qui d'ailleurs ?

Toi peut-être pas, mais ce que tu cite parle d'AQ dans le cadre d'offshore Indien. Je te laisse rattacher les wagons.

On te parle pas de commercial mais d'estimation d'une réalisation technique.

Bah en effet, je ne sais pas qui est "on" mais moi je réagissais à poser un véto sur une livraison.

En tout cas drôle de discours pour quelqu'un qui prétend corriger "une incompréhension de la notion de qualité" dans "la plupart des commentaires".

Venant de quelqu'un qui ne comprends pas le rapport avec des exigences quand on parle d'AQ, je crois que sans les bases de discussion, tout peut en effet paraitre "drôle".

Il y a effectivement la stratégie d'entreprise à prendre en compte, lié à l'investissement (l'argent en propre ou l'argent dette), l'effort initial, le marché et ses études à un instant T et prédictives à quelques mois, etc.

Même avant la stratégie d'entreprise, il y a simplement la finalité d'une entreprise…*C'est bien beau de se focaliser sur la dette technique, mais si c'est pour générer de la dette financière…

orienté routine et non pas les questions à la Nostradamus qui sont aussi réelles que prédictives

Pour ma part, avec mes questions qui ne sont pas anodines, je crois que l'on met clairement en évidence que les considérations des développeurs relèvent de ces "questions à la Nostradamus" et pourquoi ils n'ont pas leur mot à dire sur les questions commerciales…