Tous les articles
ATDD : Ce qu’on peut en conclure
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 alors que, biberonné aux spécifications semi-formelles et aux générateurs automatiques de tests dans le cadre de développement de logiciels embarqués, il me paraît évident que l’agilité passe par : Les outils ATDD restent marginaux, alors que les techniques graphiques et tables de décision, très simples (pas de MBT fondé
Petits trucs de testeur: le retest
Introduction Un testeur est amené, dans son quotidien à découvrir des anomalies (c’est normal il les cherche!). Ces anomalies font l’objet d’un processus (workflow) qui les amène régulièrement (ce n’est pas toujours le cas) à être corrigés. Lorsque la correction de ce bug relève d’une modification du code (des fois cela peut être autre chose comme une modification des spécifications) et que cette dernière a été effectuée, la correction de l’anomalie se doit être validée… c’est ce que l’on appelle le retest. Il semble évident pour beaucoup que le testeur est amené à faire ce retest ce n’est pas malheureusement pas
ATDD : génération automatique et gestion des tests dans un cadre agile
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, ou les epics dans une fonctionnalité UC). Donc le générateur devrait nous sortir les plans de test par artefact agile (par US par ex) pour les donner au testeur. Autrement dit un outil ATDD doit être capable de générer plusieurs types de scénarios agiles : On constate
Cerberus Testing 4.15: Une mise à jour pleine de surprises – Antoine Craske
Le monde du test automatisé est en plein essor. Avec un marché mondial totalisant 20.70 milliards d’euros en 2021¹ et une croissance annualisée estimée à 19% d’ici 2030, le déploiement de tests automatisés s’accélère pour aider les entreprises à se transformer. Les apports majeurs de l’automatisation de tests remontés dans le World Quality Report 2022-23² sont de contribuer à la mise en place d’une démarche de CI/CD (55%²) et l’amélioration de la valeur des tests tout en réduisant leur nombre (53%²). La meilleure valeur des tests automatisés est d’ailleurs captée par les tests fonctionnels (46%²) et pour les tests d’intégrations (45%²).
Pourquoi mettre en place le shift left ?
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éthodologie ni même une pratique! En fait on se rapproche plus d’une philosophie ou un état d’esprit que je résumerai comme ceci: s’assurer à chaque étape de la construction que ce que l’on produit est de qualité. Afin de s’assurer de la qualité de notre construction logicielle