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.
[^] # Re: Tests différents (ou partiels)
Posté par stanlee974 (site web personnel) . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à 2.
Hello !
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
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
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.
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.