Tous les articles
A la recherche de la qualité perdue: les plages de velours et les rocks éternels
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
6 : Modélisation business et graphique d’éléments d’une macro-fonctionnalité
La modélisation système consiste en ATDD à représenter visuellement des éléments d’un système, jusqu’à enchaîner : – Des MUC : pour former de bout en bout des “parcours utilisateur” ou une partie (une activité par exemple). Là encore le PO sera sollicité. D’un autre côté, une équipe de testeurs IT (des Business Analystes par exemple) peuvent vouloir s’assurer de l’intégration de “tâches métiers” dans une UC. En agile ces tâches sont des US INVEST ou des US INVEST ayant subi des modifications successives de détail (au niveau d’une ou plusieurs règles de gestion). Principes de modélisation graphique On a une représentation
Les exigences Agile
Organisation usuelle des exigences Le sujet des exigences et des tests de ces dernières est un sujet sensible mais nécessaire en Agile… Je l’ai d’ailleurs appris à la dure! Sur le papier c’est assez simple, on a un produit. Ce produit est composé de macro fonctionnalités permettant de le définir. Ces macro-fonctionnalités sont les « epics », elles sont composées de « Feature » qui sont des éléments plus petits mais trop grand pour être INVEST et donc une US (User Story), l’élément élémentaire des produits Agile. A noter: il existe d’autres dénomination, je pense notamment à US/Epic/initiatives. Une architecture d’un produit Agile ressemble donc
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