Expérience avec BDD

Il y a environ sept ans, Dan North a décrit dans son article l'application pratique de l'approche BDD, qui vous permet de rendre le processus de développement plus compréhensible et gérable en établissant des communications internes. L'industrie manifeste chaque jour un intérêt croissant pour cette méthodologie, qui vise l'interaction productive d'équipes standard telles que «analytics-development-testing».

Cependant, seule une petite partie des entreprises décident désormais d'utiliser le BDD. Pourquoi?

Alors, découvrons-le. Le BDD (Behavior Driven Development) est une méthodologie flexible étroitement liée au TDD (Test Driven Development - "Development through Testing"). Par expérience, même les testeurs chevronnés ne voient souvent pas la différence entre ces méthodologies. En effet, à première vue, il est difficile de l'isoler: les deux approches impliquent la rédaction de documentation et de tests avant le début de la phase de développement. Et la différence est la suivante: dans BDD, pour décrire les tests, vous devez utiliser un langage naturel compréhensible pour chaque participant au projet afin, en fait, de combiner l'énoncé du problème, les tests et la documentation ensemble. En d'autres termes, DSL (langage spécifique orienté sujet) est défini, puis un ensemble limité d'expressions standard est créé qui décrit le comportement des éléments nécessaires. Ensuite, avec leur aide, un scénario est développé à l'aide de la nouvelle fonctionnalité, qui sera claire pour tout le monde.

Voyons la différence une fois, et cela deviendra évident:

Nous allons aborder cet exemple, mais d'abord, examinons toute la variété des méthodologies qui sont actuellement de pertinence non nulle.

Comparer plusieurs méthodologies

Le diagramme ci-dessous présente une comparaison de trois approches: TDD, TLD (Test Last Development) et BDD:

• Lorsque nous travaillons selon la méthodologie BDD, les spécifications d'autotest et de rédaction accompagnent chaque étape du cycle de développement logiciel, ce qui garantit la pertinence constante des autotests et de la documentation.
• Les méthodologies TDD et ATDD (Acceptance Testing) sont combinées dans un diagramme en un seul bloc, car écrit au stade de l'analyse. Comme mentionné ci-dessus, TDD est basé sur l'écriture de tests avant de développer la fonctionnalité. Le développeur doit écrire des tests afin d'écrire des fonctionnalités pour le test.
• Le TLD (Test Last Development) inclut des tests après la mise en œuvre de la fonctionnalité.
• BDD est universel et peut être inclus à n'importe quel stade de développement.

Le deuxième diagramme montre l'implication des participants dans le processus de développement dans l'écriture de scripts.

• Dans BDD, tout membre de l'équipe peut se connecter aux tests à tout moment, par exemple, analyste, utilisateur professionnel, développeur et testeur, car les tests sont clairs pour tous les participants au processus.
• BDD est également utile dans la mesure où vous n'avez pas besoin de passer beaucoup de temps à rédiger différents types de documentation. Le schéma de développement classique nécessite, au minimum, des spécifications et des scripts de test qui sont généralement écrits par des personnes différentes. Dans BDD, une spécification est un cas de test, alors qu'il s'agit également d'un autotest. Les testeurs n'ont pas besoin d'écrire une documentation de test distincte - pour eux, l'analyste l'a déjà fait, en écrivant une spécification à partir de constructions en langage naturel (qui est lisible et compréhensible par tout membre de l'équipe).

Sans aucun doute, BDD est un bon outil pour atteindre la qualité des produits. Les tests et la documentation sont rédigés plus rapidement. Pour une entreprise, un projet devient plus transparent, grâce à des constructions en langage naturel compréhensibles par toute personne loin de la programmation.

Il s'agit des pros. Néanmoins, comme cela a déjà été dit, malgré un grand nombre d'avantages, peu mettent en œuvre cette méthodologie.

Le BDD est bon pour tout le monde, mais pourquoi ne pas l'utiliser?

La réponse est simple: elle est longue et coûteuse. La plupart des sociétés informatiques seront d'accord avec cette déclaration. Et au début, nous n'avons pas fait exception. Le BDD n'est pas pratique, même s'il nécessite la participation de spécialistes des tests déjà au stade de l'élaboration des exigences.

BDD bouleverse la directive classique de développement (TLD). Elle est mal mise en œuvre car elle est difficile. Le cycle de développement s'allonge.

BDD est sans aucun doute un moyen d'atteindre la qualité. Mais tout le monde n'est pas prêt à payer du temps et des spécialistes pour cette qualité.

Cependant, que dois-je faire si je souhaite toujours implémenter BDD?

Vous pouvez essayer d'utiliser des frameworks prêts à l'emploi. Par exemple Concombre, Squish, Yulup.

Le principal problème de la complexité BDD n'est pas dans le processus, mais dans la mise en œuvre et les outils existants. Prenons WEB comme exemple de développement d'un système d'information d'entreprise. Ayant une implémentation Web, nous rencontrons un WebDriver, qui est actuellement la norme pour automatiser les applications s'exécutant dans un navigateur Web. Il a pas mal d'opportunités. Pour prendre en compte différentes personnalisations des éléments de page, vous devez proposer des options pour y accéder. Et ici, pour faciliter le développement du test, différentes bibliothèques viennent à la rescousse (Selenide, etc.), ce qui crée son propre écosystème que vous devez connaître. Pour travailler avec WebDriver, vous avez besoin d'un programmeur ou d'un testeur-automatisation, car tout est mis en œuvre en utilisant du code et des conceptions astucieuses.

La mise en route du framework BDD est difficile et prend du temps.

Nous nous concentrons sur un instrument appelé Gauge. Il s'agit d'un framework flexible et léger, distribué sous licence gratuite. Franchement, nous n'avons pas vraiment étudié les alternatives, car L'utilisation de Gauge a été agressivement dictée par notre client.

Dans Gauge, les tests sont écrits dans des fichiers de spécifications (fichiers avec l'extension .spec). La spécification contient des étapes de test écrites en langage naturel. Ces étapes sont implémentées dans un langage de programmation (nous avons utilisé le langage de programmation Java). Lors de la mise en œuvre des étapes, il est important de respecter la convention de dénomination à la fois dans les noms du script et des fichiers d'implémentation, et dans les noms des méthodes d'implémentation et des étapes du script, ils doivent être complètement identiques. Une flexibilité supplémentaire de cet outil est que les étapes peuvent avoir des paramètres.

Gauge nous a permis d'utiliser les avantages du BDD. Cependant, nous avons encore rencontré des problèmes qui sont la complexité de la mise en œuvre: les problèmes d'outils et de mise en œuvre du processus.

Il s'est avéré que l'implication des testeurs à un stade précoce a un effet néfaste sur le résultat final. Augmentation du temps pour développer des tests. Utiliser n'importe quel framework nécessite de gros efforts du testeur, qui, sans aucun doute, doit avoir une bonne maîtrise de la programmation. Au début, le processus de travail avec le script était le suivant: l'analyste a dit le test au testeur et le rédacteur technique l'a noté. Pendant que le testeur s'occupait de l'implémentation du logiciel, la signification de la fonctionnalité testée a changé. Cela affecte la séparation du point d'entrée, et il devrait en être un, car le processus est divisé et se transforme en un processus «normal», dont je voulais juste sortir. C'est-à-dire le point d'entrée était divisé, les communications se sont propagées, le testeur s'est lancé dans la mise en œuvre du test, le rédacteur technique l'a compris à sa manière, et l'analyste a réécrit ses quais et a changé d'avis, le développeur est entré dans «son monde»).

Le testeur a passé beaucoup de temps sur le code. Mais toujours le même testeur a dû réfléchir à la recherche d'éléments sur la page. La situation rappelait un célèbre jeu pour enfants: «Téléphone gâté». L'effondrement s'est produit. Et nous avons décidé: BDD ne fonctionnera que si les analystes peuvent écrire des tests. Il est nécessaire de réduire la complexité des tests d'écriture, de les simplifier. Mais pour cela, vous devez simplifier considérablement les interfaces de test. Les outils de test, la mise en œuvre du processus en conjonction avec toutes les approches et bibliothèques devraient être plus simples.

Au début, le travail du testeur ressemblait à ceci:

1. Examen de la documentation, le cas échéant;
2. Etablir une liste de contrôle;
3. Tests ad hoc
4. Élaboration d'un plan de test;
5. Affinement de la vision du monde de l'analyste;
6. Amélioration de l'image du monde par le développeur;
7. Si tout a grandi ensemble, rédiger la documentation du test, en parallèle avec le test;
8. En attente de correction de bogues, test de bogues;
9. Description des pages, contrôles, recherche d'éléments sur la page à l'aide de Web-Driver. Rechercher ce qui a déjà été implémenté dans le système de test;
10. Rédaction de la logique de test;
11. Relâchez
12. Bogue de support / bogue de régression;
13. Mise à jour des spécifications;
14. Correction d'un bug
15. Mise à jour de l'autotest, mise à jour d'un grand nombre de contrôles modifiés;
16. Relâchez
17. ...
    Les éléments en italique (1, 5, 6, 7, 9, 13, 15) entraînent des coûts de temps. Ils peuvent et doivent être optimisés.

Cette liste est brièvement illustrée dans le diagramme du processus de développement:

Notre entreprise est spécialisée dans les projets avec implémentation web d'interfaces. Sur cette base, nous utilisons l'outil Web Driver pour interagir avec le navigateur Web.

De fait, Selenium Web Driver est la norme, et il est utilisé pour décrire les objets Web sur n'importe quel framework, y compris les bibliothèques Gauge, jUnit, Masquerade et autres. Il a beaucoup de flexibilité pour différentes tâches, ce qui crée une pénibilité excessive dans les problèmes de type local. Nous devons trouver une solution pour réduire la complexité.

Pour un exemple, montrons dans le diagramme comment le pilote Web Selenium, le framework Gauge, la bibliothèque Masquerade et le langage de programmation Java sont liés.

Dans ce schéma, au lieu du framework BDD, vous pouvez mettre jUnit, TestNG ou tout autre, n'importe quel bundle fonctionnera, selon les besoins. Selenium et Masquerade resteront, le langage de programmation peut être changé.

Accélérer l'écriture de code - Connexion de mascarade

Notre entreprise se développe sur la plateforme CUBA . Et spécifiquement pour cette plate-forme, un outil d'autotests a été développé: Masquerade est une bibliothèque qui fournit une API concise et pratique pour travailler avec du code lors de l'implémentation de tests à l'aide de WebDriver. Cette bibliothèque fonctionne sur Selenium Web Driver, est amie avec selenide et tous les frameworks.

Dans les projets CUBA, chaque élément de la page Web contient cuba-id, qui ne change pas. CUBA utilise une approche de composants et la bibliothèque Masquerade simplifie l'interaction avec les éléments de page Web. La bibliothèque peut effectuer des actions avec des éléments de page Web implémentés à l'aide de CUBA d'une manière plus simple. Par conséquent, lors de la recherche d'éléments sur la page, vous n'avez pas besoin d'utiliser des constructions volumineuses avec XPath, comme c'était le cas auparavant:

$(new By.ByXPath("//*/div/div[2]/div/div[2]/div/div/div[3]/div/div/div[3).click(); 

Ou des constructions plus concises en Java, qui restent cependant encombrantes:

 private static void click(String cssClass, String caption) { $(By.cssSelector(cssClass) .$(byText(caption)) .closest(".v-button") .click(); } 

Après avoir connecté la bibliothèque Masquerade, la description du contrôle intégré semble simple et facile d'accès. Vous n'avez même pas besoin de rechercher des contrôles sur la page, car il l'a déjà dans le projet. Voici un exemple de description de bouton pour le formulaire d'autorisation dans l'application:

Dans le code de la page, nous voyons un élément clairement reconnaissable cuba-id=”loginButton”

Décrivons le bouton à l'aide de la bibliothèque Masquerade:

 @Wire(path = {"WebHBoxLayout", "loginButton"}) private Button loginButton; 

Une implémentation de test simple sur le framework jUnit est un bloc d'autorisation qui s'exécute avant chaque test:

 @Before public void loginAdm() { Tests loginTest = _$(Tests.class); loginTest.login(); } 

Et dans le corps de la méthode de connexion, le code suivant:

 LoginWindow loginWindow = _$(LoginWindow.class); assertNotNull(loginWindow.getLoginField()); loginWindow.getLoginField() .shouldBe(EDITABLE) .shouldBe(ENABLED); loginWindow.loginField.setValue("admin"); loginWindow.passwordField.setValue("admin"); loginWindow.rememberMeCheckBox.setChecked(true); loginWindow.loginButton().click(); 

La chose la plus importante est la façon dont nous décrivons la page, comment nous nous référons aux éléments. Description de la page LoginWindow:

 public class LoginWindow extends Composite<LoginWindow> { @Wire(path = {"loginField"} ) private TextField loginField; @Wire(path = {"passwordField"} ) private PasswordField passwordField; @Wire(path = {"rememberMeCheckBox"} ) private CheckBox rememberMeCheckBox; @Wire(path = {"loginFormLayout", "loginButton"} ) private Button loginButton; } 

La recherche d'éléments n'est qu'une partie de la bibliothèque Masquerade. L'accès aux éléments d'une page Web vous permet d'effectuer diverses actions avec ces éléments. Par exemple, vous pouvez sélectionner un élément dans la liste déroulante:

 getMaxResultsLayout().openOptionsPopup().select("5000") 

Ou triez le tableau:

 Table tb1 = client.getPaymentsTable(); tb1.sort("column_year", Table.SortDirection.ASCENDING); 

Voir les captures d'écran ci-dessous pour une liste de quelques actions de table:

L'utilisation de Masquerade a grandement simplifié l'écriture des tests, maintenant pour écrire un test pour de nouvelles fonctionnalités, vous avez besoin de:

1. L'utilisation de Masquerade pour décrire une page est facile et ne nécessite pas de compétences de programmation spéciales.
2. Rassemblez en une seule classe toutes les pages utilisées lors de la vérification de la fonctionnalité.
3. À partir des constructions prêtes à l'emploi du langage naturel, collectez un script de test (en y substituant les noms des éléments nécessaires), c'est-à-dire rédigez une spécification de jauge.

Intégration de la mascarade et de la jauge

Avant d'utiliser BDD, l'approche TLD a été utilisée et pour travailler avec elle, nous avons également optimisé le processus d'écriture du code de test. Bundles jUnit / TestNG + WebDriver + Selenide + Masquerade utilisés.

Maintenant, afin de travailler avec Gauge, nous ajoutons le plug-in correspondant à intellij IDEA. Après cela, il sera possible de créer un nouveau type de test - Spécification.

Nous créons maintenant la spécification (script) et implémentons les étapes en utilisant les capacités de WebDriver, Masquerade et Java.

On clique sur l'étape du script et on passe à l'implémentation:

Dans l'implémentation, vous pouvez utiliser la méthode login () existante.

À quoi ressemble cette perfection?

Rappelons l'exemple que nous avons examiné au tout début de l'article:

"Navigation.openMenu(menu)” contient l'implémentation de l'ouverture d'un menu à l'aide de la bibliothèque Masquerade.

La bibliothèque a été par la suite étendue et des étapes universelles sont apparues qui pourraient être utilisées pour n'importe quelle application CUBA. Ce sont les étapes qui vous permettent de travailler avec des éléments de programme: boutons, champs, tableaux. Ces étapes universelles sont devenues l'ensemble des phrases standard que nous utilisons dans BDD pour écrire des scripts.

Grâce à Masquerade + Gauge, nous avons considérablement réduit la complexité de création des tests. Désormais, les tests peuvent être écrits par des personnes n'ayant pas de compétences particulières en programmation. Un test peut être écrit par une personne (avant, un script a été inventé par une personne, mais mis en œuvre par une autre, ce qui a semé la confusion). Nous avons donc atteint notre objectif: les interfaces sont simplifiées et il ne sera pas difficile pour les analystes d'écrire des scripts de test.

Les changements de processus sont indiqués ci-dessous:

C'était:

C'est devenu:

En comparaison, on voit que les exigences, les spécifications et la documentation de test sont combinées dans un paragraphe. La documentation de test est également un autotest, à l'exception de la mise en œuvre d'étapes de test spécifiques.

Résumé

Pour le moment, nous développons avec succès selon le schéma indiqué ci-dessus. Et nous avons réussi à nous débarrasser du problème principal du BDD - une augmentation sérieuse en termes en raison de la complexité de la mise en œuvre, en ajoutant et en finalisant la boîte à outils. Cependant, la qualité de livraison des produits s'est améliorée.

Le temps nécessaire pour maintenir la documentation est réduit proportionnellement au nombre de spécifications modifiées, car un changement de spécification (logique système) entraîne automatiquement un changement d'autotest en une seule itération. C'est-à-dire le testeur n'a pas besoin d'entrer dans le système de documentation (tel que Confluence, etc.) pour une mise à jour, et cela est également vrai pour les autres membres de l'équipe.

Le temps de mise en œuvre et de prise en charge des tests en présence d'une bibliothèque qui simplifie le travail avec les objets de page a été réduit de moitié par rapport au travail avec le pilote Web propre habituel et le coût de refonte des liens XP.

Dans le développement de toute solution d'entreprise et dans la gestion de la qualité - le coût de l'élimination des erreurs dans la collecte des exigences et l'analyse augmente de façon exponentielle . En conséquence, la probabilité de problèmes liés à la modification du produit, selon les articles et les calendriers existants dans le développement itératif, avec la détection précoce d'un problème, qui est une bonne étude des exigences, réduit considérablement le coût de développement, selon le projet. Cela peut être à la fois 0% et ~ 40%. C'est cette amélioration qui est obtenue grâce à l'introduction du BDD. Cela peut être implémenté sans l'appeler le mot BDD, mais il existe dans BDD. Être capable de contourner les problèmes est un élément important de l'assurance qualité.

En conclusion, je voudrais noter que ce schéma de développement est également intégré à l'intégration continue et au système de gestion des tests QA Lens développé dans notre entreprise. Dans QA Lens, vous pouvez écrire les mêmes scripts que dans IDEA en utilisant un langage orienté sujet. Ce langage se compose d'un glossaire précédemment compilé des actions disponibles qui ont été précédemment implémentées. Lorsque vous effectuez un autotest sur Gauge à partir d'une machine de développeur ou d'un CI, QA Lens note automatiquement les étapes de script qui ont été terminées et celles qui ne l'ont pas été. Ainsi, après avoir exécuté un autotest d'un script écrit par un analyste, le service de test reçoit immédiatement des informations complètes et à jour sur l'état du produit.

Auteurs: Sunagatov Ildar et Yushkova Julia ( Yushkova )