Dans un article précédent, nous avions répertorié 5 fonctionnalités requises pour une automatisation des tests boîte noire.
Ils s’agissait des suivantes :

  • décrire le comportement de vos tests
  • stocker vos données de test (entrée, sortie attendue et résultats d’exécution de test)
  • exécuter vos tests sur du matériel / logiciel spécifique
    contrôler et surveiller l’exécution du test
  • analyser les résultats des tests et surveiller des tendances en matière de qualité

Dans cet article, nous allons partager quelques réflexions sur la première fonctionnalité : comment décrire le comportement de vos tests.

show screen

Les tests logiciel en boite noire peuvent être illustrés de cette façon : le logiciel sous test (SUT) est une boite opaque avec un ensemble de points d’entrée (une interface utilisateur, une interface en ligne de commande, une API, etc.) que le testeur utilise pour produire un ensemble de sorties permettant de vérifier le comportement du logiciel. Automatiser ces tests signifie écrire un logiciel supplémentaire qui utilisera ces points d’entrée pour vérifier automatiquement ces comportements. Ainsi, comme pour tout autre logiciel, il existe toute une gamme de possibilités pour l’écrire avec différents niveaux de compétences en programmation. Ces possibilités peuvent être regroupées en 3 types principaux : langage complet, langage spécifique à un domaine (Domain Specific Langage, DSL) et solution de test packagée.

Langage Complet

L’option du langage complet signifie que vous utilisez un langage de programmation générique pour écrire vos tests. Contrairement aux tests unitaires qui doivent être écrits dans la même langue que le SUT, les tests de type boîte noire peuvent être écrits dans n’importe quelle langage car le couplage entre le SUT et le test est faible (vous n’appellerez pas les fonctions ou méthodes du SUT mais plutôt des points d’entrée). Néanmoins, de nombreuses personnes soutiennent qu’un seul langage devrait être utilisé. Cela peut fonctionner dans certaines organisations, mais cela ne sera ni pertinent ni possible dans de nombreux contextes. Par exemple, le SUT lui-même pourrait être écrit en plusieurs langage (backend Java et le front-end Javascript est un cas courant), mais lequel choisir pour les tests boîte noire ? Un autre exemple serait lorsque le produit est écrit dans un langage de bas niveau, tel que C, ou dans un langage fonctionnel, tel que OCaml. Serait-il vraiment pertinent d’écrire des tests boîte noire en OCaml ? Enfin, s’il existe une équipe d’automatisation distincte, l’automatisation peut être utilisée pour plusieurs produits écrits dans différentes langages. Dans ce cas, choisir un seul langage (potentiellement différent de ceux des produits) peut être judicieux. Les bibliothèques de test pourront ensuite être partagées plus largement, ce qui permettra aux testeurs de passer facilement d’un projet à l’autre.

Quelle que soit le langage choisie, cette option « langage complet » nécessitera des ingénieurs de test possédant des compétences en programmation. Cela peut être difficile dans certaines organisations où les testeurs sont plus des experts métier (finance, santé, communication, etc.) que des développeurs. L’avantage de ce choix est qu’il permet à votre équipe de bénéficier de tous les avantages d’un langage à part entière (excellent IDE, analyse de code statique et réponses StackOverflow !). Un autre avantage est que les ingénieurs en logiciel pourraient être plus disposés à participer à la rédaction de tests automatisés si elle est effectuée de la même manière que le SUT lui-même.

Notez qu’aujourd’hui, Python est en train de devenir l’un des langages de programmation les plus populaires, en particulier parmi les testeurs. Sa simplicité permet aux experts métier de s’essayer à la programmation, mais cela peut encore être compliqué comme vous pouvez le constater dans cet exemple :

from selenium import webdriver
from selenium.webdriver.common.keys import Keys

driver = webdriver.Firefox()
driver.get("http://www.python.org")
assert "Python" in driver.title
elem = driver.find_element_by_name("q")
elem.clear()
elem.send_keys("pycon")
elem.send_keys(Keys.RETURN)
assert "No results found." not in driver.page_source
driver.close()

Donc, pour ceux qui ne sont pas à l’aise avec ce genre de code, un Domain Specific Langage pourrait être la bonne option, comme nous allons l’expliquer.

Utilisation d’un DSL

La deuxième possibilité pour automatiser vos tests consiste à utiliser un langage DSL (Domain Specific Language). Ici, le domaine est le test. L’idée est que vous n’avez pas besoin d’un langage complet pour écrire vos tests, mais d’une sous-partie qui se concentre sur les besoins des tests. L’exemple le plus célèbre de ce type de DSL est Gherkin écrit pour Cucumber. Ce langage est composé de 5 mots seulement: Scenario, Given, When, Then et And. Ces instructions permettent de créer des tests de style BDD ressemblant à ceci:

Scenario: User clicks the About link
Given I am on the homepage
When I click the link to About page
Then I should see the About page

Le langage utilisé par Robot Framework est un autre DSL répandu pour les tests. Ce framework propose un ensemble plus large de mots-clés et comprend un grand nombre de bibliothèques pour toutes sortes de tâches (opérations sur les fichiers, manipulation de la date/heure, etc.). Cependant, il permet également d’écrire des tests simples du style BDD à la Cucumber:

*** Test Cases ***
Addition
    Given calculator has been cleared
    When user types "1 + 1"
    and user pushes equals
    Then result is "2"

Le code utilisé pour Cucumber et Robot Framework est beaucoup plus simple, non ? Mais bien sûr, il n’y a rien de magique. À un moment donné, quelqu’un devra programmer des mots clés tels que « I should see the About page » ou « user pushes equals ». Cette tâche sera effectuée en Python, Java, Ruby, etc. Cela nous ramène à la case départ et à la nécessité d’utiliser un langage complet. L’avantage de tels outils est que leur DSL offre une couche qui peut être utilisée par des personnes non techniques (par exemple des QA métiers, des business analyst etc.). C’est un facteur clé de succès pour de nombreuses organisations où certains membres de l’équipe sont responsables des librairies d’automatisation (qu’ils codent en Python par exemple), tandis que d’autres utilisent uniquement le DSL afin de ne pas avoir à apprendre un vrai langage de programmation. . Par conséquent, ces frameworks peuvent agir en tant que facilitateurs d’automatisation. Après un certain temps, au fur et à mesure que les testeurs ressentent le besoin d’écrire des tests plus complexes (et prennent confiance en leurs compétences en programmation !), ils risquent d’atteindre la limite de ces DSL. Dans ce cas, il n’est pas rare de revenir à un langage complet et de supprimer ces frameworks.

Solution Propriétaire

La troisième possibilité consiste à utiliser une solution fournie par des éditeurs de logiciels de test. Le type historiquement le plus connu est « record and playback » pour des tests basés sur une interface graphique. Avec une telle solution, le testeur peut cliquer sur le bouton « enregistrer », parcourir le logiciel en cours de test via l’interface utilisateur suivant le cas d’utilisation, et le scénario est enregistré pour être rejoué plus tard. Ceci est aussi fragile que cela en a l’air, et subit des critiques d’une partie de la communauté depuis longtemps. La seule possibilité pour rendre un tel test robuste est de revoir le code généré afin de le rendre moins sensible aux changements d’interface. Quoi qu’il en soit, comme nous en avons discuté dans un article précédent, l’interface graphique n’est généralement pas le bon point d’entrée pour automatiser les tests de type boîte noire.

Il existe d’autres solutions de test qui ne ciblent pas la couche d’interface graphique. Par exemple, la solution pourrait fournir un accès à l’interface de ligne de commande ou à l’API REST de votre SUT. Cela pourrait vous permettre de créer un test automatisé robuste sans avoir à utiliser un langage de programmation complet. Vous devez trouver une solution de test capable d’interagir avec les interfaces offertes par votre SUT.

Quelle solution choisir ?

Pour décider quelle solution utiliser pour décrire vos tests, le principal facteur à considérer est certainement le profil et les compétences de votre équipe. S’il n’y a pas d’ingénieurs de test dans votre équipe et que les ingénieurs logiciels sont chargés d’automatiser les tests en boîte noire, vous souhaiterez probablement opter pour la solution en langage complet. De cette façon, les développeurs peuvent gérer la totalité de la « pile de tests » (du test unitaire au test final) à partir de leur IDE et utiliser le langage de programmation de leur choix. Si votre équipe compte des ingénieurs de test possédant de solides connaissances métier mais peu de compétences techniques, vous pouvez choisir une solution intégrée permettant aux testeurs d’écrire des tests automatisés avec le moins de programmation possible. Le dernier cas concerne de grandes entreprises où il existe à la fois des ingénieurs de test métier et des ingénieurs de développement de tests disposant de connaissances techniques plus poussées. Dans de tels contextes, les profils techniques sont en charge de la construction de l’infrastructure d’automatisation et une approche DSL pourrait avoir un sens. Le profil technique écrit le code derrière les mots-clés du DSL et les profils métier utilise le DSL pour écrire des tests orientés business.

N’oubliez pas que la description des tests ne représente qu’une partie de la solution, car vous devez également avoir quatre autres fonctionnalités (stockage, exécution, surveillance, analyse). Ces autres fonctionnalités peuvent avoir un impact sur le langage ou outil que vous choisissez. Par exemple, si vous devez utiliser certaines API pour vous connecter à des services où stocker vos données de test (données d’entrée et de référence), vous pouvez choisir un langage pour lequel cette API est disponible ou un outil capable de s’intégrer à cette dernière. Nous discuterons de ces autres fonctionnalités avec plus de détails dans un prochain article.

Share