KDT: Keyword Driven Testing

On parle toujours de tests manuels et de tests automatisés mais rarement de Keyword Driven Testing (KDT). A quoi cela correspond exactement le KDT ?

Repartons de la base.

Les tests manuels

Un test manuel bien écrit est une suite d’actions entraînant chacune un résultat à vérifier

Prenons un exemple : lire un mail sur une application android :

Ici si un résultat n’est pas validé ou une action impossible alors le cas est en échec. Sinon il est en succès.

Les tests automatisés

A partir d’un cas de test manuel bien écrit on peut développer un cas de test automatisé. Pour une application Android il est possible d’utiliser Appium avec Sélénium.

Si on reprend l’exemple précédent alors il suffit de coder chaque partie du test. On commence par l’ouverture de l’application en appuyant sur l’icône, puis on vérifie que la boite de réception est bien affichée (par exemple en cherchant la présence dans la partie haute de l’écran du texte « Boite de réception »)

On fait ensuite de même avec les autres étapes, tout est écrit en java si on utilise Sélénium.

Nous arrivons donc au KDT

Le KDT est utilisé pour l’automatisation des tests. Par contre, contrairement à l’utilisation « classique » ce type de test ne se présente pas de la même façon qu’un test automatisé classique.

L’idée avec le KDT est de faire un point entre le test manuel et le test automatisé afin que des personnes plus fonctionnelles que techniques puissent automatiser des tests ou même que des personnes ne comprenant rien aux langages de programmation puissent le lire et comprendre ce que le test fait. En fait, on peut voir le KDT comme un « middle ware ».

J’ai personnellement travaillé sur des KDT, les tests étaient écrits sur Excel, chaque ligne faisant une action (et donc appelant une fonction sélenium), et comme pour les tests manuels si une étape était en échec alors le cas était en échec. Comme pour un test automatisé si la ligne est validée alors on passe à la suivante, sinon le test s’arrête et est en échec (à moins que l’on donne des conditions précises en fonction du succès ou de l’échec de l’étape).

Le KDT peut prendre plusieurs formes mais voici ce que le test de mon exemple pourrait donner en KDT :

Ici, chaque action (click, Idtext_exists et Id_exists) appelle une fonction préalablement développée et demandant certaines variables. Click et Id_exists n’ont besoin que d’un ID alors que la fonction Idtext_exists a besoin d’une valeur afin de vérifier une présence.

La colonne commentaire permet de savoir ce qui est fait même pour une personne non technique. Le test ressemble également (en apparence) à un test manuel ce qui le rend plus lisible.

Le KDT peut évidemment être plus complexe (et présenté différemment), en ajoutant par exemple ce qui est fait lorsque l’étape est en échec et lorsqu’elle ne l’est pas (afin de gérer des changements d’option et avoir un test plus stable par exemple).

Conclusion

Le KDT est un excellent moyen de se familiariser avec l’automatisation des tests, particulièrement si la personne devant automatiser n’est pas très technique (ce qui est souvent le cas pour des testeurs logiciel). De plus le KDT a également l’avantage de simplifier la lecture des tests pour une personne en dehors ou rejoignant l’équipe. Par contre il ajoute une couche supplémentaire entre l’application et l’outil d’automatisation ce qui peut nuire aux performances.

Un autre avantage du KDT (et non le moindre) est le fait que si l’on change d’outil d’automatisation alors les tests ne sont pas à jeter, il suffit de recoder les fonctions utilisées sur l’ancien outil.

Outil utilisant le KDT : Robot Framework

Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !

N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles