Discussion :

[foufa007]

Salut,

j'aimerai savoir à quel point effectuer des tests c'est important pour assurer la qualité du produit logiciel.
En fait je cherche exactement quelques exemples de dégats causés par un <<mal test>> disons ou une mauvaise adéquation de la spécification.
Merci

[tipiak]

Salut,

j'aimerai savoir à quel point effectuer des tests c'est important pour assurer la qualité du produit logiciel.
En fait je cherche exactement quelques exemples de dégats causés par un <<mal test>> disons ou une mauvaise adéquation de la spécification.
Merci

disons que les réponses à tes questions se situent plus vers la gestion des risques
(et non vers les tests en soit)

ne pas tester c'est accepter certains risques ... et leurs conséquences
si tu considere que tes developpeurs font exactement ce que le client demande tu n'as pas de risques donc pas besoins de tests ...
les tests sont un moyen de mitiger et de maitriser certains risques...

de même si les conséquences d'un risque sont minimes tu peux tolerer ce risque (inutile aussi de tester)


Ensuite je ne suis pas d'accord avec le : "une mauvaise adéquation de la spécification"
ca c'est pour vérifier que ton appli correspond à la spec hors tout les tests ne servent pas qu'à cela...
ils peuvent tester l'architecture (tests integration), tester les business requirements (tests utilisateurs), tester que l'appli se comportent bien sur l'architecture hardware cible (tests de configuration)
et j'en passe

pour les exemples:

pb de spec: je ne sais plus quelle sonde spatiale qui s'est plantée dans Mars: un module comptait en Pied et un autre en Metres
c'est typiquement un pb de spec (le développeur y est pour rien) les conséquences : cher ....

pb de régression: ariane 5, un de ses modules était celui d'ariane 4 (repris tel quel) , un autre module lui donne une valeur d'acceleration qui se trouve être plus grande que celles gérées par ariane 4 ==> le module d'ariane 4 plante en indicant une acceleration negative (l'intéger à dépassé la plage d'utilisation)
conséquences perte de la fusée

pour les pbs Métier (le developpeur n'est pas non plus en cause): une appli financière qui ne fait pas correctement les arrondi (elle marche mais ne correspond pas aux besoins business)

les exemples sont multiples, le plus souvent tu trouveras des exemples sur l'aeronautique, le nucleair... la ou les conséquences de risques sont souvent très grave.


le site web de ma grand mere avec son livre de recette: elle n'a pas relue avant de publier il y a plein de fautes d'orthographes (ce que l'on peut assimiler à pas de tests) : conséquences : NULL personne ne lit ce site donc on peut accepter l'absence de tests et de process qualité poussés

[foufa007]

merci pour votre réponse,
j'aimerai savoir si les bugs(on en parle souvent) est une conséquence
d'un "non test"

[tipiak]

merci pour votre réponse,
j'aimerai savoir si les bugs(on en parle souvent) est une conséquence
d'un "non test"

les tests permettent de mettre en valeur des BUGs avant mise en exploitation
ils permettent donc de réduire des risques. (car la conséquence d'un BUG lors des tests est souvent moins chere que si la conséquence surevient en Exploitation)

En exploitation tu perds ta fusée, alors qu'en test tu aurai juste fait planter un soft / une puce ....


je n'ai plus les liens en tête (de mémoire c'est l'ISO qui défini bien les termes)
de mémoire pour les process de troubleshooting:

une erreure (ou NON conformité) dans une appli devient une anomalie si cette fonction est appelée (si elle survient). (si tu as une erreur de code dans une portion jamais appelé elle ne surviendra jamais).
suite à ce Anomalie tu vas avoir des DYSFONCTIONNEMENT (ce qui correspond à la propagation de cette erreur), si tu peux IDENTIFIER ces propagation (ou l'anomalie elle même) tu obtiens un BUG (matérialisation visuelle de cette erreur)

un utilisateur final ne verra que le BUG mais cela n'a rien à voir avec le NON-TEST.
les tests aident à faire survenir le bug
les logs, le monitoring etc aident à Identifier la cause du bug (l'anomalie) (en traçant l'enchainement de la propagation des Dysfonctionnement)

mais tu peux aussi réduire les causes de bug par l'amont:
faire qu'il y ai moins de "non conformité" indépendament de l'effort de test
grace aux process de développement, Best practices, design patern, revue, documentation ...

biensure tout ceci reste très théorique...
en pratique ....