Donnez un coup de fouet à votre BDD
Auteur : Octane Enabling Enterprise BDD
Source : Speak to us about Jumpstarting your BDD
Traducteur : Fabrice Aimetti
Date : 26/02/2019
Traduction :
BDD implique 3 rôles principaux : métier, développeur et testeur. Ces rôles ne sont pas propres aux individus, une seule personne peut jouer plusieurs rôles. Au sein d'Octane, le lancement du BDD peut être initié par le représentant métier, par exemple un product owner qui définit une user story dans Octane.
Le testeur ajoute ensuite un test gherkin comme critère d'acceptation de la user story.
Dès le début, Octane prend en charge la traçabilité entre les artefacts BDD. Au fur et à mesure que les critères d'acceptation sont ajoutés à la user story en tant que test gherkin, ils sont affichés dans l'onglet relation d'Octane (illustré ci-dessous).
Une fois que le test gherkin, en tant que critère d'acceptation, est ajouté au backlog, c.-à-d. sous la forme d'une user story, le développeur commence à concevoir et à développer le code concernant la feature, en se basant sur la user story et le test gherkin. Le développeur peut utiliser un plugin IDE pour IntelliJ, Eclipse et Visual Studio pour se connecter directement depuis son espace de travail à Octane et voir le module intégré "MY WORK". Le module "MY WORK" ne montrera au développeur que les tâches, les items de backlog et les tests qui sont pertinents et qui lui sont affectés.
Le testeur peut alors commencer à automatiser tous les scénarios en utilisant un framework BDD tel que Cucumber ou SpecFlow. Le testeur peut également utiliser le plugin IDE pour IntelliJ, Eclipse et Visual Studio pour se connecter directement depuis son espace de travail à Octane et voir le module intégré "MY WORK" . Le module "MY WORK" ne montrera au testeur que les tâches, les items de backlog et les tests qui sont pertinents et qui lui sont affectés. Le testeur peut automatiser les cas de test à l'aide de l'outil de son choix : Cucumber, SpecFlow, UFTPro (LeanFT), Selenium, Appium, etc. Les deux rôles travaillent en parallèle dans leurs domaines respectifs.
Une fois que les deux ont terminé leur travail, la feature et la user story associée peuvent être vérifiées et validées à l'aide des tests automatisés créés par le testeur.
Il y a différentes façons de démarrer le pipeline de build d'une application : * Directement à partir d'Octane * Le développeur commite le code dans un référentiel de code source (repository) * Directement via un serveur d'intégration continue (CI) tel que Jenkins, Bamboo, TeamCity, GoCD et/ou TFS.
L'exécution du pipeline exécutera les tests automatisés associés.
Une fois l'exécution de l'Intégration Continue terminée, le product owner peut voir sur son tableau de bord :
- la couverture des features par ordre d'importance
- le nombre de critères d'acceptation (tests gherkin) réussis
- le nombre de user stories implémentées dans le build / la version actuelle
- le nombre d'échecs et de défauts, etc.
Mettre en oeuvre Enterprise BDD avec Octane : c'est la facilité avec laquelle la culture BDD peut être pratiquée, en augmentant le rythme de livraison, en comblant toutes les lacunes entre les product owners, les développeurs et les testeurs, et en fournissant une visibilité sur les activités courantes à traiter.
En action dans cette vidéo :
