Test axé sur le comportement (BDT) est un terme rare dans les tests de logiciels par rapport au développement piloté par le comportement (BDD). Les tests dans les tests pilotés par le comportement sont le plus souvent axés sur le comportement des utilisateurs plutôt que sur les fonctions techniques du logiciel. BDT est le meilleur choix lorsque vous voulez montrer votre point de vue commercial et les exigences du produit. Pour étaler les idées de produits, BDT utilise un langage très facile à comprendre pour s’assurer que tout le monde dans l’équipe ne manque de rien, même s’il s’agit de gars non techniques. Par conséquent, les personnes responsables de l’analyse commerciale et de la gestion des produits pourraient participer activement au processus de test. Les tests axés sur le comportement prennent de l’ampleur, car de nombreuses organisations les considèrent comme une solution à leurs défis d’automatisation et de collaboration. Le cadre BDT a été mis en œuvre avec succès par diverses équipes d’assurance qualité dans divers domaines. En outre, c’est la prémisse pour mettre en œuvre les tests basés sur les données beaucoup plus efficacement et plus facilement.
Les origines des tests axés sur le comportement :
Depuis le début de l’automatisation des tests temporels, elle a énormément évolué avec de nouveaux concepts, la conception de cadres et les outils. La faible facilité d’utilisation, la rigidité et les coûts de maintenance élevés ont été la raison de l’évolution des cadres d’automatisation.Évolution des frameworks de test :
frameworks de base > l’enregistrement et la lecture > les tests axés sur les > les mots clés pilotés par mots-clés > les tests axés sur les > hybrides et les comportements.
L’un des inconvénients courants lors de l’utilisation de ces cadres est qu’il est difficile pour les personnes non techniques comme les analystes d’affaires, les gestionnaires de lire et de comprendre les cas de test. Mais les tests axés sur le comportement peuvent le gérer. Il a aidé à combler le manque de communication en écrivant les cas de test en langage naturel. Il s’agit d’une approche de développement logiciel agile relativement nouvelle qui se concentre sur la communication ; encourager la collaboration entre les développeurs, l’assurance qualité et les participants commerciaux ; pour aider à combler l’écart d’alignement entre l’entreprise et l’informatique. Les scénarios sont écrits pour construire une compréhension claire du comportement souhaité et cela se produit par le biais de discussions avec les parties prenantes.
Avantage d’utiliser les tests axés sur le comportement.
- Collaboration : Il établit des relations plus étroites entre les analystes d’affaires, l’assurance qualité et le développement grâce aux examens de clarification du comportement. C’est également utile pour communiquer efficacement les exigences. Vérifié par les BA et les testeurs pour s’assurer des critères d’acceptation.
- Révision et feedback faciles : En écrivant les cas de test dans un langage naturel lisible par l’homme, aucune compétence de développement ne sera requise. Les analystes d’affaires peuvent participer activement au processus de création des cas de test automatisés, les examiner et donner leur avis pour les améliorer.
- La bonne orientation : Le BDT aide à se concentrer sur les exigences et le point de vue commercial plutôt que de trop se concentrer sur les tests de la mise en œuvre technique.
- Plus grand retour sur investissement: Il a été observé que le comportement du logiciel reste plus longtemps que la mise en œuvre. Ainsi, les tests axés sur le comportement sont plus faciles à modifier et entraînent donc un meilleur retour sur investissement. En outre, les outils BDT sont open source, ce qui réduit encore l’investissement.
- Ce n’est plus coûteux à maintenir : Avec BDT, la redondance du code peut être minimisée grâce à la fonction de réutilisation par étapes. Par conséquent, ces tests sont moins coûteux à entretenir.
- Compatible avec l’automatisation : Les tests BDT peuvent être intégrés dans le pipeline CI/CD et exécutés automatiquement selon un calendrier prédéfini. Cela permet l’agilité et permet aux développeurs de se concentrer sur le développement futur.
BDT VS BDD
Les tests axés sur le comportement sont souvent utilisés de manière interchangeable avec le développement axé sur le comportement. Cependant, ce n’est pas la même chose. Le développement axé sur le comportement est l’approche de développement logiciel qui vise à développer des logiciels uniquement en fonction du comportement de l’utilisateur. Cela permet d’éviter un code excessif et des fonctionnalités inutiles. Comme BDT, BDD est également basé sur des conversations avec les parties prenantes de l’entreprise et comprend des scénarios d’utilisateurs réels. Toutefois, contrairement au BDT, l’objectif de ces discussions est le développement et non les essais.
Quand utiliser les tests axés sur le comportement :
Le BDT peut-être implémenté avec différents types de tests :
- BDT avec tests d’intégration : Les tests d’intégration sont les tests de différents modules logiciels en tant que groupe, afin de s’assurer que tous les modules peuvent fonctionner ensemble. BDT permet de créer des scénarios clairs et précis pour ces intégrations, basés sur le comportement des utilisateurs et dans leur langue. Compte tenu de l’intégration entre les composants, lorsqu’un utilisateur effectue une certaine action, les composants intégrés effectuent X. L’intégration du BDT dans les tests d’intégration offre la flexibilité et la liberté de tester des scénarios intermodales pour examiner le système de bout en bout.
- BDT avec test API : Dans le cadre des tests d’intégration, les tests d’API examinent la fonctionnalité et la fiabilité des API dans la couche métier de l’architecture. Cela fait de BDT un très bon choix pour les tests d’API. Les scénarios BDT permettent de mapper clairement chaque étape dans un appel d’API en cours de test. Il est très facile de corréler chaque appel d’API en une étape donnée et de l’écrire avec des mots clairs.
- BDT pour les tests d’interface utilisateur : Bien que certaines entreprises utilisent le BDT pour les tests d’interface utilisateur, il ne s’agit pas d’une meilleure pratique recommandée. La couche d’interface utilisateur comporte plusieurs scénarios complexes. Chaque action pourrait avoir des milliers de résultats. Même les actions qui semblent similaires pourraient avoir un résultat unique de l’interface utilisateur, ce qui nécessiterait un ensemble de tests complètement différent. Par conséquent, l’écriture de tests d’interface utilisateur dans la structure donnée quand alors, puis dans le code est compliqué et prend beaucoup de temps. En outre, de tels tests pourraient également être très fragiles, car l’interface utilisateur change constamment. Après tout, BDT a été créé pour tester le comportement, pas la visibilité.
Comment les tests comportementaux ont-ils été mis en œuvre?
Il existe une pléthore de frameworks BDT open source disponibles dans de nombreux langages de programmation et prenant en charge différentes plates-formes. Par exemple, Cucumber de préférence avec Ruby, JBehave pour Java, NBehave et specflow pour.Net, Behat pour PHP et Twist pour Groovy, etc.
Vous trouverez ci-dessous les grandes lignes du processus de test piloté par le comportement :
- Business Analyst rédige une User story formelle.
- Le testeur écrit les scénarios en fonction du récit utilisateur.
- Les scénarios sont examinés par l’équipe commerciale.
- L’ingénieur en automatisation écrit les définitions d’étape pour les étapes du scénario.
- Les scénarios sont automatisés par l’équipe d’assurance qualité.
- Exécutez les scénarios automatisés et corrigez si des bogues existent.
- Les tests automatisés s’exécutent en tant que tests de régression. L’utilisateur accepte le logiciel (critères d’acceptation et de qualité remplis)
