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)Lire la suite 6 : Modélisation business et graphique d’éléments d’une macro-fonctionnalité
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 “motLire la suite 5- Illustrer et appréhender les concepts
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 laLire la suite 4- Problèmes sur les US : leurs critères d’acceptation
Plusieurs sujets posent un vrai problème sur le terrain. Vouloir les ignorer ou rester dogmatique, ce n’est pas la bonne attitude et les problèmes surgissent. Peut-on les clarifier ? US INVEST : quelle signification ? Une User Story doit être INVEST, dit-on. Que signifie cet acronyme ? US INVEST : une US est-elle toujours indépendanteLire la suite 3- Problèmes sur les US : leur définition
Ce sujet pourrait paraître évident. En réalité, il ne l’est pas. Il y a, en fait, une grande incompréhension sur le terrain, de la définition de ce terme au regard de la théorie. Revenons sur ce sujet avant d’avancer sur les spécifications et les tests. Dans l’esprit des personnes qui ont initié le mouvement agile,Lire la suite 2- Définir une user story selon la théorie
Le but de cette nouvelle série d’articles est de vous montrer comment, dans l’hypothèse où vous n’avez pas un outil ATDD de génération automatique de test (ce qui est la situation la plus courante), spécifier et générer les tests d’un système de manière rigoureuse, rapide et … simple ! Cette méthode est valable pour les systèmesLire la suite 1- ATDD “manuelle” : Ce qu’il faut comprendre du sujet
Nous voici arrivés en fin de l’étude ATDD pour comprendre ce dont il s’agit et pour montrer son utilisation en agile à l’aide d’un outil. Un étonnement : pourquoi l’ATDD n’est-il pas encore vu comme un outil indispensable à l’agile ? Il est assez incroyable de voir qu’en 2022 l’ATDD est encore au stade embryonnaire alorsLire la suite ATDD : Ce qu’on peut en conclure
Voyons comment un outil ATDD peut traiter la validation d’un produit (toutes ses fonctionnalités doivent marcher), mais dans le cadre d’un développement agile. Test des fonctionnalités nouvelles en agile : le constat En agile, nous l’avons vu, nous avons utilisé les colonnes complémentaires pour tracer les artefacts agiles (par exemple les US dans les tâches,Lire la suite ATDD : génération automatique et gestion des tests dans un cadre agile
Le shift left en quelques mots Le Shift left est un concept qui existe depuis de nombreuses années qui a fait l’objet d’un de mes premiers articles début 2017. De manière générale le shift left est la mise en application du principe « Tester tôt« . Le shift left n’est ni un concept agile, ni une méthodologieLire la suite Pourquoi mettre en place le shift left ?
Evidemment le gros avantage d’un outil ATDD est de produire les scénarios de tests, puis les tests, à partir de la modélisation effectuée : les graphiques et les tables. Que faut-il en penser ? Points d’attentions à avoir sur un générateur automatique de tests ATDD Trois points sont au moins à vérifier : L’outil vous proposeLire la suite La génération automatique de tests avec un outil ATDD
La taverne du testeur 