Que devons-nous tester ? Cette question qui semble élémentaire se trouve être une des plus complexes dans le monde de la qualité et du test… tout en étant peut être la plus importante car, mais est-il nécessaire de le rappeler ?, les tests exhaustifs sont impossible. Vous l’aurez reconnu, on parle ici du périmètre deLire la suite Que devons-nous tester ?
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 qu!) de travailler sur la qualité des US. Pour rappel, une US se doit d’être INVEST. PourLire la suite Qualité des US
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 uneLire la suite 20 : De l’ATDD pratiquée manuellement à l’ATDD automatisée (2 / 2)
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éLire la suite 19 : De l’ATDD pratiquée manuellement à l’ATDD automatisée (1 / 2)
18 : Conseils d’application de l’ATDD en mode manuel et agile (3 / 3)
Considérons maintenant deux exemples où une tâche est touchée par des modifications de spécifications internes (changements d’ergonomie, règles de gestion, … qui auraient dû être pris en compte au sein de l’US INVEST initiale). Elles ne peuvent pas être qualifiées d’INVEST … Les US étant déjà de tailles très faibles, le PO ne peut qualifierLire la suite 18 : Conseils d’application de l’ATDD en mode manuel et agile (3 / 3)
17 : Conseils d’application de l’ATDD en mode manuel et agile (2 / 3)
Quels sont les différents cas particuliers à considérer pour bien appliquer l’ATDD manuelle en mode agile ? Voyons quelques réponses à travers la suite de notre exemple. Intégrer de nouvelles US INVEST qui étendent une fonctionnalité Le sprint 2, par exemple, étend le modèle de la feature F3 (une seule US “s’authentifier de manière simple”,Lire la suite 17 : Conseils d’application de l’ATDD en mode manuel et agile (2 / 3)
Les DoD et DoR supports essentiels à la qualité en Agile
Le cycle en V n’est jamais loin! On ne va pas se le cacher, même si les développements logiciels sont de plus en plus fait avec des méthodes Agiles, l’influence des méthodes dites « traditionnelles » comme le cycle en V reste particulièrement prégnante. Cette influence s’explique d’ailleurs assez simplement par le fait que ces méthodes ontLire la suite Les DoD et DoR supports essentiels à la qualité en Agile
16 : Conseils d’application de l’ATDD en mode manuel et agile (1 / 3)
Envisageons la situation où nous sommes une équipe agile ayant à spécifier et tester un parcours client en démarche agile, et sans outil autre qu’un outil de ticketing et un outil comme support des exigences et des tests (définition et exécution). C’est le cas le plus courant … Illustrons alors par un exemple l’approche deLire la suite 16 : Conseils d’application de l’ATDD en mode manuel et agile (1 / 3)
[Webinaire] les exigences en Agile
Le vendredi 24 mars a eu lieu le 2ème webinaire de l’année de la taverne. Jérôme Khoualed (expert test et gestion des exigences) et Christophe Moustier (expert test agile et auteurs de 2 livres sur le sujet) nous ont parlé de l’industrie des exigences à travers l’IREB et de ses liens/applications avec les tests (ISTQB)Lire la suite [Webinaire] les exigences en Agile
15 : Concevoir rapidement et progressivement les scénarios de tests d’une fonctionnalité avec l’algorithme des tamis successifs (3 / 3)
Prenons l’exemple de la fonctionnalité F représentée par le schéma ci-dessous : Voyons comment traduire ce graphique dans une table ATDD qui nous fournira systématiquement les scénarios de test et, accessoirement, montrera comment les exigences fonctionnelles pourraient s’énoncer en Gherkin comme des RG de haut niveau. Réaliser une table ATDD à partir du langage graphiqueLire la suite 15 : Concevoir rapidement et progressivement les scénarios de tests d’une fonctionnalité avec l’algorithme des tamis successifs (3 / 3)