Tous les articles
L’ATDD 2 / 4 : Une spécification hiérarchique des fonctionnalités
Nous avons vu les différentes vues d’un système. Même en agile, il faut les avoir pour comprendre le système et le tester (PO et testeurs : validation des « nouveautés » et de la régression). Alors comment gérer tous ces artefacts et comment poursuivre la décomposition du système jusqu’à aboutir aux US, dont les critères INVEST sont si souvent vantés ? Architecture d’un produit et agilité : les avantages de l’ATDD Les avantages sont multiples : Pour lui la compréhension d’une fonctionnalité est meilleure, au lieu de multiplier des modélisations de features/epics qui ne représentent, en fait, que les nombreux éléments temporaires de développement. En effet,
Mon résumé du WQR 2022-23
Le World Quality Report (WQR) est une (voir la) référence en ce qui concerne les études liées à la qualité. Vous pouvez télécharger ce rapport gratuitement sur ce lien et je vous invite à le faire afin de vous faire votre propre opinion. Tout d’abord je souhaite commencer par le profil des personnes interviewées, comme vous pouvez le constater ces personnes sont principalement des haut placés ce qui assure un très bonne vision sur des chiffres et indicateurs mais peut être une moins précise sur le terrain: Je vous propose maintenant de partager avec vous mon résumé de cette enquête: La
L’ATDD 1 / 4 : Une spécification visuelle des fonctionnalités
Dans une démarche agile, nous avons vu que le BDD s’impose essentiellement pour spécifier les tests des User Stories (US). Mais comment faire pour les éléments plus complexes qui représentent des fonctionnalités, ou des macro-fonctionnalités ? Nous allons présenter la démarche ATDD lorsqu’elle est outillée. Nous pourrons ainsi montrer des copies d’écran. Nous avons en effet voulu vous montrer de manière visuelle, par la pratique, ce que les responsables de spécifications et les testeurs auront comme fonctionnalités à disposition pour appliquer cette démarche. Nous avons ainsi des illustrations concrètes qui seront, nous en sommes sûrs, appréciées. Ceci a été rendu possible par l’utilisation de l’outil YEST. Même si d’autres
La maturité des tests: pistes de réflexion (2/3)
Nous avons vu dans le premier article de cette série qu’il existe actuellement de beaux référentiels visant à évaluer le niveau de maturité des tests indépendamment du contexte. Ces modèles aussi bien soient-ils ont des limites. Ces limites sont par exemple: Afin de répondre à ces problématiques et rendre une évaluation de la maturité plus simple, ou de manière plus pragmatique juste permettre de prioriser les actions d’amélioration à mettre en place de son côté, de nombreux professionnels du test proposent des alternatives plus facile à mettre en place. Cet article vous présentera 3 de ces initiatives afin de vous offrir
Tests en agile : les principaux concepts (2 / 2)
Nous allons aborder dans cet article la présentation des artefacts agiles et leur documentation de test. Nous insisterons sur l’impérieuse nécessité de comprendre que l’agilité ne tue pas la vision du système que doit avoir le PO (ce qu’on veut faire ?), et qui est différente des tickets de développement du système (comment le faire ?). Distinguer artefacts agiles et fonctionnalités du produit Le produit, même si l’on réduit son utilisation à un cas d’usage (le produit utilisé sous des conditions bien précises), possède des fonctionnalités. Les “artefacts agiles” (US, epics, features …) sont les éléments à développer pour réaliser les