Tous les articles
La conception des tests
Le cycle de vie d’un test commence toujours par la conception (design) : Cette phase est différente de l’écriture et son but est tout autre. Le but de l’écriture c’est de mettre sur papier ce que l’on va tester et de s’assurer que cette exécution sera toujours la même. Mais d’écrire ce que l’on va tester il faut savoir exactement ce que l’on veut tester. Le but de la conception des tests c’est justement de choisir ce que l’on va tester. Choisir ce que l’on va tester, choisir comment on va le tester, choisir quels seront les tests à automatiser, les tests
Le test en image (2)
Pyramide niveaux des tests L’importance des tests métier Exécution seule TDD Processus cas en échec N’hésitez pas à rejoindre le groupe Le métier du test N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
L’analyse des tests en échec
Je dis dans mon article sur « l’exécution seule » que cette dernière ne sert à rien sans analyse. Pour rappel l’analyse se fait sur un cas en échec : Cette analyse a pour but de savoir pourquoi le cas est en échec. Si cet échec est causé par un bug, fournir les informations nécessaires à sa correction. Les raisons d’un cas en échec peuvent être : · Un vrai dysfonctionnement de l’application · Un problème d’environnement (instabilité) ou de données (ex : chercher un vol un dimanche alors que ce dernier n’existe que du lundi au samedi) · Le test qui est mal écrit et ne vérifie pas
La faute à qui?
Cette idée d’article m’est venue suite à une discussion avec Rajae AOUCHI lorsque j’ai publié cette caricature. La question est simple: Qui est responsable dans ce cas? Afin d’avoir une réponse plus précise je vais préciser un contexte: Les tests sont effectués, tout va bien sauf un problème critique qui est détecté sur les freins. Un bilan très court est envoyé au métier: Tout fonctionne parfaitement sauf les freins Le métier ne cherche pas plus et décide de sortir en production pour ne pas être en retard. Qui est responsable de cet accident? Voici mon point de vue: Le métier a
L’exécution seule…
L’exécution seule est un gros problème dans le métier du test et ce pour plusieurs points: · C’est la caricature du métier : on croit souvent qu’un testeur ne fait qu’exécuter des tests. cette réduction est la même que si l’on disait qu’un recruteur ne faisait que faire passer des entretiens… · Elle n’apporte aucune valeur : Qui est capable de me donner la qualité d’un logiciel si je dis simplement que 25% des cas sont en échec ? (remarque : rien qu’en sachant qu’il y a 25% d’échec je suis allé au-delà d’une exécution simple, j’ai regardé les résultats… Même ça, ce n’est pas toujours fait)