Supprimer l’équipe QA était peut-être en réalité une mauvaise décision
- La partie la plus lente du déploiement logiciel, c’est le testing. Si le déploiement continu existe, c’est à cause du testing, donc le fait que ce soit le goulot d’étranglement peut être considéré comme un état optimisé.
- Les habitudes et comportements d’optimisation ont conduit l’industrie à considérer l’équipe QA comme un goulot d’étranglement et à chercher à l’éliminer. Cela a entraîné une baisse du respect accordé au rôle de QA et des problèmes de production de logiciels de qualité.
- Les développeurs ne maîtrisent pas vraiment la gestion de la qualité logicielle. Beaucoup d’organisations ne savent pas clairement à qui incombe la responsabilité de la qualité logicielle, et même celles qui ont conservé une fonction QA peinent à lui trouver sa place.
Ce qu’il faut faire pour gérer la qualité dans les pratiques logicielles
- Suivi des défauts : il faut un moyen pour que les utilisateurs fournissent des informations sur les bugs et pour que les développeurs les enregistrent.
- Triage : le triage des bugs est le processus qui consiste à gérer leur attribution, leur priorisation, leur nettoyage, leur classification et la suppression des doublons.
- Investigation des défauts : reproduire un bug est une partie essentielle de sa gestion, et cela demande un effort d’ingénierie pour identifier le vrai problème et le résoudre.
- Focalisation : l’entreprise doit compter des personnes concentrées sur la qualité, capables de la défendre afin d’équilibrer qualité et vitesse.
- Tests de bout en bout : les problèmes de propriété du système naissent d’architectures complexes, ce qui conduit à l’absence de tests en conditions réelles avant la sortie du produit.
L’avis de GN⁺
- Supprimer l’équipe QA est une erreur de management qui peut avoir, à long terme, un impact grave sur la qualité logicielle.
- Dans le processus de développement logiciel, l’assurance qualité est un travail essentiel, et l’ignorer ou le minimiser peut finir par mener à l’échec.
- Cet article est intéressant en ce qu’il remet en lumière l’importance de la QA dans l’industrie logicielle et souligne la nécessité d’une compréhension adaptée de la gestion de la qualité ainsi que d’une répartition claire des rôles au sein de l’organisation.
1 commentaires
Avis Hacker News
À la fin des années 1970 chez IBM, j’étais chargé de l’assurance produit et j’écrivais du code de test ainsi que je montais le matériel pour le produit dont j’avais la charge (un système de traitement de texte). Je ne communiquais pas en détail les cas de test à l’équipe de développement, seulement les problèmes généraux, afin de les pousser à corriger les bugs. En comparant les écarts entre les bugs découverts de cette manière et ceux corrigés par l’équipe de développement, il était possible de calculer statistiquement une estimation des bugs restants.
Dans les organisations sans équipe QA, on a introduit le concept de « sniff test ». Il s’agit d’une session où tout le monde dans l’entreprise teste intensivement une nouvelle fonctionnalité pendant une courte durée (en général une heure), ce qui aboutissait à la création de nombreux tickets de bugs. Le fait que des tests simples provoquent souvent des problèmes n’est désormais plus surprenant.
Deux entreprises où j’ai travaillé il y a 15 à 20 ans investissaient dans des équipes QA de tout premier niveau, et celles-ci excellaient à trouver des bugs auxquels les développeurs ne pensaient pas. L’équipe QA avait l’autorité finale pour décider si le produit pouvait être publié ou non. Aujourd’hui, beaucoup d’entreprises pensent qu’il vaut mieux que les développeurs écrivent des tests automatisés et passent beaucoup de temps sur la couverture de code, mais j’ai vu beaucoup de produits qui, en pratique, ne fonctionnaient pas. Ce n’est pas une critique des tests automatisés en soi, mais une remise en cause de la suppression des testeurs QA humains.
Les employés les plus consciencieux dans une organisation sont souvent aussi les plus insatisfaits. Ils perçoivent les problèmes de qualité et essaient de les résoudre, mais ne sont pas reconnus, et lorsqu’ils parlent de qualité, on les traite comme des gens qui veulent faire avancer les choses plus lentement. Pendant que ceux qui « avancent vite et cassent des choses » continuent d’être récompensés, eux s’énervent à devoir réparer derrière et sentent que le fait de se soucier des choses peut nuire à leur carrière dans l’organisation.
La QA tend à être considérée comme un « centre de coûts » par l’entreprise et la direction. Il existe l’idée qu’il vaut mieux éviter de travailler dans un service perçu comme un « centre de coûts », car la rémunération et la reconnaissance reviennent toujours à ceux qui génèrent du revenu. La QA doit faire plus avec moins de personnel, se fait reprocher les échecs, et peut être le premier endroit où l’on licencie quand l’entreprise doit se rationaliser.
Les ingénieurs QA ont d’excellentes compétences en debug. Ils travaillent sur tous les aspects de l’application, y compris les pipelines, le code source et les répertoires de test, et il arrive souvent que les ingénieurs logiciel ne lisent pas les messages d’erreur du pipeline, ignorent le problème de fond et passent des journées à deviner une solution. Le mépris envers les ingénieurs QA n’est pas exagéré dans l’article, et comme les organisations QA ne passent pas par des processus d’entretien aussi stricts que les organisations d’ingénierie, les ingénieurs QA sont considérés comme inférieurs.
D’après mon expérience personnelle, je n’ai jamais rencontré d’équipe QA qui écrive réellement des tests pour l’ingénierie. La plupart des équipes QA exécutent des « plans de test » manuellement ou, plus rarement, via des tests automatisés sur navigateur/appareil. Ces types de tests ont de la valeur, mais pas autant que les « tests unitaires » ou les « tests d’intégration ». Dans ce modèle, c’est en réalité l’équipe d’ingénierie qui assure le vrai rôle de QA plus que l’équipe QA elle-même, et l’équipe QA finit souvent par signaler comme bugs des choses qui n’en sont pas, ce qui réduit sa valeur.
Microsoft a constaté davantage de bugs dans Windows et ses produits cloud après avoir supprimé ses équipes QA.