Tests agile dans le développement de logiciels
La voie vers plus de qualité et d'efficacité
Avec la mise en place de méthodes agiles, les besoins des utilisateurs sont au cœur du développement logiciel. Les futurs utilisateurs sont davantage impliqués dans le processus de développement .et garantissent par leurs contributions, à ce que les thèmes importants soient effectivement mis en œuvre et à ce que l’application soit facile à utiliser et efficace. Pour le vérifier, un logiciel fonctionnel et sans erreur doit être livré souvent et continuellement. Les exigences élevées posées à la partie non fonctionnelle du logiciel doivent également être testées en permanence : le code est-il clair, l’application est-elle conforme aux exigences de sécurité, est-elle stable et facile à maintenir? En une phrase : une livraison de code constante, fréquente et sans erreur est une question de qualité.
Qu’est-ce qui distinguent les tests agiles des tests classiques ?
Dans la gestion classique des tests, le développement et les tests sont clairement séparés et les quatre étapes de test se déroulent l’une après l’autre . La phase de test débute à l’achèvement du produit. Les différents composants sont d’abord testés (test des composants).l’étape suivante, le test d’intégration, permet de vérifier l’interaction entre les différents composants.Pour finalement tester sous tous les angles les fonctions du produit entier, d’abord en interne (système d’essai) . et enfin. le client (test d’acceptation par l’utilisateur.
Les rôles sont clairement répartis. L’équipe de développement développe, l’équipe de test teste et la gestion des tests contrôle et gère. Pour une livraison continue (à chaque itération). des logiciels stables et exempts d’erreurs dans un environnement agile, des tests permanents sont nécessaires. Il n’est pas possible à long terme de passer d’une étape de test à une autre à l’aide de méthodes de test conventionnelles, car les itérations sont courtes et rapides. En test agile, il y a aussi des tests de composant, d’intégration et de système, à la différence qu’ils ne s’exécutent pas l’un après l’autre. mais parallèlement à une itération, et sont même parfois intégrés au développement.
L’approche agile ne connaît pas non plus de rôles clairement répartis. Idéalement, les développeurs de logiciels et les architectes ainsi que les testeurs. Les responsables des tests et de la qualité font partie de l’équipe de développement et se soutiennent les uns les autres. L’équipe a un objectif commun : une qualité élevée avec une couverture de test élevée, une exécution et une documentation efficaces. Pour ce faire, il faut trouver le juste équilibre entre un haut niveau d’automatisation et peu de tests manuels.
Répartition efficace des tests : la pyramide des tests
Un coup d’œil sur la pyramide de test de Mike Cohen montre comment concevoir une stratégie de test efficace. Comment planifier la répartition des tests sur les différents niveaux de test et quels domaines se prêtent le mieux à l’automatisation des tests. La large base de la pyramide est constituée par un nombre élevé de tests de composants sous forme de tests unitaires automatisés. Ceux-ci sont relativement faciles à créer en parallèle avec le développement de l’application, rapides à réaliser, peu coûteux et garantissent une couverture de test élevée.
Ils décèlent la plupart des erreurs au stade du développement. Les tests d’intégration (tests API) constituent le niveau intermédiaire de la pyramide de test. API signifie Application Programming Interfaces. Les tests API automatisés garantissent que les composants fonctionnent ensemble comme prévu. Les tests API sont très bien adaptés à l’automatisation des tests, car ils sont généralement soumis à peu de modifications et sont faciles à entretenir. Il convient de noter que les tests non fonctionnels, tels que les tests de charge et de performance, ne sont pas pris en compte dans la pyramide de test par contre ils sont importants pour l’acceptation par l’utilisateur et qu’ils peuvent en partie être très bien automatisés.
Les tests système (tests GUI) se trouvent au sommet de la pyramide. On appelle GUI (Graphical User Interface) l’interface utilisateur graphique. Les tests GUI automatisés vérifient si toutes les fonctions se déroulent comme prévu. Leur automatisation est facilement réalisable grâce à une sélection d’outils, mais le choix des tests à automatiser doit être étudié avec soin, car ils sont plus complexes à créer et à entretenir par conséquent plus coûteux. En règle générale, les tests de l’interface graphique nécessitent des d’importantes retouches pour pouvoir suivre les changements fréquents.
Il est recommandé d’automatiser autant de tests que nécessaire et aussi peu que possible et de les introduire progressivement, par exemple en sécurisant les fonctions existantes au moyen de tests de régression automatisés sprint après sprint. Les tests exploratoires et les tests de bout en bout ne se prêtent guère à l’automatisation des tests en raison de leur complexité et pour les tests exploratoires en raison de leur degré de liberté. Le testeur exploratoire explore l’application sans avoir déterminé au préalable quelles étapes de test doivent être exécutées. L’avantage est qu’il y a moins de préparation, que la documentation est réduite au minimum et que les erreurs sont trouvées en dehors des scénarios de test existants.
Sources: Livre: Agile Testing: Manfred Baumgartner, Martin Klonk, Helmut Pichler, Richard Seidl, Siegfried Tanczos (2018): Der agile Weg zur Qualität
