Tous les articles
Bon ou mauvais ?
Les indicateurs sont un outil nécessaire mais dont il faut constamment se méfier. Je suis d’ailleurs revenu spécifiquement sur des exemples de dérives dans un article de décembre 2021. Malheureusement la complexité des indicateurs ne se limite pas à leurs potentielles dérives ou la loi de Goodhart. En effet, tout comme les tests, les indicateurs dépendent du contexte… et nous l’allons montrer tout à l’heure! Vous l’aurez compris, dans l’article d’aujourd’hui nous allons faire un jeu sur les indicateurs et déterminer si ce qu’ils remontent est bon ou non! 0 bug remonté pendant la campagne Cet indicateur est particulièrement piégeux. Il
Webinaire: tester une IA
Pour le troisième webinaire de la taverne nous avons le plaisir de vous parler d’un sujet qui fait beaucoup parler de lui actuellement: Les IA! Et plus précisément le test de l’IA. L’IA bouscule notre utilisation des logiciels comme on le voit avec ChatGPT ou les assistants vocaux, il est donc essentiel de savoir les tester. Afin de bien appréhender cette nouvelle discipline la taverne a le plaisir d’accueillir Clément FRANCOIS de la société Kereval qui interviendra sur le sujet du test de l’IA à la prochaine JFTL. Voici la vidéo de la présentation: Ci-dessous le support utilisé: Pensez à rejoindre
Qualité des US
Je parlais dans un article d’il y a 4 semaines de la nécessité de tester la valeur. La nécessité des tests ne s’arrête pas à la valeur et il me semble essentiel, en tant que testeur (mais pas que!) de travailler sur la qualité des US. Pour rappel, une US se doit d’être INVEST. Pour rappel, une US INVEST est une US: Un élément est donc, en théorie, pas une US même si cet élement peut s’avérer essentiel (on peut par exemple parler de features ou d’épiques si non Small ou encore d’enabler en SAFe pour du « non testable ») Ce critère
20 : De l’ATDD pratiquée manuellement à l’ATDD automatisée (2 / 2)
Terminons notre conclusion sur l’ATDD manuelle et l’ATDD automatisée : Structuration de la documentation et outillage Normalement une US INVEST donne lieu à une fonctionnalité dans le produit, c’est-à-dire “une tâche métier”. Les “corrections de spécification” devraient être traitées comme pour les bugs. Ce sont des tickets à évaluer, attachés au plus bas, c’est-à-dire une tâche existante. Si vous les considérez comme des US (ce que nous avons dénoncé dans un article précédent, elles ne sont plus INVEST), plusieurs US de nature différente (les INVEST et les corrections) pointent sur la même tâche et sa documentation. Concernant les tickets de “haut
19 : De l’ATDD pratiquée manuellement à l’ATDD automatisée (1 / 2)
En conclusion de nos articles, d’une part sur l’ATDD avec un outil générant les scénarios de test et les tests (scénarios avec les valeurs spécifiques en conditions et observations), d’autre part une approche ATDD qui spécifie et teste de manière systématique et rapide les exigences, que pouvons-nous dire ? Le test agile doit rester centré sur le produit à livrer Souvent on pense que le test en agile c’est le test des US, celles-ci étant souvent créées même lorsqu’elles ne sont pas INVEST. La série d’articles, je l’espère, rectifie cette vision. Le nombre de scénarios de test doit être proportionnel aux