ST a une nécessité vital que les logiciels critiques de ses salles blanches fonctionnent parfaitement par exemple.
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.
Sinon je vais me faire l'avocat du diable avec notre ami le manager : oui la question de la rentabilité de faire des tests se pose. Si on livre le logiciel qu'une seule fois et qu'on y touchera plus ensuite, a priori ça sert a rien de s'embêter a pousser les tests. Il est également possible que l'application soit hyper simple a tester, et a ce moment là une validation manuelle peut aussi bien marcher et être là manière la plus efficace de travailler.
Mais si on doit livrer souvent, que l'application devient plus complexe ou que malgré les tests manuels des régressions passent entre les mailles du filet, alors a ce moment là je dirais qu'il faut se lancer sur des tests e2e et que le retour sur investissement sera très rapide. Notons tout de même que ce besoin arrive assez rapidement dans la vie d'un projet.
[^] # Re: Tests différents (ou partiels)
Posté par flagos . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à 3.
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.
Sinon je vais me faire l'avocat du diable avec notre ami le manager : oui la question de la rentabilité de faire des tests se pose. Si on livre le logiciel qu'une seule fois et qu'on y touchera plus ensuite, a priori ça sert a rien de s'embêter a pousser les tests. Il est également possible que l'application soit hyper simple a tester, et a ce moment là une validation manuelle peut aussi bien marcher et être là manière la plus efficace de travailler.
Mais si on doit livrer souvent, que l'application devient plus complexe ou que malgré les tests manuels des régressions passent entre les mailles du filet, alors a ce moment là je dirais qu'il faut se lancer sur des tests e2e et que le retour sur investissement sera très rapide. Notons tout de même que ce besoin arrive assez rapidement dans la vie d'un projet.