Le démantèlement de l’équipe QA était peut-être en fait une mauvaise décision

• Après l’optimisation façon DevOps pour réduire les goulets d’étranglement liés aux releases, aux déploiements, à la gestion des images et aux rollbacks, le point le plus lent de la livraison logicielle reste le test
• Le secteur a commencé à voir non pas le test lui-même, mais l’équipe QA comme le goulet d’étranglement ; les attentes envers ce rôle ont augmenté, tandis que les conditions se sont dégradées, avec plus de contractualisation, d’offshoring et de réduction des embauches
• Le démantèlement des organisations QA a sapé le moral des professionnels QA expérimentés et, comme les développeurs n’ont pas naturellement repris les tâches liées à la qualité, le problème des logiciels de mauvaise qualité s’est aggravé
• La gestion de la qualité est un vrai travail qui doit être nommé et attribué : suivi des défauts, triage, investigation, plaidoyer pour la qualité, tests end-to-end
• Si le travail de qualité n’est pas organisé, ceux qui détectent et rattrapent les problèmes ne sont pas récompensés, tandis que ceux qui livrent vite et cassent des choses sont récompensés de façon répétée

---

Le goulet d’étranglement qui subsiste après l’optimisation DevOps

• Les praticiens DevOps ont fortement optimisé les pipelines et pratiques de livraison logicielle en appliquant la Theory Of Constraints
• La gestion manuelle des releases, les déploiements, la gestion des images et les rollbacks en production sont devenus des cibles d’automatisation
• Dans le parcours qui mène du backlog produit jusqu’au code livré au client, les activités à faible valeur ont été éliminées ou traitées comme des goulets d’étranglement à optimiser
• Résultat : la partie la plus lente de la livraison logicielle reste le test
  • C’est aussi pour cela que la livraison continue existe
  • On peut rendre les tests plus rapides, les automatiser et les paralléliser
  • Si, dans une pratique donnée, l’activité la plus précieuse est le goulet d’étranglement, c’est qu’on est déjà proche de l’optimum

Un secteur qui a vu l’équipe QA comme le goulet d’étranglement

• Cette habitude d’optimisation s’est étendue au-delà du test lui-même jusqu’au rôle de QA
• Il y a eu un mouvement visant à réduire les tests d’intégration et les tests end-to-end en tests unitaires afin de les paralléliser
• Au niveau des effectifs, on a aussi vu des personnes jugées incapables de coder être repoussées dans des fonctions spécialisées
• Le secteur a commencé à considérer que le goulet d’étranglement, ce n’était pas le test mais l’équipe QA
  • Les attentes envers le rôle QA ont augmenté
  • Les salaires ont baissé ou n’ont pas progressé au même rythme que pour les autres rôles
  • Le rôle s’est contractualisé et a été offshoré
  • Les décisions visant à réduire les embauches d’ingénieurs QA se sont multipliées

Le cercle vicieux créé par la réduction du rôle QA

• Les personnes restées en QA se sont retrouvées dans une situation de plus en plus défavorable
  • Celles qui savaient suffisamment bien coder ou qui étaient lassées de leurs conditions ont quitté la QA
  • Les autres ont commencé à considérer les personnes restées en QA comme “pas assez bonnes pour en sortir”
  • De moins en moins de gens recommandaient la QA aux jeunes diplômés
• Les entreprises ont rompu avec la QA sur le mode “nous n’aurons plus cette fonction, débrouillez-vous”
• Pour ceux qui avaient construit une carrière en QA, ce processus a été irrespectueux et profondément démoralisant
• Le démantèlement de la QA a aggravé le problème des logiciels de mauvaise qualité, et de nombreuses organisations ne savent plus qui doit faire quoi en matière de qualité logicielle
• Même les organisations qui ont conservé une fonction QA peinent à lui trouver sa place dans un domaine déjà fragilisé

“Licencier les testeurs” n’était pas la solution

• Le “truc bizarre” pour accélérer la livraison logicielle n’était pas de licencier les testeurs
• Dégrader le domaine de la QA s’apparente à l’une des pires erreurs de management
  • C’est un choix qui a détruit quelque chose développé sur plusieurs décennies
  • Ses effets peuvent ne pas être ressentis pendant des années
  • Et quand l’organisation finit par percevoir le problème, il faut encore des années pour rétablir quelque chose de significatif
• Les aspects du rôle QA qui étaient déjà défaillants à l’origine restent non résolus
• La répartition du travail n’a pas eu lieu, et les développeurs n’acceptent pas volontiers d’assumer les tâches de QA sans reconnaissance, compensation ou structure de récompense supplémentaire
• Certaines personnes ayant travaillé avec des équipes QA très performantes peuvent en imiter une partie des comportements, mais les ingénieurs et managers plus récents ont du mal à savoir ce qui manque
• Le principe central est que l’assurance qualité est un travail
  • Comme pour tout autre travail, supposer que “quelqu’un” le fera mène à l’échec
  • Le laisser comme un travail invisible mène aussi à l’échec

Les tâches nécessaires à la gestion de la qualité logicielle

• Suivi des défauts

  • Il faut un moyen pour que les utilisateurs puissent signaler des bugs et pour que les développeurs puissent les consigner
  • Un bug est un ticket individuel qui décrit ce qui ne va pas et à quel point c’est grave
  • Il ne décrit pas le travail de correction lui-même
  • Il doit contenir le défaut, la méthode de reproduction et l’impact
  • La plupart des équipes de développement avec lesquelles l’auteur a travaillé récemment ne suivaient pas ces défauts
  • Des raisons comme “on ne le corrigera pas de toute façon”, “ce n’est pas mon travail” ou “on est récompensé pour les nouvelles fonctionnalités” ne justifient pas des résultats de faible qualité
  • Gérer une liste de bugs est en soi un travail

• Triage et priorisation

  • Le triage des bugs consiste à affecter, prioriser, nettoyer, classer et dédoublonner les bugs entrants
  • Définir de manière cohérente des critères de gravité haute, moyenne et basse aide l’organisation
  • Autrefois, on appelait cela “l’hygiène des bugs”
  • Déterminer quelle équipe doit prendre en charge un bug est aussi un travail
  • Les organisations qui fonctionnent bien réagissent mieux aux pressions externes ou aux restructurations
  • Même en cas de licenciements, elles gèrent plus progressivement la dégradation de la qualité
  • Lors d’une réorganisation, elles transfèrent certaines catégories de bugs à de nouvelles équipes
  • Elles clôturent en masse les bugs liés à des fonctionnalités abandonnées
  • Dire qu’une équipe sans stress externe ni réorganisation peut ignorer le triage relève presque de la plaisanterie

• Investigation des défauts

  • La reproduction est une partie importante de la gestion des bugs
  • Quelqu’un doit transformer un signalement du type “j’ai essayé d’acheter une place de cinéma et ça n’a pas marché” en quelque chose comme “un problème d’encodage de caractères pour les clients dont le nom contient des caractères non anglais casse le tunnel d’achat”
  • Des questions comme “combien de fois ce problème s’est-il produit ?” ou “quel est l’impact utilisateur ?” exigent qu’une vraie personne y consacre du temps
  • L’investigation des défauts consiste à appliquer une rigueur d’ingénierie au backlog de bugs

• Un rôle centré sur la qualité

  • Il est réellement utile d’avoir dans l’entreprise des personnes concentrées sur la qualité du produit final
  • La qualité peut être l’affaire de tout le monde, mais elle doit aussi être le travail de quelqu’un
  • La tension entre qualité et vitesse exige quelqu’un pour défendre la qualité
  • Les outils de test, la qualité des tests et les plans de test ont besoin d’une personne impliquée, avec des convictions sur la meilleure manière de faire

• Tests end-to-end

  • L’un des problèmes les plus grands et les plus fréquents dans de nombreuses organisations d’ingénierie est la propriété du système
  • La complexité architecturale a augmenté dans le but de garder des équipes et des applications petites, ce qui peut être une stratégie raisonnable
  • Mais cela a laissé des angles morts sur les parties les plus importantes de l’application
  • L’équipe moyenne ne pratique plus l’usage et la validation du produit au niveau end-to-end, simplement parce que c’est trop difficile
  • Il faut vérifier que quelqu’un dans l’organisation utilise réellement le produit avant sa mise en production

Les problèmes organisationnels créés lorsqu’on ignore le travail de qualité

• La réaction peut être : “nous sommes agiles, lean et dynamiques, donc nous n’avons pas besoin de faire ce genre de choses”
• En y regardant de plus près, il est probable que ce travail ait déjà lieu dans l’organisation, mais qu’il soit très mal exécuté
• Dans d’autres domaines comme l’automobile, la banque ou la médecine, entendre “nous ne faisons pas d’assurance qualité” n’inspire pas confiance
• Ne pas reconnaître ni organiser les activités de qualité mène à de très mauvaises situations
• Les employés les plus consciencieux finissent dans l’état le plus amer
  • Ils voient les problèmes de qualité et les résolvent souvent
  • Ils n’en reçoivent aucune reconnaissance
  • Lorsqu’ils soulèvent des inquiétudes sur la qualité, ils sont traités comme des gens qui ralentissent le rythme
  • Ils voient ceux qui “vont vite et cassent des choses” être récompensés à répétition
  • Ils ont l’impression de passer leur temps à nettoyer avec colère le chaos des autres
• Dans ce type d’organisation, le simple fait de se soucier des choses devient un désavantage de carrière

[GN⁺]

Avis sur Hacker News

• Au début de ma carrière, à la fin des années 1970, j’ai travaillé chez IBM Hursley Park dans l’équipe Product Assurance, c’est-à-dire l’organisation QA. Nous construisions du code et du matériel pour tester le système de traitement de texte dont nous avions la charge, puis nous exécut ions des cas de test sur le système visé
  Les problèmes découverts n’étaient transmis à l’équipe de développement que sous forme de descriptions générales, dans le but de leur faire corriger les bugs plutôt que de leur faire deviner les cas de test. Ainsi, si nous trouvions 3 bugs dans le domaine de la coupure des mots avec trait d’union et de la suppression avec retour arrière, l’équipe de développement en corrigeait 4 dans cette zone alors que, de notre côté, nous n’en avions effectivement trouvé que 2 ; cela permettait d’estimer statistiquement le nombre réel de bugs restants
  Dans les organisations sans équipe QA, on a introduit le concept de sniff test. Il s’agit en général d’une session d’environ une heure durant laquelle n’importe qui dans l’entreprise ou le département malmène une nouvelle fonctionnalité ; même quand la fonctionnalité est considérée comme terminée, les cas limites étaient presque toujours cassés. Il suffisait souvent d’essayer des conditions simples, comme saisir "" dans tous les champs puis valider, naviguer dans l’interface uniquement au clavier, ou utiliser une grande police / un zoom navigateur à 110 %, pour faire ressortir des problèmes, et ça ne me surprend même plus aujourd’hui

  • Chez nous, on appelle ça un bug bash, et c’est généralement très productif en termes de nombre de défauts trouvés
    Lors du développement de petites fonctionnalités, seuls les programmeurs les testent en général, et cette façon de faire peut différer de la manière dont les vrais utilisateurs finaux s’en servent, ce qui rend l’approche particulièrement utile
  • La stratégie consistant à cacher aux développeurs l’origine des tests automatisés est intéressante. On dirait que cela peut les pousser à se concentrer sur la résolution du vrai problème, plutôt que de désactiver les tests ou de coder uniquement pour les faire passer
  • Chez Microsoft autrefois, on appelait ça un bug bash, et ma startup a repris l’idée. On encourageait toute l’entreprise à libérer une après-midi pour y participer, et on donnait même des prix pour le bug le plus impactant ou le plus intéressant
  • Je me demande à qui il est réellement utile de créer 100 tickets de bug en une heure. S’il y a beaucoup de doublons, 10 bugs différents suffisent déjà à montrer que la fonctionnalité est gravement défectueuse ; au-delà, on a l’impression de continuer à frapper sur les débris
  • Le fait d’avoir des cas de test QA précis tout en ne donnant aux développeurs que des descriptions ambiguës est assez malin. Je n’avais jamais vu cette méthode, et la possibilité d’estimer le nombre de bugs restants est également impressionnante

• J’ai travaillé dans deux entreprises qui, il y a 15 à 20 ans, investissaient dans des équipes QA de tout premier niveau, et ces équipes valaient vraiment leur coût. La QA trouvait très bien les bugs auxquels les développeurs, trop proches du problème, ne pensaient pas, et le produit atteignait aussi un niveau mondial
  Dans les deux entreprises, le point clé était que l’équipe QA avait le dernier mot sur la décision de livrer ou non
  Aujourd’hui, les entreprises semblent penser qu’il vaut mieux que les développeurs utilisent des tests automatisés et se focalisent de manière excessive sur la couverture de code, mais j’ai vu bien trop de produits avec une couverture de code de 100 % qui, objectivement, ne fonctionnaient pas. Cela ne veut pas dire que les tests automatisés sont mauvais, mais que supprimer les testeurs QA humains est le vrai problème

  • Les excellentes organisations QA/QE que j’ai connues fonctionnaient de façon similaire. La chaîne de commandement qui décidait de certifier ou non une mise en production était distincte de celle du développement, et la structure d’incitation l’était aussi
    Dans la dernière entreprise où j’ai travaillé, l’équipe QE écrivait une quantité énorme de code pour exécuter les tests, au point d’avoir plus de lignes de code que les modules testés et certifiés
  • La couverture de code ne trouve pas les bugs issus de code qui n’a pas été écrit alors qu’il aurait dû l’être. La couverture n’est qu’un indicateur parmi d’autres, et il est absurde de la traiter comme le seul critère
    Cela dit, j’ai déjà entendu un responsable des tests dans une grande entreprise logicielle bien connue déclarer qu’une fois les 100 % de couverture atteints, l’équipe de test n’avait plus de raison d’être
  • Le simple fait de décréter que la QA a le pouvoir de décision final ne suffit pas ; il faut une culture QA
    Même avec cette autorité, dans les entreprises où la QA est composée en majorité de contractuels mal payés qui ne font que ce qu’on leur dit, la situation restait catastrophique
  • J’ai vu des développeurs écrire des tests sans assertion, ou avec seulement assertTrue(true). Tout est toujours au vert et la couverture est de 100 %
    Les mêmes demandaient souvent pourquoi il fallait écrire des tests puisqu’ils pouvaient déjà développer de nouvelles fonctionnalités ; puis un QA senior arrivait et cassait tout. Une fois, il a trouvé qu’en appuyant 50 fois sur F5 en une minute, le backend enchaînait les requêtes à la base de données jusqu’à mourir sur un outOfMemory
  • J’aime vraiment les QA méticuleux. En tant que développeur, compter excessivement sur eux en espérant qu’ils attrapent ce que j’ai raté est un anti-pattern, mais quand moi j’ai peur de laisser mon code tourner ne serait-ce qu’une minute, eux y prennent plaisir
    Ils sont fiers de trouver des cas limites qui dépassent largement les spécifications, et cette valeur est réelle. De la même façon qu’un bon système de types donne confiance pour faire évoluer le code, une excellente QA donne aussi confiance aux développeurs. C’est particulièrement vrai pour les applications très interactives comme les jeux, où il est difficile de couvrir tout l’espace des paramètres avec seulement des tests unitaires et d’intégration

• Dire que les employés les plus consciencieux d’une organisation sont aussi les plus amers est une vérité douloureuse. Ils voient les problèmes de qualité, les corrigent souvent eux-mêmes, mais ne sont pas reconnus, et quand ils expriment leurs inquiétudes sur la qualité, on les traite comme des gens qui ralentissent l’équipe
  Ceux du camp du « move fast and break things » continuent à être récompensés, tandis que ceux qui s’en soucient ramassent les morceaux et accumulent de la frustration. Pour eux, le simple fait de se soucier des choses ressemble à un énorme désavantage de carrière, et c’est effectivement le cas
  Les équipes DBA et infrastructure sont dans la même situation que la QA, et j’espère que leur heure reviendra bientôt

  • Il suffit de sauter du navire et de laisser cette entreprise couler. Mieux vaut qu’elle échoue plus vite, et de bonnes choses deviennent possibles quand on cesse de soutenir artificiellement une mauvaise entreprise
  • Pour moi, la manière dont l’astreinte revient, c’est you build it, you run it. Si vous ne voulez pas que le pager d’on-call sonne, il suffit de ne pas créer quelque chose qui le fera sonner
  • Au final, tout dépend des clients. La vraie question est de savoir s’ils partiront à cause des bugs et des pannes, ou s’ils resteront pour les nouvelles fonctionnalités tape-à-l’œil
  • La QA et les tests sont importants, mais je ne sais pas s’il est possible de convaincre ceux qui ne regardent que le profit. Comme le déploiement sur Internet est devenu trop facile, l’approche « sortir vite, patcher plus tard » semble destinée à durer
    Le raisonnement est qu’il n’y a pas de raison d’investir beaucoup d’argent et de temps si les utilisateurs peuvent signaler les bugs et recevoir les mises à jour via Internet. Depuis que les jeux et les logiciels sont passés des supports physiques au téléchargement, corriger après coup semble coûter moins cher. Bien sûr, cela mène à d’horribles problèmes de sécurité et à une mauvaise expérience utilisateur, mais tant que les dirigeants maximisent leurs profits, cela leur importe peu
  • Les ingénieurs consciencieux n’ont pas toujours raison ; il faut du contexte et de l’équilibre. Parfois ils ont raison, mais leur manière de communiquer est défaillante, et parfois ils sont simplement au mauvais endroit
    Si vous développez un produit SaaS POC, vous n’avez pas besoin d’un niveau de qualité d’un microcontrôleur d’avionique. Tout compromis comporte un risque et un coût, et un bon ingénieur doit savoir faire la différence

• Le problème fondamental des équipes QA est le même que pour les équipes IT ou les structures de management : si elles font bien leur travail, on a l’impression qu’elles ne font rien
  Elles se retrouvent donc souvent dans une situation où elles doivent « justifier » leur travail, ce qui conduit généralement à une dépendance excessive aux métriques. Comme avec la loi de Goodhart, on finit par ne plus comprendre ce dont la métrique est le substitut ni quel est l’objectif réel du travail
  Une mauvaise équipe QA pinaille excessivement pour donner l’impression qu’elle a des choses à dire, tandis qu’une bonne équipe QA vérifie la qualité tout en formant les employés à produire une qualité supérieure
  J’ai l’impression qu’il y a un manque de formation généralisé dans les effectifs. L’article passé récemment en une, « le 95e percentile n’est pas si impressionnant » (https://news.ycombinator.com/item?id=38560345), expliquait aussi qu’il est facile d’atteindre le top 5 % dans n’importe quel domaine, parce que la plupart des gens ne s’entraînent pas activement et ne reçoivent pas de feedback
  Une entreprise ne devrait-elle pas s’entraîner en continu comme une équipe professionnelle plutôt que comme une équipe sportive amateur ? Même le recrutement devrait moins chercher à savoir « cette personne est-elle déjà top performer ? » que « peut-on faire de cette personne un top performer ? ». Le fait d’avoir réussi dans un environnement précédent a moins de valeur qu’on ne le pense si le nouvel environnement est très différent

  • Il existe un mème culturel très répandu selon lequel atteindre le 95e percentile serait quelque chose d’extrêmement difficile, alors que cela peut simplement être le résultat d’une réduction des erreurs inutiles plutôt que d’un effort titanesque
    Sous chaque article sur la qualité logicielle, on trouve beaucoup de commentaires qui considèrent comme normale l’indifférence généralisée des ingénieurs. Selon les contextes, bien sûr, mais les gens semblent assez à l’aise pour suivre l’optimum local de leur organisation en abandonnant toute initiative. Ce n’est pas entièrement leur faute, mais ils ne sont pas innocents non plus
  • Dans les équipes DevOps, je vois sans cesse ce schéma où il faut « justifier son travail ». En général, l’opérationnel le mieux payé ou le plus senior passe beaucoup de temps à éteindre les incendies créés par sa propre incompétence ou ses propres erreurs, ce qui donne l’impression qu’il fait quelque chose
    Automatiser pour éliminer les tâches répétitives ferait disparaître son poste, mais bien faire les choses donne aux managers l’impression que cette personne reste assise toute la journée sans rien faire ; il y a donc peu d’incitation à agir correctement
  • Quand on travaille avec de nouveaux développeurs, on peut souvent les faire trébucher rien qu’avec des tests de base comme le double-clic, les espaces en tête de ligne ou le bouton retour d’Android. Après quelques tickets rejetés, ils apprennent ces points et le même problème réapparaît rarement ensuite
    Comme on n’est pas évalué au nombre de bugs trouvés, il n’y a pas non plus de pression pour gonfler les chiffres en dénichant de force des bugs idiots
  • J’ai entendu dans presque toutes les entreprises : « si on les forme comme ça, ils partiront ailleurs pour gagner plus ». Toute formation sérieuse a toujours été un uphill battle
    Une bonne formation exige, au sein des métiers techniques, un vivier suffisamment large de personnes compétentes. Elles n’ont pas besoin de connaître toutes les dernières technos, mais elles doivent savoir repérer et signaler les absurdités. Même FAANG n’échappe pas à ça

• Comme le dit aussi cet article, le vrai cœur du problème est que la QA est presque toujours perçue par les business units et le top management comme un centre de coûts
  Dans les organisations perçues comme des centres de coûts, j’ai l’hypothèse qu’il vaut mieux ne pas travailler. Les bonus, la reconnaissance et le respect vont toujours à ceux qui rapportent de l’argent, tandis que les centres de coûts doivent faire plus avec moins, porter la responsabilité des échecs et être les premiers licenciés quand l’entreprise se rétracte. L’IT, c’est pareil
  Ce cercle vicieux fait que faire carrière en QA est inévitablement plus difficile que devenir développeur avec des compétences comparables. Les meilleurs finissent épuisés et partent dès qu’ils le peuvent, ce qui renforce encore le système

  • Même comme développeur d’app mobile, j’ai l’impression qu’il faut faire attention à ne pas se retrouver avec du travail de type centre de coûts
    L’accessibilité, l’observabilité, un bon logging, l’amélioration de l’infrastructure de test, l’ajustement du CI/CD, la fiabilité, de meilleurs linters et les problèmes d’analyse sont tous importants, mais ce sont les livraisons rapides de fonctionnalités qui sont récompensées
    Cette année, j’ai passé trop de temps sur ce type de travail parce que je pensais que l’équipe et l’app en avaient besoin, et je m’inquiète de mon évaluation de fin d’année. Je comprends maintenant pourquoi les autres évitaient ces tâches, et l’an prochain je compte me concentrer sur des livraisons de fonctionnalités plus visibles. Désolé pour les bugs de l’app, mais j’ai besoin de garder mon emploi pour rembourser mon prêt immobilier
  • Je suis d’accord avec cette idée de centre de coûts, mais d’après mon expérience c’est un peu plus nuancé
    Certaines organisations valorisent sincèrement ce qu’apporte la QA/QC. Je l’ai davantage vu dans l’industrie manufacturière que dans le logiciel, sans doute parce que le logiciel est par nature plus abstrait et qu’il est plus difficile d’y suivre le gaspillage
    Une très bonne QA n’est pas quelqu’un qui cherche la facilité, mais quelqu’un qui croit en la mission de la QA. Au final, la valeur vient du fait que l’organisation et les individus adhèrent sincèrement à l’esprit de la QA ; beaucoup d’endroits ne le font que de manière formelle
  • Je travaille dans une équipe plateforme frontend sur l’amélioration des performances, la conception du CI et le process engineering, mais il est bien plus difficile d’obtenir de la reconnaissance et des promotions que pour ceux qui livrent des fonctionnalités qui se traduisent directement en argent sur le compte en banque
    Cela dit, ça m’est égal. J’aime rendre les choses meilleures et plus robustes, et ça me donne l’esprit tranquille. Je laisse le soin de les casser aux cyniques
  • J’ai passé presque toute ma vie professionnelle dans des centres de coûts, et je ne voudrais pas échanger ça contre autre chose
    Peu importe si les bonus et le reste vont à d’autres groupes. Je suis déjà suffisamment bien payé dans un métier technique, et une bonne partie de ces rôles qui rapportent de l’argent m’auraient rendu profondément malheureux, même si j’y avais été bon
  • C’est pour ça que je ne travaille pas dans les départements IT d’entreprises traditionnelles

• La qualité logicielle, la maintenabilité du code et une bonne conception n’ont d’importance que si l’on prévoit de rester longtemps dans l’entreprise
  Si l’on compte rester quelques années puis partir ailleurs, la voie optimale consiste à faire des choses très visibles pour monter vite, puis à utiliser cette ligne sur le CV pour obtenir un poste mieux payé. Peu importe si, quelques années plus tard, le projet se casse ou devient impossible à maintenir : à ce moment-là, on sera déjà parti
  Les startups fonctionnent aussi comme ça. Le growth mindset gravé partout, c’est exactement ce schéma. Même si le produit devient impossible à maintenir dans 5 ans, d’ici là il y aura peut-être déjà eu une sortie et une monétisation
  Je ne blâme pas exactement ces gens-là. Ce sont les pratiques que les entreprises elles-mêmes instaurent, et les gens ne font que jouer selon les règles. Je n’aime pas ça, je déteste vraiment ça, mais je comprends
  Le plus ironique, c’est quand les managers et les dirigeants se plaignent du turnover, du manque d’engagement envers l’entreprise et du quiet quitting. C’est comme s’ils goûtaient eux-mêmes au poison qu’ils ont fabriqué

  • Pour une startup, considérer comme raisonnable le fait que le produit puisse devenir impossible à maintenir dans 5 ans peut être une attitude réaliste. La plupart des startups ne survivent pas 5 ans et échouent
    Si elle est encore là dans 5 ans avec de la dette technique, pour beaucoup de startups ce sera plutôt un bon problème à avoir. Cela voudra au moins dire qu’elle a survécu jusque-là

• Les ingénieurs QA sont aussi généralement très bons en débogage. Ils touchent aux pipelines, au code source, aux répertoires de tests, et à presque tous les aspects du développement et du déploiement d’une application
  Quand j’étais lead QA, je voyais souvent des ingénieurs logiciel se plaindre tous les jours sur Slack sans même essayer de lire les messages d’erreur du pipeline. Même lors d’optimisations du pipeline, ils ignoraient le problème fondamental et passaient des jours à tenter de résoudre au doigt mouillé des symptômes issus de ce problème, comme s’il s’agissait de soucis magiques et incompréhensibles
  Le mépris envers les ingénieurs QA évoqué dans cet article n’est pas exagéré. Même dans les entreprises qui ont une organisation QA, il arrive souvent que les procédures d’entretien ne soient pas aussi rigoureuses que dans les équipes d’ingénierie, ce qui contribue à sous-évaluer les ingénieurs QA
  Les seuls SWE que j’ai vus respecter la QA étaient ceux qui y avaient eux-mêmes travaillé. Le mépris était si répandu que j’ai fini par retourner dans l’ingénierie, et j’ai essayé de faire bouger les choses en m’appuyant sur mon ancienneté de principal engineer ou sur des rôles de management, mais j’ai échoué. L’ingénierie n’arrivait pas à dépasser sa propre arrogance, et le leadership n’a pas aidé
  Le nouveau CTO de l’entreprise où j’étais avant d’être licencié disait qu’on pouvait éliminer le besoin de QA grâce à l’automatisation, mais il n’a jamais donné le moindre exemple concret de ce que cela signifiait. Voilà le niveau de respect venu d’en haut pour le travail de création de bon logiciel

• Microsoft semble être le cas le plus frappant de ce problème. Après avoir supprimé ses équipes QA, les bugs ont visiblement augmenté dans les mises à jour de Windows et des produits cloud

  • Comme le chiffre d’affaires continue de rentrer, j’imagine que c’était donc la bonne décision d’un point de vue business… soupir
    J’utilise beaucoup de logiciels et services Microsoft au travail, et j’aimerais qu’ils paient d’une manière ou d’une autre pour cette baisse de qualité

• C’est peut-être seulement mon expérience personnelle, mais je n’ai jamais vu d’équipe QA écrire réellement des tests pour l’ingénierie
  Dans mon expérience, les équipes QA écrivaient des plans de test et les exécutaient manuellement, ou plus rarement via des tests automatisés sur navigateur ou appareil. Ces tests ont de la valeur, mais à mes yeux moins que les tests unitaires ou d’intégration
  Dans ce modèle, c’est en pratique l’équipe d’ingénierie qui devient l’équipe QA, et une équipe QA séparée finissait souvent par coûter plus qu’elle ne rapportait, en générant du bruit en signalant comme bugs des choses qui n’en étaient pas
  J’aimerais apprendre à connaître un modèle d’équipe QA qui fonctionne bien. Les tests manuels sont excellents, mais dans mon expérience ils ont des limites. Ce n’est pas une tentative de rabaisser les gens de la QA, je partage simplement mon vécu

  • Pour moi, la valeur de la QA réside dans la familiarité avec le produit. Une bonne QA connaît mieux que quiconque le fonctionnement réel du produit
    Elle a une vision d’ensemble du système tel qu’il est vu par l’utilisateur, souvent meilleure que celle du PM, des commerciaux ou de la plupart des équipes de développement, et peut dire exactement ce qui se passe quand on appuie sur tel ou tel bouton. Une mauvaise QA peut certes être une source de bruit, mais c’est aussi vrai des mauvais développeurs, administrateurs systèmes ou supports de niveau 1/2
  • Une bonne QA joue pour les développeurs le même rôle qu’un bon éditeur pour un écrivain. Elle regarde froidement le fruit d’un travail acharné et le critique sans ménagement
    Sur le moment, c’est vraiment agaçant, mais la qualité du résultat final s’en trouve largement améliorée
    Autrefois, la QA n’écrivait généralement pas de tests ; elle testait le code manuellement et essayait toutes les choses bizarres qu’on espère qu’un utilisateur ne fera jamais. Elle trouvait ainsi des problèmes et des bugs difficiles à détecter de manière générale par des tests
    Aujourd’hui, on a refilé la QA aux utilisateurs. En travaillant avec de jeunes développeurs, j’ai de plus en plus l’impression que le concept même de QA leur devient étranger. Quand un bug part en production et qu’on demande « ça donnait quoi quand tu l’as manipulé en local ? », on récolte souvent des regards perplexes. Comme si le simple fait d’avoir passé le vérificateur de types suffisait à justifier la mise en prod
    De nos jours, l’efficacité des programmeurs se mesure au nombre de PR par minute, donc introduire des bugs n’est pas un problème, c’est presque une bonne chose. Si quelqu’un les repère en production, on peut soumettre quelques jours plus tard une autre PR pour les corriger. S’il y avait eu de la QA, cela aurait perturbé ce flux
  • Je suis QA et j’écris des tests pour l’ingénierie ; mon intitulé de poste exact est SDET. Je m’occupe non seulement des plans de test, mais aussi des frameworks de test, de l’infrastructure et de l’automatisation de ces plans de test
    Chaque entreprise met en œuvre la fonction QA différemment. Certaines la confient aux clients, d’autres aux développeurs, au support client, à la QA manuelle ou aux SDET. Au final, tout dépend de l’importance que le leadership accorde à la qualité et de sa perception de la QA
    S’il existe une équipe QA, elle a selon moi le plus de chances de réussir si elle intervient tôt dans le processus. Une bonne équipe QA devrait trouver des bugs avant même que le code soit écrit. Plus elle arrive tard, plus les bugs sont découverts tard, et plus elle se fait sévèrement squeezed entre « code terminé » et la release. Une équipe QA doit avoir des capacités d’automatisation pour pouvoir consacrer du temps à de nouveaux cas de test au lieu de répéter indéfiniment des tests manuels
    Cet article me parle assez douloureusement. La QA est parfois traitée comme un citoyen de seconde zone et tenue à l’écart des discussions qui permettent d’obtenir le contexte nécessaire pour bien faire le travail. Quand les bons éléments partent vers le développement ou le product management, la situation empire encore, et cette spirale descendante existe bel et bien
  • Comme il n’existe pas de méthode formelle pour faire fonctionner une organisation QA, il arrive souvent que les gens soient embauchés puis qu’on leur dise de « se débrouiller ». Les autres équipes ne comprennent alors pas le besoin de QA et la méprisent
    Ce qui est décrit ici est un problème de leadership, pas un problème d’utilité de la QA
  • Dans le modèle classique, la plupart des organisations QA fonctionnaient comme des appendices inutiles. C’était en partie structurel, et aussi parce que la QA se faisait écarter dès que le développement prenait du retard
    Sans être intégrée dès le début, la QA passait son temps à construire l’infrastructure de test et les plans de test, puis recevait à la fin un bloc de code et un calendrier de validation de 48 heures, avec une pression extrême pour signer le go final
    Mais il arrivait parfois de tomber sur des organisations QA qui comprenaient profondément le domaine du problème et guidaient réellement le développement. Elles avançaient en parallèle du développement du début à la fin, amélioraient la qualité et faisaient gagner du temps à tout le monde

• Lors de la création de FoundationDB, l’équipe s’est concentrée sur la qualité et les tests à un niveau proche de l’obsession. Elle est même allée jusqu’à créer un langage appelé Flow, afin de simuler de manière déterministe des clusters FDB de taille arbitraire, de les soumettre à des conditions extrêmes, puis de signaler toute violation des propriétés du système et de reproduire parfaitement l’exécution de test ayant provoqué cette violation
  Chaque nuit, des dizaines de milliers d’exécutions de test étaient lancées, jusqu’à atteindre un point où, en l’absence de nouveau code, elles étaient pratiquement toutes au vert par défaut
  Les tests qui passaient au rouge étaient presque toujours dus à un ajout de code récent, ce qui permettait de les identifier et de les corriger facilement
  Grâce à cela, l’équipe pouvait développer en sachant que les nouveaux bugs introduits seraient détectés rapidement, ce qui a permis d’avancer assez vite pour entreprendre avec confiance des projets audacieux comme la réécriture du système de traitement des transactions après la mise en production
  Cela a même permis d’obtenir un gain de performance de 10x
  Au final, l’attention portée à la qualité s’est traduite par de la vitesse, et les deux n’étaient absolument pas en contradiction. Je ne pense pas qu’il s’agisse d’un cas isolé, et c’est ce qui a mené au nouveau projet, mais ce sera pour une autre fois

  • Est-ce bien ce Flow-là ? https://github.com/apple/foundationdb/blob/main/flow/README....