J'y ai travaillé. ST a surtout besoin que les puces soient livrées sans bug, car on peut pas facilement livrer un fix sur du silicium. L'effort en tests est assez important a ce niveau dans cette industrie en général et a ST en particulier. A l'époque on avait un objectif de nombre de bugs par mm2 de surface, bon c'est toujours un peu couillon ces métriques mais ça démontre l'importance du sujet.
Moi aussi, mais le nombre d'erreur par mm2 est un élément multifactoriel et c'est plus lié aux logiciels des ateliers eux-même qui a ce que je sache ne sont pas fait en internet. Je pensais plus à la gestion des lots parce que c'est un sujet bien plus simple.
Si on livre le logiciel qu'une seule fois
Je comprends ce que tu veux dire, mais la métrique ne me parait pas bonne. L'idée c'est de ne pas tester qu'à la livraison. Si tu as 6 mois de développement tu veut t'assurer que ce qui a était fais le premier jour fonctionne encore 3 mois après et éviter de t'en rendre compte le jour de l'unique livraison.
Mais ce que je n'ai sans doute pas assez fais ressortir c'est que c'est issu d'un alignement des objectifs. Que le manager veuille de la rentabilité à tout prix ou de la qualité ou autre chose n'est pas un problème en soit c'est juste qu'il faut que les développeurs en soient conscients et s'assurer que c'est bien ce que l'on veut (qu'on est ok d'avoir potentiellement beaucoup de retours utilisateurs par exemple).
[^] # Re: Tests différents (ou partiels)
Posté par barmic 🦦 . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à 2.
Moi aussi, mais le nombre d'erreur par mm2 est un élément multifactoriel et c'est plus lié aux logiciels des ateliers eux-même qui a ce que je sache ne sont pas fait en internet. Je pensais plus à la gestion des lots parce que c'est un sujet bien plus simple.
Je comprends ce que tu veux dire, mais la métrique ne me parait pas bonne. L'idée c'est de ne pas tester qu'à la livraison. Si tu as 6 mois de développement tu veut t'assurer que ce qui a était fais le premier jour fonctionne encore 3 mois après et éviter de t'en rendre compte le jour de l'unique livraison.
Mais ce que je n'ai sans doute pas assez fais ressortir c'est que c'est issu d'un alignement des objectifs. Que le manager veuille de la rentabilité à tout prix ou de la qualité ou autre chose n'est pas un problème en soit c'est juste qu'il faut que les développeurs en soient conscients et s'assurer que c'est bien ce que l'on veut (qu'on est ok d'avoir potentiellement beaucoup de retours utilisateurs par exemple).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll