Testing is not a crime

Technique, User Experience

25 sept, 2018

Le test ou la vie

Nous avons tous à coeur de livrer un produit fini parfait à notre client, répondant à toutes ses exigences, sans dysfonctionnement et cerise sur le gâteau avec un design avant-gardiste.

Pour arriver à ce résultat ultime, nous devons passer par une case primordiale que certains fuient comme une épidémie de virus H1N1 : la phase de vérification, qualification, test ou encore recette, qui soit dit en passant évitera de se dire « Dans le doute, on livre… », le jour précédent la livraison du précieux aux utilisateurs.

sebastien1 Testing is not a crime

Quels tests ?

Les types de tests sont multiples, ici on retiendra les principaux dans une phase projet, on précisera l’acteur qui est en charge de les réaliser, l’environnement sur lequel ils sont joués et le moment auquel ils sont réalisés :

– Les tests unitaires
Qui ? Agence / Equipe de développement
Quand ? Après avoir terminé un développement, souvent automatisé en intégration continue
Où ? Sur le poste de développement

sebastien2 Testing is not a crime

– Les tests d’intégration
Qui ? Agence / Equipe de développement
Quand ? Après avoir terminé un ensemble de développements qui permettent le test intégral d’une fonctionnalité utilisateur sur un environnement dédié
Où ? Sur un environnement dédié iso production, dit de recette

sebastien3 Testing is not a crime

– Les tests fonctionnels
Qui ? Agence / Equipe fonctionnelle / UX
Quand ? Après la validation de l’intégration de la fonctionnalité sur l’environnement dédié
Où ? Sur un environnement dédié iso production, dit de recette

sebastien4 Testing is not a crime

– Les tests d’acceptation (aussi appelé Recette)
Qui ? Clients / Utilisateurs finaux
Quand ? Après validation des tests fonctionnels
Où ? Sur un environnement dédié iso production, dit de pré-production

sebastien5 Testing is not a crime

En UX, pour les tests fonctionnels, ce qui prend tout son sens ce sont les tests de bout car ils apportent quelque chose d’intéressant : vérifier les attendus front-office, leurs interactions avec le back-office et les éventuelles interfaces web services, en entrant dans la peau de l’utilisateur.

Comment ça se passe ?

Sous la forme d’un scénario d’utilisation, le test va raconter une histoire qui a du sens pour l’utilisateur, prenons l’exemple suivant pour le cas d’une boutique en ligne :
– Paul l’internaute accède à la boutique monshop.com
– Il recherche l’article ABC dans la page des articles en promotion
– Il consulte la fiche du produit
– Il modifie la couleur du produit
– Il ajoute le produit à son panier
– Il consulte son panier et modifie la quantité de l’article ABC
– Il choisit le mode de livraison retrait en magasin
– Il règle son panier avec son compte PayPal

sebastien6 Testing is not a crime

On retrouve ces cas d’utilisation en méthode A.G.I.L.E. pour décrire et spécifier une exigence utilisateur, ce qui permet de faire un parallèle très pertinent entre les phases projet de spécification et celles de test fonctionnel.

La phase de test est constituée de plusieurs scénarios qui constitueront un plan de tests, ou cahier de recette.

Quels outils ?

Côté outillage certes, un bon vieux tableur permet de faire le job, mais de nouveaux outils tentent de faire évoluer les habitudes et apportent un renouveau dans la façon de développer/tester : en intégrant le besoin utilisateur au plus près du développeur, en proposant de l’automatisation, des rapports, une interface de configuration et bien d’autres fonctionnalités.

On en retiendra 2 qui nous ont paru très intéressantes et s’utiliseront dans différentes situations selon le projet à mener : Cypress et Behat*.

sebastien7 Testing is not a crime

Cypress :

C’est un outil open source de tests d’applications web qui s’exécute directement dans le navigateur, côté client donc, à l’instar de Selenium.

Son avantage est d’être totalement autonome, il ne nécessite pas de serveur ou autre dépendance pour fonctionner. Les tests sont faciles à lire et comprendre, à condition d’avoir tout de même des notions de Javascript. L’exécution des tests dans le navigateur s’avère très rapide. En cas d’erreur, les messages sont explicites et permettent rapidement de solutionner le problème.

Comme il fonctionne dans l’application testée, Cypress dispose d’un accès natif à chacun des objets, de la fenêtre, du document, en passant par le DOM, tout ces éléments sont manipulables dans vos tests.

Le fait de garder le contrôle sur l’application testée, le trafic réseau et l’accès natif à chaque objet hôte, offre de nouvelles possibilités. Cypress permet de modifier n’importe quel aspect du fonctionnement de l’application :

– Imiter le navigateur ou les fonctions de l’application et les forcer à se comporter comme il le faut dans un scénario de test.
– Exposer des data-stores afin de modifier l’état de l’application directement à partir du code de test.
– Tester comment l’application réagit aux erreurs en retournant des codes d’erreurs HTTP.
– Modifier les éléments DOM.
– Piloter des composants en appelant les méthodes directement à partir du code de test pour les contrôler.
– Contrôler le temps de façon à ce que les timers se déclenchent automatiquement sans avoir à attendre le temps requis.

image5 Testing is not a crime

Il exécute la plupart de ses commandes dans le navigateur, il n’y a donc pas de lenteurs dues au réseau. Les commandes exécutent et pilotent l’application aussi rapidement que possible.
Pour gérer les interfaces utilisateurs complexes, il est possible d’utiliser des assertions pour lui indiquer l’état souhaité. Il attendra alors que l’application atteigne cet état avant de passer à l’étape suivante.

L’interface de Cypress montre l’exécution des commandes en live, les assertions, les requêtes réseau, les chargements de pages ou les changements d’URL.
Pendant l’exécution du test, il prend des captures d’écran de l’application et permet de remonter dans le temps jusqu’à l’état dans lequel elle se trouvait au moment de l’exécution des commandes. Il est également possible d’enregistrer le test en vidéo.
Cypress va conserver un historique, une trace de l’exécution ainsi que les résultats obtenus ce qui permet d’être consultable et partagé aux membres du projet pour analyse.

Avec un peu de pratique, cet outil s’avère être un gain de temps, dans la maintenance des tests, dans leur exécution automatique et également sur le compte rendu des résultats,  permettant de pointer avec précision les erreurs techniques qui pourront être mieux traitées par l’équipe de développement.

De  notre point de vue, l’important lorsque l’on est en phase de testing d’une application est d’arriver à s’approprier et bien comprendre le besoin de l’utilisateur, d’où l’utilité de décrire des scénarios simples, orientés vers l’utilisateur final.

Toutefois leur description, et surtout leurs résultats doivent être suffisamment précis lors des détections d’erreur afin de remonter un maximum d’informations à l’équipe de réalisation en vue de les aider à corriger plus facilement l’anomalie, et ce quel que soit l’outil utilisé.

 

Sources :

cypress.io
https://www.sodifrance.fr/blog/creez-vos-tests-end-to-end-avec-cypress-io/
behat.org

 

*Behat :
Développement axé sur le comportement, on ne re-présentera pas cet outil dans l’article car celui-ci a déjà été présenté dans une autre réflexion DISKO, à consulter ici.

 

Laisser un commentaire.