Tous les 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)
Le test en image (1)
et que j’ai utilisées pour des posts, des articles ou des présentations. Qu’est-ce que le test? Dans quel but teste-t-on? Le test n’améliore pas la qualité, il donne une vision Le paradoxe des pesticides Les différents tests Quand utilise-t-on ces différents tests? Les cycles de vie de tests et des bugs 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
Le shift left
Le shift left testing est un terme qui revient régulièrement lorsque l’on parle de tests. Il revient notamment dans certains commentaires de mes articles. A quoi correspond exactement le shift left testing et pourquoi est-il autant mis en avant ? Le shift left est une image par rapport au cycle en V que voici : Shift left testing signifie faire venir la partie test dans la branche gauche du cycle en V. Plus concrètement c’est commencer le test le plus tôt possible dans le processus projet. Le shift left testing pourrait donc être vu comme un « test en continu » tout au long du