Tous les articles
Comment bien définir le périmètre de test – Arnaud Verin
L’étendue du périmètre de test Le périmètre de test d’une application peut rapidement s’approcher de « l’infini » ou en tout cas être trop grand pour être vérifié dans des délais et budgets raisonnables. Par exemple pour l’achat d’un billet de train, on pourrait tester : Pourquoi ces trois cas de test et pas d’autres ? Comment choisir le bon périmètre de test ? (Dans l’exemple ci-dessus on pourrait faire des milliers de cas, voire beaucoup plus.) Tester des cas d’utilisation métier Un bon test est avant tout une simulation d’une future utilisation de la solution. Les logiciels étant très paramétrables ou permissifs,
5- Illustrer et appréhender les concepts
Prenons l’US INVEST classique “S’authentifier de manière simple” destiné à un client ou un prospect déjà identifié. Cela signifie que, dans le sprint prévu, le choix qui a été fait est de pouvoir s’authentifier par identifiant et mot de passe, avec 3 tentatives maximum, mais que l’utilisateur ne peut pas encore se rattraper par “mot de passe oublié”. Cela fera l’objet d’une US ultérieure. L’exemple d’une authentification simple Voici, au format excel ou avec tout outil de rédaction de plan de test (un lien avec l’outil de ticketing est alors prévu), la tâche correspondante telle que je la prévois dans un
A la recherche de la qualité perdue: la citadelle inexpugnable
Rappels des chapitres précédents L’application « New Soft » autrefois reconnue pour sa grande qualité n’est maintenant plus que l’ombre d’elle même et est envahie de bugs. Afin de retrouver la qualité perdue les représentants de l’application on nommé une communauté (les fameux Antoine le Berserker (surnommé BA), Délphine la Valkyrie (surnommée Dev), Quentin l’Ase (surnommé, QA) et Pauline l’Orc (surnommée PO)) pour aller chercher Eric Pournoo qui suite à des investigations poussées et des échanges dans la taverne du testeur leur a donné une feuille de route pour retrouver le lustre d’antan de New-Soft. Dans sa grande générosité Eric a également offert
4- Problèmes sur les US : leurs critères d’acceptation
Nous avions suggéré lors de la présentation de l’ATDD automatisé que nous puissions assimiler les principes agiles pour les US de la manière suivante : Les scénarios de test peuvent, quant à eux, se présenter textuellement sous la forme Gherkin : “Etant donné que … Quand … Alors”. Cette décision est en concordance avec la philosophie de l’outil ATDD. Mais cette position “critères d’acceptation (RG) vs Scénarios de test” est-elle encore tenable lorsqu’on n’utilise pas d’outil de génération automatique de scénario de test ? Que disent les démarches agiles ? Une US doit être documentée avec : On perçoit une chose
A la recherche de la qualité perdue: la route de la sueur et les contrées étrangères
Rappels des chapitres précédents L’application « New Soft » autrefois reconnue pour sa grande qualité n’est maintenant plus que l’ombre d’elle même et est envahie de bugs. Afin de retrouver la qualité perdue les représentants de l’application on nommé une communauté (les fameux Antoine le Berserker (surnommé BA), Délphine la Valkyrie (surnommée Dev), Quentin l’Ase (surnommé, QA) et Pauline l’Orc (surnommée PO)) pour aller chercher Eric Pournoo qui suite à des investigations poussées et des échanges dans la taverne du testeur leur a donné une feuille de route pour retrouver le lustre d’antan de New-Soft. Dans sa grande générosité Eric a également offert