Menu

Comment les testeurs sont impliqués dans les techniques TDD, BDD et ATDD

  • Principal
  • Test Agile
  • Comment les testeurs sont impliqués dans les techniques TDD, BDD et ATDD

how testers are involved tdd

Essayez Notre Instrument Pour Éliminer Les Problèmes

Présentation des techniques TDD, BDD et ATDD:

TDD, BDD et ATDD sont les termes qui ont révolutionné le monde des testeurs en Agile et ont également pris de l’ampleur. Changement de mentalité des testeurs exige également l'acquisition de nouvelles compétences et, plus important encore, un changement d'attitude et de façon de travailler.

Contrairement au travail isolé, les testeurs doivent collaborer et travailler avec les programmeurs, ce qui signifie

  • Partager les cas de test
  • Participer à la rédaction des critères d'acceptation des histoires
  • Fournir une rétroaction continue aux parties prenantes
  • Collaborer pour résoudre les défauts à temps.
  • Fournir des suggestions et des commentaires pour améliorer la qualité des livrables
  • Automatisation

Testeurs impliqués dans Agile

Avant de me lancer dans la discussion sur l'implication d'un testeur dans ces pratiques, essayons d'abord de comprendre les concepts qui sous-tendent ces termes:

Ce que vous apprendrez:

Développement piloté par les tests

Considérez l'approche traditionnelle du développement logiciel où le code est écrit en premier, puis testé. Le développement piloté par les tests ou TDD est une approche qui est exactement l'inverse du développement traditionnel. Dans cette approche, les tests sont effectués en premier, puis le code est écrit.

Embrouillé?!!

Comment tester un logiciel qui reste à développer?

Oui!! C'est du développement piloté par les tests ou TDD.

TDD fonctionne par petits incréments où:

  • Le test est écrit en premier
  • Le test est exécuté - ce qui échouera (pour des raisons évidentes)
  • Le code est écrit (ou refactorisé) juste pour faire passer le cas de test
  • Le test est à nouveau exécuté
  • Si le test réussit, passez au test suivant ELSE réécrivez / modifiez le code pour que le test réussisse

Laissez-moi essayer de l'expliquer à travers un organigramme:

Organigramme TDD

Maintenant, nous devons comprendre le fait que TDD ne parle pas des tests que font les testeurs. Cette approche parle plutôt des tests effectués par les programmeurs.

Oui!! Vous l'avez bien deviné !! C’est le test unitaire.

Le test qui est écrit en premier n'est pas le test que les testeurs écrivent, mais c'est le test unitaire que les programmeurs écrivent. Donc, je reformulerais les étapes comme suit:

  • Le test UNIT est écrit en premier
  • Le test UNIT est exécuté - ce qui échouera (pour des raisons évidentes)
  • Le code est écrit (ou refactorisé) juste pour que le test passe
  • Le test UNIT est à nouveau exécuté
  • Si le test réussit, passez au test suivant ELSE réécrivez / modifiez le code pour que le test réussisse

Maintenant, la question qui se pose ici est la suivante: si TDD est le travail d’un programmeur, quel est le rôle du testeur dans cette approche?

Eh bien, après avoir dit que TDD est le travail d'un programmeur, cela ne signifie pas que les testeurs n'y sont pas impliqués. Les testeurs peuvent collaborer en partageant les scénarios de test consistant en:

  • Valeur limite cas
  • Classe d'équivalence cas de test
  • Analyses de rentabilisation critiques
  • Cas des fonctionnalités sujettes aux erreurs
  • Sécurisation des valises de niveau

Ce que je veux dire, c'est que les testeurs devraient participer à la définition des scénarios de test unitaire et collaborer avec les programmeurs pour les implémenter. Les testeurs doivent fournir leurs commentaires sur les résultats des tests.

Si nous voulons implémenter TDD, les testeurs doivent mettre à niveau leurs compétences. Ils doivent être plus techniques et se concentrer sur l'amélioration de leurs compétences analytiques et logiques.

Les testeurs doivent également s'efforcer de comprendre le jargon technique utilisé par les programmeurs et, si possible, avoir une vue d'ensemble du code. De la même manière, les programmeurs doivent se mettre à la place du testeur et essayer de proposer des scénarios plus sophistiqués qui rendront les tests unitaires plus robustes et solides.

Les programmeurs et les testeurs doivent se mettre à la place, contrairement à l'ancienne approche traditionnelle où les programmeurs n'accordaient pas beaucoup de poids aux tests unitaires car ils se reposaient sur les testeurs pour trouver des bogues et des défauts, et les testeurs ne voulaient pas se faire plaisir dans l'apprentissage de la technique parce qu'ils pensent que leur travail se termine après avoir trouvé les défauts.

Développement axé sur le comportement

Behavior Driven Development ou BDD est une extension du Test Driven Development.

BDD, comme son nom l'indique, illustre les méthodes de développement d'une fonctionnalité en fonction de son comportement. Le comportement est essentiellement expliqué en termes d'exemples dans un langage très simple qui peut être compris par tous les membres de l'équipe qui sont responsables du développement.

Certaines des principales caractéristiques de BDD sont les suivantes:

  • Le langage utilisé pour définir le comportement est très simple et dans un format unique dans lequel il peut être compris par tout le monde - les personnes techniques et non techniques impliquées dans la mise en œuvre
  • Donne une plate-forme qui permet aux trois amigos (programmeur, testeur et PO / BA) de collaborer et de comprendre l'exigence. Détermine un modèle commun pour le documenter
  • Cette technique / approche discute du comportement final du système ou comment le système devrait se comporter et ne parle PAS de la façon dont le système devrait être conçu ou mis en œuvre
  • Met l'accent sur les deux aspects de la qualité:
    • Répondre à l'exigence
    • Apte à l'utilisation

Pourquoi BDD?

Eh bien, nous savons que réparer un défaut / punaise au stade ultérieur de tout cycle de développement est assez coûteux. La correction des défauts de production impacte non seulement le code mais aussi la conception et ses exigences. Quand nous faisons le RCA (analyse des causes profondes) de tout défaut, la plupart du temps, nous concluons que le défaut se résume en fait à des exigences mal comprises.

Cela se produit essentiellement parce que chacun a des aptitudes différentes à comprendre les exigences. Par conséquent, les personnes techniques et non techniques peuvent interpréter la même exigence différemment, ce qui peut entraîner une livraison défectueuse. Par conséquent, il est essentiel que tout le monde dans l'équipe de développement comprenne la MÊME exigence et l'interprète de la MÊME manière.

Nous devons nous assurer que tous les efforts de développement sont orientés et axés sur la satisfaction des exigences. Afin d'éviter tout type de défaut «exigence - absence», toute l'équipe de développement doit les aligner pour comprendre l'exigence qui est apte à l'emploi.

L'approche BDD permet à l'équipe de développement de le faire en: -

  • Définition d'une approche standard pour définir l'exigence en anglais simple
  • Fourniture d'exemples de définition expliquant les exigences
  • Fournir une interface / plate-forme qui permet aux techniques (programmeurs / testeurs) et non techniques (PO / BA / Client) de collaborer et de se réunir et d'être sur la même longueur d'onde pour comprendre et mettre en œuvre les exigences

Comment implémenter BDD?

Il existe de nombreux outils disponibles sur le marché pour mettre en œuvre BDD. J'en nomme quelques-uns ici:

  • Concombre
  • Aptitude
  • Concordion
  • JBehave
  • Flux de spécifications

Exemple:

Essayons de comprendre BDD avec un exemple. Pour mon cas, j'utilise Gherkin (concombre):

Prenons un cas simple où nous voulons autoriser uniquement les utilisateurs authentifiés à entrer dans le site XYZ.

Le fichier Gherkin (fichier de fonctionnalités) serait le suivant:

Fonctionnalité: Portail d'inscription aux tests

Aperçu du scénario: Utilisateur valide connecté

Donné: Le client ouvre le portail d'inscription

Lorsque: l'utilisateur entre le nom d'utilisateur comme «» et le mot de passe comme «»

Puis: le client doit pouvoir consulter le formulaire.

Exemples :

| utilisateur | mot de passe |

| utilisateur1 | pwd1 |

| utilisateur2 | pwd2 |

Nous pouvons voir comment une exigence particulière est documentée en utilisant un anglais simple. Les trois amigos peuvent travailler ensemble pour concevoir les fichiers de fonctionnalités et des données de test spécifiques peuvent être documentées dans la section exemple. BDD fournit un moyen de rassembler les programmeurs, les testeurs et les entreprises dans une même table et d'établir une compréhension commune des fonctionnalités à implémenter.

L'approche BDD permet d'économiser des efforts et des coûts et vérifie s'il y a des défauts après le déploiement en production, car la collaboration des clients et des développeurs s'est déroulée tout au long du cycle de développement de la fonctionnalité.

Les équipes de développement peuvent utiliser ces fichiers de fonctionnalités et les convertir en programmes exécutables pour tester une fonctionnalité particulière.

Comment?

Eh bien, vous devez apprendre Cucumber / Fitnesse pour cela !!

Développement piloté par les tests d'acceptation

Le développement piloté par les tests d'acceptation ou ATDD est une technique dans laquelle toute l'équipe collabore pour définir les critères d'acceptation d'une épopée / histoire avant que la mise en œuvre ne commence réellement. Ces tests d'acceptation sont étayés par des exemples appropriés et d'autres informations nécessaires.

La plupart du temps, BDD et ATDD sont utilisés de manière interchangeable. L'approche ATDD peut également être implémentée en utilisant le format donné-quand-alors, tout comme nous écrivons des fonctionnalités dans l'approche BDD.

Essayons rapidement de résumer les différences entre les 3 approches:

  • TDD est plus technique et est écrit dans le même langage dans lequel la fonctionnalité est implémentée. Si la fonctionnalité est implémentée en Java, nous écrivons JUnit cas de test . Alors que BDD & ATDD est écrit en anglais simple
  • L'approche TDD se concentre sur l'implémentation d'une fonctionnalité. Alors que BDD se concentre sur le comportement de la fonctionnalité et ATDD se concentre sur la capture des exigences
  • Pour mettre en œuvre le TDD, nous devons avoir des connaissances techniques. Alors que BDD et ATDD ne nécessitent aucune connaissance technique. La beauté de BDD / ATDD réside dans ce fait que les techniciens, ainsi que les non-techniques, peuvent participer au développement de la fonctionnalité
  • Étant donné que le TDD est évolué, il permet une bonne conception et se concentre sur l'aspect «Satisfaire aux exigences» de la qualité; alors que BDD / ATDD se concentre sur le 2ndaspect de la qualité qui est «adapté à l'usage»

Toutes ces techniques parlent essentiellement de l'approche «test-First», contrairement à l'approche «test-last» utilisée dans les méthodologies de développement traditionnelles.

Comme les tests sont écrits en premier, les testeurs jouent un rôle très important. Les testeurs doivent non seulement avoir un vaste domaine et des connaissances commerciales, mais ils doivent également posséder de bonnes compétences techniques afin de pouvoir ajouter de la valeur au brainstorming lors des discussions des 3 amigos.

Avec des concepts tels que CI (Continuous Integration) et CD (Continuous Delivery), les testeurs doivent bien collaborer avec les programmeurs et contribuer de manière égale au domaine du développement et des opérations.

comment ouvrir un fichier .dat dans windows

Permettez-moi de résumer cette discussion avec la célèbre pyramide de test en Agile:

Tester la pyramide en Agile

La couche la plus basse de cette pyramide est constituée de la couche de test unitaire. Cette couche est la couche de base; il est donc impératif que cette couche soit solide comme le roc. La plupart des tests doivent être poussés dans cette couche. Cette couche inférieure se concentre uniquement sur TDD.

Dans le Agile monde, l'accent est mis sur le fait de rendre cette couche de la pyramide plus solide et plus robuste et il est souligné que la plupart des tests sont réalisés à cette couche.

Les outils utilisés dans cette couche d'une pyramide sont tous les outils Xunit.

La couche intermédiaire de la pyramide est la couche de service, expliquant les tests de niveau de service. Cette couche sert de pont entre l'interface utilisateur de l'application et l'unité / le composant de niveau inférieur. Cette couche comprend principalement des API qui acceptent les demandes de l'interface utilisateur et renvoie la réponse. L'approche BDD et TTDD est active dans cette couche de la pyramide.

Les outils utilisés dans la couche intermédiaire de la pyramide sont: Fitnesse, Cucumber et Robot Framework .

La couche la plus élevée de la pyramide est l'interface utilisateur réelle, ce qui montre que cette couche devrait contenir le moins de tests, ou je devrais dire que l'effort de test à cette couche particulière devrait être minime. La plupart des tests de la fonctionnalité auraient dû être terminés lorsque nous atteignons la couche supérieure de la pyramide.

Les outils utilisés dans la couche supérieure sont - Sélénium , QTP et RFT.

Puisque nous travaillons par petits incréments Scrum (appelé Sprints), la mise en œuvre manuelle de toutes ces approches n'est pas possible. Ces approches nécessitent une intervention automatisée. L'automatisation, dans ce cas, est très critique.

En fait, ces approches sont en fait exécutées par automatisation. À la fin de chaque sprint, de nouvelles fonctionnalités sont ajoutées, il devient donc important que la fonctionnalité précédemment implémentée fonctionne comme prévu; Par conséquent, Automatisation devient le HERO ici.

Conclusion

À la fin de l'article, vous devez avoir appris comment les testeurs sont impliqués dans les techniques TDD, BDD et ATDD.

Dans la troisième partie de la série, je concentrerai ma discussion sur l'automatisation dans un monde Agile.

A propos de l'auteur: Cet article est de l'auteur de STH Shilpa. Elle travaille dans le domaine des tests de logiciels depuis plus de 10 ans dans des domaines tels que la publicité sur Internet, la banque d'investissement et les télécommunications.

Continuez à surveiller cet espace pour bien plus de mises à jour.

lecture recommandée

^