mercredi 26 octobre 2016

FunKTest : LA solution pour les tests fonctionnels web

A l'issue de deux missions consacrées aux tests fonctionnels web, dans des grandes entreprises françaises, j'ai réalisé que la réponse à leurs besoins pouvait être factorisée dans un applicatif simple. FunKTest est un générateur de codes de test Protractor gratuit, utilisable par un utilisateur métier, non informaticien. FunKTest vous permettra de réduire drastiquement les coûts et les délais de vos tests car il génère des codes structurés, optimisés, performants, jouables sur toutes les plate-formes. Il vous évite l'enfer des tests par recording.

Un dessin valant mieux que mille mots, voici deux vidéos qui vous montreront la simplicité d'utilisation et l'efficacité de funKTest :
  • Protractor jouant les codes produits par funKTest
  • Exemple d'utilisation de funKTest

Pour ceux qui veulent en savoir plus sur le problèmes des tests fonctionnels web, je leur propose de présenter ici les réflexions et expériences qui m'ont amené à développer funKTest.

Tests fonctionnels : une affaire d'utilisateur métier

En matière de tests logiciels on prend souvent l'image de la maison en construction. Il y a d'abord les tests unitaires : on vérifie que l'interrupteur électrique à poser est bien en état de fonctionnement. Ensuite il y a les tests d'intégration : on vérifie que l'interrupteur se connecte bien au réseau électrique global. Il y a enfin les tests fonctionnels : on vérifie que l'utilisateur de la maison trouve bien l'interrupteur et parvient à l'actionner. Si les tests unitaires et d'intégration sont une affaire d'électricien, les tests fonctionnels sont l'affaire de l'utilisateur qui ne connaît rien à l'électricité.

Il en va de même pour le développement d'un applicatif. Les tests unitaires des fonctions et méthodes doivent être menés par le développeur. Ce dernier doit aussi vérifier que les éléments nouveaux qu'il apporte s'insèrent bien dans le schéma global de l'applicatif en construction, il doit donc mener des tests d'intégration. En revanche, le développeur ne doit pas mener les tests fonctionnels, dont seul l'utilisateur peut se charger.

A cela plusieurs raisons :

  • la première est qu'on ne peut être juge et partie.
  • la seconde est que le développeur, s'il est expert en informatique, n'est jamais spécialiste du domaine métier de l'application (aéronautique, agro-alimentaire, finance, quincaillerie, ...), sauf hasard bien sûr. Il est donc incapable de déterminer ce qui importera le plus fonctionnellement au véritable utilisateur.
  • la troisième est d'ordre mathématique : si vous avez besoin de 20 variables pour faire fonctionner une page web (username, nationalité, date de dernière connexion, contenu du shopping cart, validation d'une case à cocher, …), il y a 20! façons de les combiner entre elles, soit 2,432 1018 possibilités, et donc de tests à mener … Ainsi on voit que la force brute, qui consiste à tout tester, seule chose que pourrait faire un développeur, mène à une impossibilité technique car, dans la majorité des cas, aucun ordinateur n'aurait le temps de le faire, même en attendant quelques milliards d'années. Les tests fonctionnels ne peuvent donc pas être menés par les développeurs, mais par les utilisateurs seulement. Seul un utilisateur métier saura choisir les quelques milliers de cas intéressants parmi les 2,432 1018 qu'il faudrait mener a priori.

L'idéal, pour mener des tests fonctionnels, est bien sûr le recours aux « bêta testeurs », des utilisateurs qui acceptent la frustration de rencontrer des bugs, et de vous en faire part. Mais l'internaute est zappeur et en général il quitte le site qui ne fonctionne pas. Il est alors nécessaire d'organiser les tests fonctionnels en interne, avant la mise à disposition du public. On met donc en place des « équipes de test ». On cherche aussi à automatiser le plus de tâches possibles, afin de réduire les coûts.

Automatisation : surtout pas de recording !

Une équipe de test peut être composée d'humains qui naviguent sur le site, jouant des parcours utilisateurs, ou « user stories », et qui notent les défauts. Il n'y a alors aucune automatisation et cette solution est très coûteuse à tous points de vue (temps, argent, personnel, …) mais elle fonctionne bien.

Pour réduire ces coûts, certains choisissent de procéder par « recording ». Il s'agit toujours de faire jouer des user stories à un humain, mais on enregistre son parcours. Les technologies disponibles sont nombreuses (Siesta, Protractor-recorder, SenchaTest, Sahi, …). On obtient alors un script de test rejouable par un ordinateur, sans plus avoir besoin d'un humain. En théorie, car en pratique cette solution est illusoire pour plusieurs raisons :

  • le même test joué par deux humains différents donnera deux codes différents, c'est à dire que les scripts issus du recording sont non structurés, interdisant toute manipulation automatique de ces codes. Pour les modifier, en vue d'optimisation par exemple, il faudra qu'un être humain les édite et les corrige manuellement, un à un.
  • La moindre modification d'un tag html dans une page rend en général obsolète tous les enregistrements qui l'utilisent, et qu'il faut donc réenregistrer.
  • On constate à l'enregistrement que nombre d'événements superflus sont ajoutés (clics supplémentaire, animation au passage de la souris , …), par suite les codes obtenus ne seront pas optimisés pour de bonnes performances, et les machines de test rameront.
  • Les vérifications de présence/absence d'un élément, de visibilité/invisibilité, de couleur, de changement de couleur en passant la souris, … sont impossibles.
  • Si un test de recording est en échec, cela peut venir de :
    • l'humain qui a mal enregistré,
    • le développeur qui a retouché le code pour l'optimiser,
    • un tag HTML qui a été déplacé,
    • le logiciel qui joue le recording,
    • d'un vrai bug fonctionnel qu'il faut détecter
    Ainsi le taux d'échec d'une campagne par recording ne peut jamais refléter fidèlement la qualité fonctionnelle de votre applicatif.

Le recording, en théorie c'est formidable, en pratique c'est un enfer qui ne vous fera rien gagner par rapport à une équipe de testeurs humains.

Reste une seule solution : la production de codes de tests structurés donc fiables, optimisés, performants. C'est ce que vous propose funKTest.

FunKTest, générateur de codes Protractor

On ne peut automatiser que ce qui est structuré. La situation idéale consiste donc à générer des codes de tests fonctionnels programmés de façon structurée et optimisée. On peut le faire avec différentes technologies : Protractor, Jasmine, Karma, Siesta, Sencha Test, … Même si les syntaxes varient, ces bibliothèques fonctionnent et se codent de façon similaire.

Malheureusement seuls les développeurs savent programmer, pas les utilisateurs métier. On pourrait dès lors être amené à penser que, finalement et contrairement à ce que j'écrivais plus haut, les tests fonctionnels devraient bel et bien être programmés par les développeurs. Ce serait confondre développement applicatif et développement de tests fonctionnels, qui sont deux mondes séparés, avec des outils spécifiques et distincts. La programmation de tests, quelle que soit la technologie (Protractor, Jasmine, Karma, Siesta, Sencha Test, …), est d'une simplicité extrême au regard de la programmation applicative. Elle est répétitive et sans valeur ajoutée, pour le fan de vraie programmation et de belle envolées algorithmiques. C'est tellement répétitif et bas de gamme que j'ai eu l'idée de créer funKtest pour trancher la question : ni le développeur, ni l'utilisateurs n'ont à programmer, funKTest le fait pour eux.

A y regarder de plus près, 95 % de notre comportement sur une page web consiste à scroller, cliquer sur un élément (coche, menu, bouton, …) ou à entrer du texte dans des inputs et des textareas. Les 5 % restant pour des doubles clics, des clics droits, et quelques actions exotiques. Vu du front-end, la situation est donc simple : il suffit de vérifier que les scrolls/clics/enter text fonctionnent. Et cela peut se faire sans connaissance du contenu cognitif de l'élément cliqué par l'utilisateur. Je veux dire que du point de vue de Protractor, et des autres, cliquer pour choisir l'option de carburation du moteur de la fusée Ariane, dans sa phase de satellisation orbite basse, ne fait pas de différence avec cliquer pour dire "j'aime". Au fond, tout ça n'est qu'un clic sur un élément HTML.

J'ai donc conçu une interface qui permet à un non informaticien, donc un utilisateur métier, de décrire les scroll/clics/enter text qu'il fait sur un site web, quel qu'il soit, pour accomplir sa user story. Une fois cette description faite, funKTest exporte les fichiers de codes de test Protractor correspondant. Ces scripts sont alors jouables par n'importe quelle machine de test ayant installé Protractor.
En plus (pour faire la nique au recording =;o) funKtest a le bon goût de proposer la vérification de la présence, de la visibilité et de la couleur des éléments d'une page, notamment avec le "mouseover".

Notez que j'aurais pu utiliser d'autres bibliothèques que Protractor, mais c'est une solution gratuite, de qualité, disponible sur tous les OS, maintenue (par Google), documentée et discutée sur les forums par une grande communauté de développeurs. Ce sont des critères de sélection capitaux lorsqu'il s'agit de choisir une technologie web.

Restant à votre disposition si vous souhaitez en savoir plus,
Cordialement,
Hervé


Aucun commentaire:

Enregistrer un commentaire