Principe 2 – Les tests exhaustifs sont impossibles

Tout tester (toutes les combinaisons d’entrées et de pré-conditions) n’est pas faisable sauf pour des cas triviaux. Plutôt que des tests exhaustifs, nous utilisons l’analyse des risques et des priorités pour focaliser les efforts de tests.
Qui n’a jamais rencontré un client qui demande de TOUT tester sur son application. Cette vidéo de moins de 3 minutes fournit une réponse rapide et claire. Les questions et commentaires des lecteurs améliorent la qualité du contenu et font plaisir à l’auteur, N’hésitez pas à m’écrire ci-dessous.

Principe 1 – Les tests montrent la présence de défauts

Les tests peuvent prouver la présence de défauts, mais ne peuvent pas en prouver l’absence. Les tests réduisent la probabilité que des défauts restent cachés dans le logiciel mais, même si aucun défaut n’est découvert, ce n’est pas une preuve d’exactitude.
Plusieurs décennies de tests logiciels ont permis d’identifier des règles auxquelles les tests se soumettent telles des lois de la physique. Re-visiter ces principes se révèle utile même pour des professionnels qui ont des années d’expérience derrière eux. Je vous ai préparé une série de courtes vidéos pour illustrer la substance de ces principes et les rendre accessibles à tous : Clients, Fournisseurs, Manageurs, Développeurs, Testeurs…etc La première vidéo « Principe 1 – Les tests montrent la présence de défauts »explique ce que le test peut faire et ce que le test ne peut pas faire. Les questions et commentaires des lecteurs améliorent la qualité du contenu et font plaisir à l’auteur, n’hésitez pas à m’écrire ci-dessous.

Principe 3 – Tester tôt

En quoi est ce utile d’introduire les tests plus tôt dans un projet ? Vous trouverez la réponse à cette question et plus dans la vidéo du Principe 3: Tester tôt Les questions et commentaires des lecteurs améliorent la qualité du contenu et font plaisir à l’auteur, n’hésitez pas à m’écrire ci-dessous.

Principe 4 – Regroupement des défauts

L’effort de test devrait être fixé proportionnellement à la densité des défauts prévus et constatés dans les différents modules. Un petit nombre de modules contiennent généralement la majorité des défauts détectés lors des tests pré-livraison, ou affichent le plus de défaillances en opération.

Est ce qu’il y des tests plus efficaces que d’autres?

Vous trouverez la réponse à cette question et plus dans la vidéo du Principe 4: Regroupement des défauts Les questions et commentaires des lecteurs améliorent la qualité du contenu et font plaisir à l’auteur, n’hésitez pas à m’écrire ci-dessous.

Principe 5 – Paradoxe du pesticide

Si les mêmes tests sont répétés de nombreuses fois, il arrivera que le même ensemble de cas de tests ne trouvera plus de nouveaux défauts. Pour prévenir ce “paradoxe du pesticide”, les cas de tests doivent être régulièrement revus et révisés, et de nouveaux tests, différents, doivent être écrits pour couvrir d‟autres chemins dans le logiciel ou le système de façon à permettre la découverte de nouveaux défauts
Il arrive que de bons tests soient moins efficaces avec le temps, cette détérioration est due à un phénomène qui s’appelle le paradoxe du pesticide. La vidéo du Principe 5 explique ce paradoxe et propose des solutions pour limiter son impact. Les questions et commentaires des lecteurs améliorent la qualité du contenu et font plaisir à l’auteur, n’hésitez pas à m’écrire ci-dessous.

Principe 6 – Les tests dépendent du contexte

Les tests sont effectués différemment dans des contextes différents. Par exemple, les logiciels de sécurité critique seront testés différemment d’un site de commerce électronique
Testeriez-vous de la même façon une application de gestion des livres et un logiciel de gestion du trafic aérien? Le principe 6 affirme que les tests dépendent du contexte et que chaque projet se déroule dans des conditions qui lui sont spécifiques et la réussite de ces tests exige une stratégie adaptée. Les questions et commentaires des lecteurs améliorent la qualité du contenu et font plaisir à l’auteur, n’hésitez pas à m’écrire ci-dessous.

Principe 7 – L’illusion de l’absence de défauts

Trouver et corriger des défauts n’aide pas si le système conçu est inutilisable et ne comble pas les besoins et les attentes des utilisateurs.

La relation entre la maîtrise d’ouvrage et sa maîtrise d’œuvre peut rapidement se détériorer si on ne comprend pas la réalité décrite par ce principe. Oui un logiciel peut être est jugé inutilisable à juste titre par la maîtrise d’ouvrage alors que le logiciel a un fonctionnement validé conforme aux spécifications par les tests de la maîtrise d’œuvre à juste titre également. Mais comment ça se fait ?!! La vidéo du Principe 7 l’explique en moins de 5 minutes. Les questions et commentaires des lecteurs améliorent la qualité du contenu et font plaisir à l’auteur, n’hésitez pas à m’écrire ci-dessous.