stanlee974 a écrit 10 commentaires

c'est un très bon point. On ne devrait pas vouloir récolter les fruits d'un investissement longtermiste sur du court terme. C'est totalement illusoire.

Mais c'est malheureusement ce que la société actuelle veut de manière général.

Il ne faut pas en faire une généralité. l'article parle bien de "la pertinence de vos tests de bout en bout". Donc ces exemples sont concrets. UUV présente une alternative pour faire les tests, mais en aucun cas il est dit, utilisez UUV dorénavant, parce que c'est l'idée du siècle et quand bien même ça serait dit, on a encore notre libre arbitre pour faire ce qu'on veut.
Il faut utiliser un outil parce qu'on croit en sa philosophie, à son potentiel et/ou à ses résultats, si on a rien de tout ça, restons avec nos outils qui ont un ROI assuré.

Je pense que c'est malheureusement ce qui détruit le secteur tertiaire, la micro chefferie et l'égoïsme pour un meilleur confort personnel. Très souvent le haut et le bas de l’échelle sont en accord, c'est souvent au milieu que ça déconne. Ce n'est pas une généralité, mais c'est ce que j'ai observé avec ma petite expérience.

On sait que les tests manuels sont très chronophages, donc c'est tout simplement de libérer du temps aux personnes qui font des tests de produits, pour faire des tests qui nécessite réellement une analyse et action humaine.

Hello !

L’exemple numéro 1 est rigolo, il est en plein dedans. Ce test va peter la seconde ou le label va changer. Ou peut être pas, si par malheur t’as un autre bouton nommé get started (que t’as oublié, ou qui est correct, les 2 sont funs, mais de façons différente)

UUV veut garantir que l'information restituée à l'utilisateur utilisant ou non un outil d'assistance, est correcte (ce n'est pas forcément ce qui est affiché à l'écran, si par exemple le bouton à un aria-label "Je suis un bouton" et son libellé est "bouton", UUV privilégie la donnée "je suis un bouton", parce qu'il se base sur le nom accessible calculé dont le calcul est spécifié par le W3C.)
Donc, si ton bouton est renommé, ton test doit planter, parce que tes spécifications fonctionnelles ont changées. Donc il faut les retoucher. S'il y a un 2ème bouton avec le même label et que tu n'as pas fait un focus logiciel comme tu l'aurais fait avec tes yeux, ça va planter, parce qu'il aura trouvé 2 boutons. La spec c'est par exemple, je dois avoir un bouton nommé bouton dans le panier et je dois avoir un bouton nommé "bouton" dans le menu. donc le focus est primordial regarde le scénario nommé TownSelection - Douala à la ligne 25

L’example numero 2 aussi est marrant. Ça marche, peut être. T’as deux options en fait. Une animation est ajoutée, et paf l’asynchronicite, t’as un test de shrodinger.

C'est un fait, ce n'est pas propre à UUV, mais à toute technologie de test E2E à minima. Il faut bien configurer les solutions que l'on utilise y compris les timeouts. Très souvent on laisse la conf par défaut qui n'est pas du tout adapté à notre besoin. Je préfère répondre comme ça, parce quand je lis tes remarque sur cette partie, c'est comme si tu préconisais de ne pas faire de test E2E automatisé du tout :-D

Une equipe qa qui roule bien, c’est des gens un peu technique qui arrive à groker pas mal d’outils, lisent du code pas trop aride sans trop de problème, mais galèrent à écrire autre chose que de l’impératif simple.

Ce que tu évoques est totalement vrai. UUV adresse les personnes autres que QA et développeurs pour avoir un prisme totalement vierge de technicité si c'est possible. ça donne des cas différents et qui permettre de rendre plus robuste le produit. La volonté est également de limiter le gap linguistique entre les différents acteurs. C'est une des plus grandes failles des équipes "agiles". Le vocabulaire doit être standardisé par équipe mais malheureusement pas mal de personnes restent dans leurs bounded contextes lorsqu'ils communiquent et ça donne lieu à plein de malentendus. UUV donne une possibilité de plus de communiquer, ça ne garantit pas que ça va fonctionner.

bref, les tests automatisés, c’est fait par des développeurs pour des développeurs, et ca sert à 100% à détecter les régressions, certainement pas à valider la feature en premier lieu. La qa c’est manuel, fait par des des profils précis, et c’est 100% pour ta validation initiale.

Donc j'avais bien senti ton point de vue. Je pense que dans le monde de l'informatique c'est pas tout blanc ou tout noir. Les tests automatisés, c'est avant tout automatiser ce qui est facilement automatisable et qui fait gagner du temps à être automatisé. On n'automatise pas les tests de cas ultra tricky dans les typologies hautes de tests. C'est pas fait pour. Certains usecases QA peuvent être automatisables rapidement et libère du temps aux QA ou autres acteurs qui font du test fonctionnel, mais ce qui n'est pas top, c'est que certains projets veulent tout automatiser et ça altère la perception vis à vis de ces pratiques de test.

Hello !

Merci pour ce cas d'exemple. Le but de l'auteur je pense, n'est pas de dire faite tout avec UUV ou vous pouvez tout faire avec UUV, mais plutôt : hey, il existe une alternative supplémentaire si vous voulez adresser un public plus large d'utilisateurs. A mon sens aucune solution au monde ne permet de tout faire :-) donc pour n'importe quelle solution il y a des cas qu'on ne peut pas gérer. Il faut donc soit switcher de solution, soit tester différemment.

UUV aborde une approche usercentric et se base sur les données accessibles pour requêter le DOM HTML.

Je l'ai dit dans un autre commentaire, le prisme de réflexion utilisé est celui de l'accessibilité pour être proactif plutôt que réactif sur le sujet, et le 2ème c'est qualité du produit en donnant la possibilité à plus d'acteurs du logiciels de tester.

Le test automatisé teste ce qui est facilement automatisable. Si c'est difficilement automatisable, il faut aller sur un test manuel ou un autre type de test. En aucun cas on ne peut préconiser de tout automatiser. Cela dit, dans ton cas, il y a des choses automatisable à mon sens. Déjà, comme toute application il faut rendre son application testable par rapport au framework de test qu'on utilise. C'est une vérité, si on veut faire un TU sur une méthode avec par exemple Junit, et qu'on a repository qui va taper une BDD, on va peut être mettre une interface ou je ne sais quoi en injection pour pouvoir faire un fake ou le mocker par exemple (si on ne la pas fait dès le départ).
Si on est en E2E et qu'on utilise cypress avec la volonté de tester un élément de DOM, on va rajouter un data-testid pour le récupérer. Donc déjà on a cette phase de rendre le code testable qui est faite naturellement par les dev qui font du test sans même s'en rendre compte tellement c'est naturelle. Ici avec UUV, comme ça se base sur l'accessibilité, il faut bien faire le nécessaire pour que les informations accessibles soient bien valorisées.

Après quand on parle de E2E sur un front, il y a plusieurs config:
- celle dans laquelle tu testes que le front isolé du back,
- celle dans laquelle tu testes ton front et ton back isolés des partenaire externes,
- celle dans laquelle tu testes ton système dans son ensemble comme une app en production.
Dans le cas que tu évoques c'est plutôt ce 3ème cas.

Celui que l'auteur évoque c'est plutôt le 1er ou 2ème cas car ils sont suffisants pour valider les 2 objectifs de UUV.

Ensuite, il faut se mettre dans un mindset où on se décorrèle des briques techniques que tu évoques. Je vais m'expliquer.

Le test commande par piloter le tunnel de vente pour commander un pizza, il faut déjà interagir avec le SSO basé sur keycloak en fédération d'identité avec Fatbook (le réseau social des gros mangeurs) qui propose du MFA par SMS => il faut comprendre openid connect et pouvoir appeler des API pour envoyer et recevoir des SMS ;

les couches techniques évoquées ici, peuvent être testées avec des tests de plus bas niveau comme des TU ou des tests d'intégration ou encore des tests manuels par exemple. Toute solution de test E2E sera en galère face à ce scénario si on ne rend pas la solution dans son écosystème testable en E2E. Donc les difficultés que tu évoques existent sur toutes les solutions E2E autres que UUV.

Toutefois, il peut être fait avec des automates si on veut vraiment le faire, si ceux-ci ont accès aux devices ou à des serveurs qui vont faire office de devices.
Les systèmes d'authent ont des mécanismes qui existent pour bypasser au niveau des tests, donc ceux-ci peuvent être utiliser, mais la pertinence du test est forcément impacté dans ce cas, si ton objectif est de tester le système dans son ensemble.

Je pense que le coeur de cible de UUV ou des tests E2E, n'est pas ce genre de use case.

il faut tester que le backoffice de réception des commandes en cuisine, celui-ci n'est pas accessible sur internet, le testeur doit déployer l'appli sur un serveur de test => Dave Ops est en congé, mais il a laissé les scripts Opentofu et Ansible avec un post it "tu verras c'est simple" ;

J'ai un peu répondu plus haut, tu peux rajouter plein de difficulté inhérent à des cas exceptionnels. Si tu veux faire des choses, il faut se donner les moyens de le faire. Si un projet veut faire du test E2E, il faut qu'il rende son produit testable et donc l'env doit être fait avant que Dave soit en congé. Sinon c'est un peu comme espérer gagner à l'euromillions sans avoir joué de ticket.

lorsque le livreur prends son skateboard, la puce IoT de ce dernier envoie un message qui est enregistré dans une base d'audit, il n'existe pas d'API pour y accéder => il faut donc taper la base directement en sql ;

Ici encore une fois, le produit n'est pas testable, même la feature n'est pas testable, que ce soit en TU, en test d'intégration ou E2E, donc il faut faire le nécessaire avant de se lancer dans les tests. Normalement la stratégie de test, est quelque chose qui doit se réfléchir avant que le projet se lance, tout comme les apsect sécu, tracing, archi logiciel, système. Malheureusement c'est fait que trop tard et ces situations peuvent exister.

Chaque outil est différent et est fait dans une philosophie à appréhender. Du coup, je trouve assez réducteur de mettre tous les outils de simplification dans le même panier.
Ce que tu dis est vrai en parti sur la maintenabilité des tests trop complexes :-), c'est une vraie douleur. Mais, le but n'est pas de faire tous les tests en test E2E, il faut bien choisir sa stratégie de test et tester les choses avec la bonne typologie de test (unit, static, integration, E2E etc.). Si les tests sont trop compliqués ce n'est pas à cause de l'outil mais plutôt à cause de l'usage que l'on fait de l'outil. Peut être que l'outil qu'on utilise n'est pas adapté au type de test que l'on veut faire.
Un outil est censé faciliter les choses, s'il ne facilite pas, c'est qu'il n'est pas le bon pour ce que l'on veut faire, mais en aucun cas, ça signifie que l'outil est mauvais.

Par exemple, on peut faire des tests unitaire Front avec Cypress avec le mode component. Mais est ce que c'est vraiment adapté de faire des tests unitaires en cypress component qui va donc initialisé un contexte navigateur avec rien dedans?

Je ne sais pas si tu vois ce que je veux dire.

Effectivement le challenge est d'identifier de manière unique un élément.
UUV prévois des phrases pour faire un focus comme on peut le voir ici

Un peu comme le ferai un utilisateur voyant en regardant une zone dans laquelle il va faire une recherche (dans l'exemple de playwright, on va regarder quel product on veut, trouver le bouton en dessous et cliquer dessus), avec UUV, on va faire un within pour spécifier que c'est dans cette zone spécifique que l'on veut rechercher et ensuite on fait sa recherche ou son click. L'ambiguïté est levée non plus en utilisant un identifiant unique mais plutôt par une donnée accessible unique.

Le soucis des enregistreurs c'est que pour maintenir les tests, on réenregistre très souvent nos scénarios :-(
A mon avis, ce n'est pas une solution en soit.

Hello !

Il est clair que sur le ton accusateur utilisé n'est pas du tout approprié à mon sens. Je vais le mettre de côté pour pouvoir te répondre.

Si on intervertit les textes de app-title et start-button, le test programmeur et utilisateur ne passeront pas tous les 2, parce que le test utilisateur ici s'appuie sur des tests programmeurs, comme UUV va venir en abstraction par rapport à cypress dans cette exemple ou playwright.

"le test est pour vérifier que le développeur ne casse rien lors d'une PR, le test est certes sur une UI mais pour le programmeur par le programmeur pour ne rien casser pendant un développement",

c'est vrai lorsqu'on utilise le prisme de développeur, celui que tu utilises dans tes analyses et qui t'obliges à associer forcément le mot test à ton contexte que tu connais bien, je suppose qui est le développement. Je t'invite à consulter cette vidéo nommée Revisitons tous nos a prioris sur le(s) test(s) - Christophe Thibaut visible sur chaîne de test pour adapter ton prisme d'analyse si tu le souhaites.
Ici 2 prismes sont utilisés le premier est celui de la maximisation de la qualité produit en diversifiant les tests par plusieurs acteurs du logiciel autres que les développeurs et les testeurs. Le second est maximiser la qualité de données, restituée à nos utilisateurs y compris ceux qui utilisent des outils d'assistance et ce en proposant une posture proactive plutôt que réactive concernant l'accessibilité numérique.

start-button n'a pas été rajouté par hasard

effectivement, peut être que ça a été rajouté par un habitus de développeur qui n'a eu qu'à sa disposition que des outils techniques ou qui reproduit ce qu'il sait faire. Peut être que derrière le start-button, il y a plutôt un lien et que l'identifiant est mal nommé et que ça peut induire en erreur d'autres développeurs qui ne sont pas dans la devTeam et qui vont tester l'application parce qu'ils sont mandatés côté métiers?
Qui vérifie que ce bouton est bien un bouton? Qui vérifie que l'id start-button est renommé en cancel-button, si le libellé du bouton est renommé en cancel?
La solution va permettre de vérifier les informations liées à l'accessibilité en plus des autres aspects et rajoute une couche de vérification niveau produit pour les cas où les développeurs seraient en surmenage par exemple.

Typescript permet beaucoup de tests, et à ma connaissance ce n'est pas la première fois qu'on essaye des "User centric Usecases Validator"

il faut prendre conscience que la solution adresse les personnes non techniques d'un projet en utilisant cucumber (c'est bien la volonté de Seb Rose le créateur de cucumber), si tu n'admets pas cet aspect, c'est que tu n'acceptes pas non plus la philosophie de cucumber qui est adoptée par pas mal de projets maintenant. Moi personnellement, je pense que ça a du bon, ça ne permets pas de tout faire, ce n'est pas la volonté d'avoir une stratégie de test en cornet de glace, mais ça donne l'opportunité à plus de monde de faire des choses sans maîtriser la technique :-)

Ton point 3 commence déjà à montrer des limitations du "langage naturel", ça parle anglais tout le temps sauf bam un JSON pas naturel du tout

ça devient intéressant. C'est effectivement une limitation forte de ce langage, qui n'est pas destiné à tout tester, mais peut être qu'ici la forme employée n'est pas la bonne, c'est une phrase très technique à vrai dire et je pense qu'on peut mieux faire, comme c'est open source, tu peux faire une PR pour proposer quelque chose de plus pertinent. Toutefois, dans cet exemple, l'approche usercentric pour effectuer des vérifications d'accessibilité normalisées par un référentiel et une codification qui lui est propre, n'a pas réellement de sens.

le terme de hors sujets, c'est ce que tu décides de mettre en hors sujet, car les propos évoqués ne sont pas hors sujets par rapport à l'article qui est d'analyser 3 mauvaises pratiques, ou erreurs courantes, qui limitent la pertinence des tests E2E.

Si le but était de faire réellement la promotion de UUV, l'article aurait été écrit différemment je pense.

Pour finir pour les comparaisons entre cypress et UUV, voici deux liens qui pointent sur 2 katas attaquant la même application.
- cypress
- UUV

En espérant avoir répondu à tes questionnements.