Discussion :

[Ryu2000]

En plus le développeur polyglot pro-code (qui ne s'est jamais intêresser à l'UI) est toujours contre le désign. Combien de gens j'entends, moi je ne veux pas toucher au front ou aux interfaces.

Ouais mais en même temps c'est un autre domaine...
Réaliser une interface pratique et belle ça demande des compétences totalement différentes.
Généralement un développeur ça ne peut pas écrire les tests unitaires, puis les fonctions qui vont avec ces tests et enfin créer l'interface.
À la limite test unitaire + développement ça va ensemble, mais interface + développement ça va pas forcément ensemble.
Maintenant il existe des designers spécialisé dans l'interface utilisateur, mais toutes les entreprises ne peuvent pas ou ne veulent pas en embaucher (que ces entreprises prennent au moins une stagiaire ).

Après moi perso, j'ai toujours adoré faire des interfaces (même si elles étaient moche à chaque fois et qu'elles n'étaient pas demandé).
https://youtu.be/coL-Cm3Ugaw

[Paul TOTH]

Dans un monde idéal on aurait

1) une personne rédige un cahier des charges qui reprend les besoins des utilisateurs (conception)
2) une personne implémente une solution logiciel en suivant ce cahier des charges (développement)
3) une tiers personne s'assure que la solution proposée répond au cahier des charges (testeur)
4) le support qui connait le cahier des charges explique le fonctionnement du logiciel aux clients ou remonte à la première équipe les demandes d'évolution (support)

chaque étape rencontre ses problèmes
1) tirer des utilisateurs leur besoin n'est pas une mince affaire, car leurs besoins ne sont généralement pas formalisés et il faut savoir en faire une synthèse
2) le développeur est parfois confronté à des conceptions alambiquées qui sont liées à une mauvaise connaissance de la technique qui réclamerait un compromis plus pertinent
3) le testeur a un boulot super important mais qui me semble super chiant...il faut donc le payer mieux
4) le support est le contact direct avec le client, comme il ne décide de rien il a souvent l'impression d'être entre le marteau et l'enclume

Dans la vraie vie
l'étape 1 est rarement finalisée alors que tout repose sur elle
l'étape 2 fait du système D surtout si l'étape 3 n'existe pas
l'étape 3 n'existe pas
l'étape 4 appelle le développeur qui sait répondre aux problèmes des utilisateurs sans passer par l'étape 1 (quand elle existe)

et tout par en vrille le jour ou le développeur a un contact direct avec l'utilisateur

[el_slapper]

Dans un monde idéal on aurait(.../...)

Souvent vrai, mais j'ai aussi vu l'inverse; et c'est pas mieux :

1. un gars qui fait le cahier des charges
2. un autre qui fait les specs fonctionelles générales
3. un autre qui fait les specs fonctionelles détaillées
4. un autre qui fait les specs techniques générales
5. un autre qui fait les specs techniques détaillées
6. un autre qui code
7. un autre qui débogue
8. un autre qui corrige les anomalies
9. un autre qui teste le fonctionnel
10. un autre qui teste l'ergonomie
11. un autre qui installe
12. et l'utilisateur finale qui pleure

[LSMetag]

Dans un monde idéal on aurait

1) une personne rédige un cahier des charges qui reprend les besoins des utilisateurs (conception)
2) une personne implémente une solution logiciel en suivant ce cahier des charges (développement)
3) une tiers personne s'assure que la solution proposée répond au cahier des charges (testeur)
4) le support qui connait le cahier des charges explique le fonctionnement du logiciel aux clients ou remonte à la première équipe les demandes d'évolution (support)

chaque étape rencontre ses problèmes
1) tirer des utilisateurs leur besoin n'est pas une mince affaire, car leurs besoins ne sont généralement pas formalisés et il faut savoir en faire une synthèse
2) le développeur est parfois confronté à des conceptions alambiquées qui sont liées à une mauvaise connaissance de la technique qui réclamerait un compromis plus pertinent
3) le testeur a un boulot super important mais qui me semble super chiant...il faut donc le payer mieux
4) le support est le contact direct avec le client, comme il ne décide de rien il a souvent l'impression d'être entre le marteau et l'enclume

Dans la vraie vie
l'étape 1 est rarement finalisée alors que tout repose sur elle
l'étape 2 fait du système D surtout si l'étape 3 n'existe pas
l'étape 3 n'existe pas
l'étape 4 appelle le développeur qui sait répondre aux problèmes des utilisateurs sans passer par l'étape 1 (quand elle existe)

et tout par en vrille le jour ou le développeur a un contact direct avec l'utilisateur

Je suis d'accord. Heureusement qu'il y a des exceptions qui s'approchent du monde idéal. Chez nous par exemple. Le principe est que le testeur est un assistant-chef de projet.

1) En effet, il est très rare d'avoir un cahier des charges venant du client. C'est alors le chef de projet ou un accompagnant de celui-ci (testeur) qui le rédige et est un interlocuteur pour l'étape 2.
2) Travail avec mise en place d'une organisation et d'un cahier des charges de la part du chef de projet ou d'un assistant. En environnement Microsoft les workitems TFS, et la disponibilité pour questions et remarques.
3) Le testeur ne doit pas faire que ça sinon c'est chiant en effet. Chez nous, il est passé chef de projet, et avant ça, il accompagnait le chef de projet à toutes les réunions avec les clients. C'était en gros un co-chef de projet.
4) Il faut mettre à disposition les outils appropriés pour récupérer les demandes d'évolution, les questions et les rapports de bug du client. Un logiciel de ticketing ou l'on peut chatter est très bien pour ça. On préviens ensuite ensuite les développeurs (ou le support) des remontées, et on les affecte (par exemple comme WorkItems TFS).

J'aime cette organisation qui est à la fois efficace et humaine. Bon après, il faut aimer son travail. Les chefs de projet ne sont guère plus payés que les simples développeurs. Donc pareil pour les testeurs.

[Marco46]

On n'ose pas le dire mais je vais le dire. C'est juste que nos entreprises, n'ont pas thunes pour laisser le temps de faire des codes reviews, des tests unitaires.
Tester c'est une reflexion à part, le faire soi-même n'est pas le plus qualicatif que si tu combinais plus que toi, ce serait plus efficaces.

C'est faux faux faux archi faux je suis totalement opposé à cette interprétation c'est véritablement une falsification de la réalité.

La réalité c'est que nombre de développeurs ne posent pas leurs balls sur la table pour défendre leur métier et agissent comme des moutons. Ce n'est pas à un CPI ou un quelconque manager de se mêler de savoir s'il faut faire ou pas des tests ou des code reviews. C'est un sujet qui est 100% technique et ne concerne que les techniciens. Les managers n'ont pas à se méler de de ça. Les managers donnent en input un besoin aux devs et les devs donnent une estimation ce qui permet d'estimer un cout et une ETA. Point final. Les managers n'ont pas à se méler de comment les devs travaillent ils sont plus qu'incompétents, ils sont "acompétents". C'est en dehors de leur juridiction !!

[Marco46]

Dans un monde idéal on aurait

1) une personne rédige un cahier des charges qui reprend les besoins des utilisateurs (conception)
2) une personne implémente une solution logiciel en suivant ce cahier des charges (développement)
3) une tiers personne s'assure que la solution proposée répond au cahier des charges (testeur)
4) le support qui connait le cahier des charges explique le fonctionnement du logiciel aux clients ou remonte à la première équipe les demandes d'évolution (support)

Ça c'est le monde idéal de 1980. Ça s'appelle le waterfall et ça comporte une myriade de défauts. C'est très bien pour établir des contrats, beaucoup moins pour réaliser du logiciel.

[MikeRowSoft]

La réalité est donc comme avoir un débogueur de multithread sous les yeux en vue globale...

[Ryu2000]

1) une personne rédige un cahier des charges qui reprend les besoins des utilisateurs (conception)

Ouais mais ça c'est impossible, il faut trouver des nouvelles solutions de gestion de projet.
Les clients expriment mal ce dont ils ont besoin, les développeurs comprennent mal les besoins exprimé par les clients.
La rédaction du cahier des charges c'est trop la merde.

Il faudrait un nouveau système sans cahier des charges, ou alors faire un truc dynamique et évolutif, le problème c'est qu'on peut pas prévoir l’ampleur du projet final, ni combien de temps il va nécessiter, combien il va coûter.
Bon ça va aujourd'hui, il y a de la gestion de projet agile et il y a régulièrement du dialogue entre le client et le développeur.
Tu peux livrer une nouvelle version du projet au client toutes les deux semaines par exemple.

Tout définir au début c'est pourri, c'est comme le cycle en V.
À la limite faire pleins de petits cycles en V, ça va, mais faire l'intégralité de la conception avant d'écrire le moindre code, ça n'a pas de sens.
Le cycle en V c'est peut être adapté pour la conception d'un immeuble dans les années 80, mais c'est pas adapté au développement logiciels dans les années 2010.

[LSMetag]

Ouais mais ça c'est impossible, il faut trouver des nouvelles solutions de gestion de projet.
Les clients expriment mal ce dont ils ont besoin, les développeurs comprennent mal les besoins exprimé par les clients.
La rédaction du cahier des charges c'est trop la merde.

Il faudrait un nouveau système sans cahier des charges, ou alors faire un truc dynamique et évolutif, le problème c'est qu'on peut pas prévoir l’ampleur du projet final, ni combien de temps il va nécessiter, combien il va coûter.
Bon ça va aujourd'hui, il y a de la gestion de projet agile et il y a régulièrement du dialogue entre le client et le développeur.
Tu peux livrer une nouvelle version du projet au client toutes les deux semaines par exemple.

Tout définir au début c'est pourri, c'est comme le cycle en V.
À la limite faire pleins de petits cycles en V, ça va, mais faire l'intégralité de la conception avant d'écrire le moindre code, ça n'a pas de sens.
Le cycle en V c'est peut être adapté pour la conception d'un immeuble dans les années 80, mais c'est pas adapté au développement logiciels dans les années 2010.

C'est tout à fait ça. En cycle en V, ce genre d'organisation est impossible (ou très difficile). Par contre en méthode agile, ça fonctionne plutôt bien, puisque la communication avec le client est directe et constante, et que l'on ne gère que par cycles de 2 semaines.

[fredinkan]

C'est faux faux faux archi faux je suis totalement opposé à cette interprétation c'est véritablement une falsification de la réalité.

La réalité c'est que nombre de développeurs ne posent pas leurs balls sur la table pour défendre leur métier et agissent comme des moutons. Ce n'est pas à un CPI ou un quelconque manager de se mêler de savoir s'il faut faire ou pas des tests ou des code reviews. C'est un sujet qui est 100% technique et ne concerne que les techniciens. Les managers n'ont pas à se méler de de ça. Les managers donnent en input un besoin aux devs et les devs donnent une estimation ce qui permet d'estimer un cout et une ETA. Point final. Les managers n'ont pas à se méler de comment les devs travaillent ils sont plus qu'incompétents, ils sont "acompétents". C'est en dehors de leur juridiction !!

Je suis à moitié d'accord avec toi.

Sur un modèle waterfall, lors d'un chiffrage, le PM va venir demander à l'équipe technique qui, si elle est bonne, va compter tout ce qu'il faut (+ une marge).
Comme en règle générale, on (entreprise ou client) va essayer de faire descendre la facture, on réduit de plus en plus la marge, voir on sort carrément les tests car "ouais mais au moins y aura cette fonctionnalité".

Sur le modèle agile on aura moins ce problème, vu qu'au pire tu réduit ton sprint backlog. Le problème à ce niveau sera plus de l'intervention externe sur le sprint backlog alors que ce dernier a déjà commencé ou sur les contrôles qualité externes à l'équipe. Car être agile dans l'IT, c'est bien mais c'est souvent très mal compris dans beaucoup d'entreprises pour lesquelles le waterfall est la norme de gestion pour tous les autres services...

[Paul TOTH]

Ça c'est le monde idéal de 1980. Ça s'appelle le waterfall et ça comporte une myriade de défauts. C'est très bien pour établir des contrats, beaucoup moins pour réaliser du logiciel.

oui, et donc on est passé de ce système avec ses défaut à de l'AGILE...mais sans en prendre les contraintes.

AGILE c'est pas de cahier des charges, génial, on le supprime
AGILE c'est des développeurs très réactifs, bon alors les gars va falloir bosser maintenant
AGILE c'est des réponses rapides et des problèmes précis...non mais j'ai pas le temps là, fait ton boulot quoi !
AGILE ce sont des objectifs à cours terme qui peuvent donc changer régulièrement et implique beaucoup de collaboration...y'a quelqu'un ?

[koyosama]

Ouais mais en même temps c'est un autre domaine...
Réaliser une interface pratique et belle ça demande des compétences totalement différentes.
Généralement un développeur ça ne peut pas écrire les tests unitaires, puis les fonctions qui vont avec ces tests et enfin créer l'interface.
À la limite test unitaire + développement ça va ensemble, mais interface + développement ça va pas forcément ensemble.
Maintenant il existe des designers spécialisé dans l'interface utilisateur, mais toutes les entreprises ne peuvent pas ou ne veulent pas en embaucher (que ces entreprises prennent au moins une stagiaire ).

Ben pas d'être Léonard de Vinci, mais au moins d'avoir la cutlure de l'art. C'est pas difficile de dire que son UX est juste pourri. C'est juste que beaucoup de gens sont dans leur bulle. Beaucoup de Project Manager doit comprendre, empatiser un code ou un design alors le développeur n'a pas vraiment d'excuse. Tim Cook (oui on l'aime pas, je sais, moi non plus) avait dit qu'en faisant des cours de caligraphie, cela lui donnait plus d'exigence pour le deisgn maintenant.
Ça s'apprend comme tous les trucs, en plus c'est moins compliqué que de faire des maths. Après ne va pas non plus à comprendre que Picasso avait du talent, j'ai du mal encore avec cela.

Le but ce n'est pas devenir désigner mais de faire la différence entre un bon UI/UX et empatiser ton collègue qui passe du temps à jouer à CS sur son mac toute la journée .

En plus je suis désolé de te dire cela mais les test unitaires pour les interfaces, cela existe. Tu as des outils puissant de tests pour les testeurs. Les testeur configurent et code un petit peu.

Voici un exemple de framework:

• Ruby : https://github.com/teamcapybara/capybara
• Node : http://zombie.js.org/

Je les connais pas tous mais j'ai utilisé capybara.

[Ryu2000]

oui, et donc on est passé de ce système avec ses défaut à de l'AGILE...

Vous voulez faire un topic sur la gestion de projet ?
En tout cas le cycle en V ça a plein de défaut, c'est pas motivant, trop long, il peut y avoir un gros rush à la fin, etc.
Alors qu'avec des méthodes agile, t'as + de petits objectifs, donc + de petits succès.

Tu peux faire une réunion Skype avec le client chaque semaine, pendant laquelle tu lui montre la version dev du projet, comme ça il fait des remarques.
Et de temps en temps tu livres une version pour que le client test.

Le but ce n'est pas devenir désigner mais de faire la différence entre un bon UI/UX

C'est quand même dur le design...
Surtout en web, car il faut gérer les différentes tailles d'écran...
Il faut que ça s'adapte aux smartphones, tablettes et toute ces conneries.
Personnellement ça me casse les couilles.

Je suis plus backend que frontend, pourtant avant j'aimais bien.
Il y a des frameworks comme Bootstrap qui aide et que j'utilise.

En fait c'est frustrant le design, parce que tu peux y passer énormément de temps, et t'as l'impression que t'as pas accompli grand chose.
Y'en a qui passent des heures à bricoler des fichiers css ou créer des icônes, moi j'aurai du mal.

[Marco46]

Sur un modèle waterfall, lors d'un chiffrage, le PM va venir demander à l'équipe technique qui, si elle est bonne, va compter tout ce qu'il faut (+ une marge).
Comme en règle générale, on (entreprise ou client) va essayer de faire descendre la facture, on réduit de plus en plus la marge, voir on sort carrément les tests car "ouais mais au moins y aura cette fonctionnalité".

Mais qui décide de sortir les tests ? C'est comme si tu me disais "ok on va sortir les classes on va faire que des méthodes statiques ça sera plus court". Mais d'où le CP se mêle de l'implémentation ?!?

La fonctionnalité et les tests de la fonctionnalités c'est une entité atomique. Il ne faut pas la séparer en deux, c'est comme livrer les rails 2 ans après le TGV. Ça n'a aucun sens !

Après je sais très bien que plein de devs baissent leur pantalon dès qu'un manager gueule un peu fort, c'est justement là où je pense qu'on se déresponsabilise.

[Marco46]

oui, et donc on est passé de ce système avec ses défaut à de l'AGILE...mais sans en prendre les contraintes.

Ah mais c'est certain que mal faire de l'agile c'est pareil que faire du mauvais waterfall et que ça peut pas être mieux que du waterfall bien fait ! Ceci dit ce que tu décris ne correspond pas à de l'agile, c'est du n'importe quoi.

[el_slapper]

Ah mais c'est certain que mal faire de l'agile c'est pareil que faire du mauvais waterfall et que ça peut pas être mieux que du waterfall bien fait ! Ceci dit ce que tu décris ne correspond pas à de l'agile, c'est du n'importe quoi.

Sauf que c'est 90% du "agile" en entreprise, ce n'importe quoi. Le vrai agile est rarissime. La seule fois ou j'en ai fait, personne dans la salle ne connaissait le terme. J'ai juste fait neuf versions du programme dans la journée(un samedi, qui plus est), et les gens en face 9 versions de la spec. Et à la fin, ça marchait comme ils voulaient.

De même que du bon waterfall, avec des gens intelligents, qui savent s'adapter en cas de de pépin, ça marche en fait pas mal du tout(mais c'est fort rare, et plus ancien, d'ou une réputation encore plus pourrie que l'agile, souvent à raison, hélas). J'ai connu un projet de 18 mois et 60 personnes, ou la spec avait été signée par un grand chef, et n'avait donc plus le droit d'être modifiée. Alors même qu'elle avait deux ans et n'était plus adaptée. 6 ans plus tard, ils sont repartis de zéro(oui, ça fait 6*60 = 360 années hommes jetées à la poubelle - et c'était prévisible depuis le jour un, d'ailleurs, je l'avais annoncé en me barrant par la petite porte, les autres n'avaient pas osé parce qu'ils n'avaient pas de porte de sortie). A ce niveau de stupidité, quelle que soit la méthode, on va dans le mur. Et on accusera la méthode.

Mais non, l'effort de test(hors tests unitaires, qui font partie intégrante du développement) n'est pas à laisser à l'appréciation des développeurs. C'est une décision stratégique. Souvent prise de travers par des crétins qui n'y pigent rien, mais n'est-ce pas le cas de toutes les décisions stratégiques? Moi, je peux te dire que tout ce que nous faisons ici comme tests passé le développement, le chef développeur était vent-debout contre. Et on à recalé environ une release sur deux. La grande chef a décidé qu'il y aurait de l'effort de test, et elle a eu raison. Après, c'est délicat à doser. Les retours sur investissement diminuent, comme souvent. Un effort léger aura des effets déjà sympathiques, un effort important attrapera un peu plus de bugs(et en laissera passer beaucoup moins, en proportion), laissant le client bien plus satisfait, et un effort démesuré est nécessaire en aérospatial.

Toi, ce que tu prônes, c'est le pouvoir entier aux développeurs. C'est malsain. Certes, le monde modenre a donné tout le pouvoir aux commerciaux, et c'est pas mieux, mais il y a des contraintes marché réelles, et laisser les développeurs se faire plaisir avec un test infini, ou au contraire pas de test du tout("on est les meilleurs, on en a pas besoin"), c'est néfaste à la bonne marche de l'entreprise.

[Marco46]

Toi, ce que tu prônes, c'est le pouvoir entier aux développeurs. C'est malsain.

Je prône de laisser la décision a ceux qui sont en mesure de la prendre. Il n'y a que quelqu'un qui connait le code qui sait quel niveau de test est nécessaire avant de release.

Certes, le monde modenre a donné tout le pouvoir aux commerciaux, et c'est pas mieux, mais il y a des contraintes marché réelles, et laisser les développeurs se faire plaisir avec un test infini, ou au contraire pas de test du tout("on est les meilleurs, on en a pas besoin"), c'est néfaste à la bonne marche de l'entreprise.

Mais j'ai jamais dit qu'il fallait passer tout son temps à tester sans jamais releaser ?!?

Je dis que seuls les développeurs sont pertinents pour prendre des décisions techniques.

J'ai dit qu'il fallait automatiser au maximum, c'est juste une lapallisade pour un informaticien mais c'est pas acquis par tout le monde ce que je trouve hallucinant.

Si pour une raison x ou y sur un sprint donné il y a une raison commerciale à releaser plus vite, qu'est-ce qui empêche les commerciaux de venir demander aux devs de prendre en compte leurs contraintes ? Ça se traduira par la release d'après qui sera plus longue pour fixer la dette.

En fait je dis que les techniciens doivent prendre les décisions techniques (le truc de ouf quoi) et qu'ils doivent pouvoir poser un veto. Après il faut faire la part des choses et faire preuve de souplesse.

Mais la tradition en France est complètement inverse, les devs ne sont que des exécutants alors que fondamentalement, dans la nature même du développement logiciel, c'est une hérésie. On vit donc un cas extrême, je dis juste qu'il faut revenir à la raison. C'est tout.

[el_slapper]

(.../...)
Je dis que seuls les développeurs sont pertinents pour prendre des décisions techniques.(.../...)

Justement : définir l'effort de test n'est PAS une décision technique. C'est une décision managériale. Comment on va tester peut être une décision technique(mais je peux te garantir qu'une équipe qualité de qualité sera plus à même de définir le comment que les développeurs eux-mêmes - évidemment, si ce sont des tocards, autant les contourner).

J'ai dit qu'il fallait automatiser au maximum, c'est juste une lapallisade pour un informaticien mais c'est pas acquis par tout le monde ce que je trouve hallucinant.

Non. Il faut automatiser quand c'est pertinent. Ce qui est très souvent le cas. je dis souvent que j'adore les tâches répétitives : ça permet de s'amuser à les automatiser. Mais ce n'est pas toujours le cas. Tiens, exemple. Tous les ans, on doit mettre à jour les licences de nos environnements de tests. Ca prend deux heures. une automatisation prendrait quelques jours(en comptant tout ce qui peut mal se passer, le paramétrage, etc... pas simplement le script, assez simple en soi). mettons 4 jours. Ca fait 16 ans de ROI. Pas intéressant.

Si pour une raison x ou y sur un sprint donné il y a une raison commerciale à releaser plus vite, qu'est-ce qui empêche les commerciaux de venir demander aux devs de prendre en compte leurs contraintes ? Ça se traduira par la release d'après qui sera plus longue pour fixer la dette.

Je ne vois pas ou tu veux en venir. Alors je vais donner un exemple, et tu vas me dire ce que tu en penses, histoire qu'on soit sur la même longueur d'ondes :
les hôpitaux publics, en France, se voient attribuer des sommes par l'état pour s'informatiser. Si à une date donnée, le logiciel n'est pas installé, ils doivent rembourser. Parfois, ça passe facilement. Parfois, on installe en sachant que ça ne marche pas encore(et le client le sait, mais il n'a pas le choix, ce sont des sommes trop importantes). Ca, c'est une contrainte commerciale forte. Et nombre de décisions son prises en fonctions de ça, et on sait pertinemment que l'installé ne sera pas optimal.

En fait je dis que les techniciens doivent prendre les décisions techniques (le truc de ouf quoi) et qu'ils doivent pouvoir poser un veto. Après il faut faire la part des choses et faire preuve de souplesse.

Encore une fois : l'effort de test(non unitaires) n'est pas du domaine des développeurs. tu n'as pas à être juge et partie.

Mais la tradition en France est complètement inverse, les devs ne sont que des exécutants alors que fondamentalement, dans la nature même du développement logiciel, c'est une hérésie. On vit donc un cas extrême, je dis juste qu'il faut revenir à la raison. C'est tout.

les devs sont une partie parmi d'autres. Le spécificateur, le testeur, l'exploitation, sont autant de maillons essentiels(et j'en oublie surement). Un seul se plante, et tout est planté. Certes, on vit dans un monde ou tous ces gens sont piétinés(je ne te fais pas un dessin), mais ce n'est pas une raison pour prendre la place du calife à la place du calife.

L'outil qui est développé n'a de sens que dans un cadre business. Un jeu web sur le thème de Noël, si tu le livres au 3 Janvier pour des raisons techniques, tu t'est planté.

[fredinkan]

Mais qui décide de sortir les tests ? C'est comme si tu me disais "ok on va sortir les classes on va faire que des méthodes statiques ça sera plus court". Mais d'où le CP se mêle de l'implémentation ?!?

Les 2 dernières fois où je l'ai vu, le lead dev.
Les 3 fois d'avant, le PM qui l'a imposé à la dev team...
Et malheureusement la première fois où je l'ai vu... Un dev qui a poussé pour ça vers toute l'équipe. Et les autres ont suivi comme de petits juniors qu'ils étaient (merci les SSII qui survendent leurs juniors)

[Marco46]

Les 2 dernières fois où je l'ai vu, le lead dev.
Les 3 fois d'avant, le PM qui l'a imposé à la dev team...
Et malheureusement la première fois où je l'ai vu... Un dev qui a poussé pour ça vers toute l'équipe. Et les autres ont suivi comme de petits juniors qu'ils étaient (merci les SSII qui survendent leurs juniors)

J'ai déjà vu aussi des devs, des tech leads et des architectes expliquer que les tests étaient une perte de temps.

Mais ce n'est pas parce qu'il y a parfois des techniciens incompétents qu'il faut donner ce genre de pouvoirs à des gens qui le seront systématiquement, ou a minima dont ce n'est pas dans le périmètre métier. Là on est du domaine du problème de recrutement plus qu'autre chose.

Après pour les types de tests de mon point de vue unitaire (au sens dev pas au sens QA) et intégration c'est le minimum non négociable. Je peux comprendre que le e2e pose un vrai problème de coût (selenium est un outil inadapté aux projets web modernes).

Ces techniciens commettent deux erreurs, l'une est de considérer le coût des tests indépendamment du développement ce qui les prives d'un indicateur automatisé validant une refacto (la fameuse non-régression) et donc les rend petit à petit inaptes à faire évoluer le code en insinuant la peur de faire évoluer le code chez les devs.

L'autre est de croire qu'ils feront des économies.