Les tests unitaires consistent à tester les plus petites parties testables du code de l'application (appelées unités), comme les modules, les fonctions ou les fragments de code. Les tests unitaires sont souvent effectués dans le cadre d'un processus automatisé, car des tests unitaires fréquents permettent d'identifier rapidement les problèmes ou les conflits de code.
Les tests d'acceptation vérifient l'acceptation des résultats par rapport aux critères d'acceptation de l'histoire de l'utilisateur (exigences commerciales).
Ces tests peuvent servir à vérifier le résultat d'une exigence spécifique, d'une spécification ou d'exigences contractuelles.
Les tests exploratoires s'ajoutent aux tests "scriptés" (par exemple, les tests unitaires). Dans les tests exploratoires, le testeur explore le système à la volée pour trouver des problèmes et des comportements inattendus dans le système.
Les tests d'utilisabilité sont une technique permettant d'évaluer l'interaction de l'utilisateur avec le système dans des conditions réalistes ou dans un cadre contrôlé. L'objectif des tests d'utilisabilité est de déterminer dans quelle mesure les utilisateurs réagissent au système ? Dans quelle mesure le système est-il facile à utiliser ? Quelles améliorations sont nécessaires en termes de convivialité ?
L'intégration continue (IC) consiste à automatiser l'intégration de codes nouveaux ou modifiés dans le référentiel de code. L'intégration continue permet d'identifier les conflits ou les codes incompatibles le plus tôt possible et de les corriger dès qu'ils se produisent. Les dépôts de code permettent aux développeurs de revenir à des versions antérieures du code.
L'intégration continue implique :
Code source système de contrôle - contrôle de version
Outils de construction - des outils de construction pour compiler le code
Outils de test - des tests unitaires pour s'assurer que les fonctionnalités fonctionnent comme prévu
Planificateurs ou déclencheurs - lance les constructions selon un calendrier ou en fonction des conditions.
Notifications - des courriels ou des messages instantanés signalant les résultats de la construction
Dans le développement piloté par les tests, les tests sont écrits avant que le code ne soit développé.
Le développeur passe par les étapes Rouge-Vert-Refactor (propre) jusqu'à ce que le code soit finalisé :
Rouge - Les tests écrits échouent initialement car le code n'est pas écrit ou est incomplet.
Vert - Le code a été écrit et a passé les tests.
Refactor - Le développeur travaille au nettoyage et à la refactorisation du code de travail.
Dans le cadre du développement piloté par les tests d'acceptation (ATDD), les tests sont axés sur les exigences métier et le comportement souhaité du système. Les tests sont écrits sur la base des critères d'acceptation des histoires d'utilisateurs que l'équipe de développement transforme en tests d'acceptation qui peuvent être stockés dans les outils de test. Les tests échouent au départ parce qu'ils sont écrits avant que les fonctionnalités souhaitées du logiciel soient développées et fonctionnent.
Behavior-Driven Development (BDD) est une technique de test agile qui vise à valider les scénarios et les comportements du système. Elle suit le langage Gherkin qui utilise le format "Donné, Quand, Alors"Mots clés pour décrire le comportement souhaité du système, c'est-à-dire ce qui doit se passer dans l'application.
La programmation en binôme est une pratique essentielle du cadre XP qui permet aux membres de l'équipe d'apprendre les uns des autres, d'accroître leur productivité et de trouver des bogues en écrivant, dirigeant et révisant le code par paires. Le conducteur écrit le code tandis qu'une autre personne, le navigateur (alias l'observateur), révise chaque ligne de code saisie. Les paires (deux membres) changent fréquemment de rôle (c'est-à-dire conducteur et navigateur). Le navigateur examine les principaux problèmes et erreurs, prend des notes et partage ses idées sur les prochaines étapes ou les obstacles possibles.
La programmation en binôme est plus efficace lorsque les membres de l'équipe se trouvent au même endroit.
Les praticiens des tests Agile et du contrôle de la qualité ont un niveau fondamental de compréhension de l'intégration des pratiques de marketing dans SMART Agile.
Les généralistes certifiés SMART Agile ont une connaissance et une compréhension du rôle de membre de l'équipe de développement dans Agile.
