Tests fonctionnels du site

a marqué ce sujet comme résolu.

Reprise du dernier message de la page précédente

Là c'est pertinent.

Je maintiens que le message de l'article que j'ai passé n'a pas été compris. Le problème, c'est pas la DSL. Le problème, c'est les DSL lourdingues qui essaient d'imiter le langage naturel.

J'ai bossé 6 mois à plein temps avec ce genre de conneries1, ça n'apporte qu'une seule chose : rendre le bordel illisible. Les pseudo-phrases, c'est joli dans les exemples, c'est imbitable dans la vraie vie, c'est plein de bruit qui n'aident en rien à la compréhension et ça n'aide personne, parce que quoi que prétendent les concepteurs de ce genre de chose, c'est extrêmement rare que des personnes non techniques écrivent ou relisent ce genre de tests.

Dans ton exemple, tu parles de "dev front". Ce sont des devs. Ils sont parfaitement capables de manier un langage de programmation. La preuve : en choisissant un DSL qui ressemble à un langage framework qu'ils connaissent (jQuery), ils s'en sortent très bien.


  1. Plus exactement "Progress 4GL", un langage "conçu pour faciliter l'audit", dont les lignes de code sont des "phrases" qui se terminent par des points, etc. C'est complètement illisible, que ce soit par des développeur ou par des personnes non-techniques (parce que la personne non-technique ne comprends pas ce que fait le code, outre le fait que les phrases n'ont pas vraiment de sens). 

OK, donc il faut essayer de mesurer la qualité de la DSL de lettuce / cumcumber.

Là je m'efface car je ne la connais pas assez. J'apprécie l'approche geb car justement la DSL est fait pour des devs tout en restant compréhensible par des humains dans des cas simples.

La syntaxe de sélecteurs jquery est quasiment comprise par tous les développeurs aujourd'hui. C'est presque devenu un standard de fait . Donc c'est parlant. La syntaxe à base de expect, when, then, and, where permet de structurer le test de façon à ce qu'il se lise comme un test (et ça c'est hyper important et parfois difficile à lire dans les TU : "mais qu'est-ce-qu'il veut faire ???"). "Quand je fais ci, j'attends ça. Je paramètre mon test pour qu'il turne avec X ou Y cas" c'est ça un test. Et la DSL doit mettre ça en avant.

Je vous laisse juger de la DSL de lettuce. Là, je peux plus trop avancer de retour d'expérience, malheureusement.

Happiness is a warm puppy

+0 -0

Quand j'ai relevé l'utilité de ce genre de tests, le but principal était surtout de soulager la QA au maximum. Quand on fait un tour sur le dépot du projet, on constate souvent des indications du genre (dans les issues, comme dans les tests de la PR) :

Scénario :

1
2
3
4
- Connectez-vous avec le membre admin ;
- Importer un big tuto ;
- Demandez la validation du tutoriel ;
- Lancez la procédure de publication du tutoriel, une erreur est lancée :

déclaration d'une issue

ou encore

Scénario appliqué pour la QA :

1
2
3
4
- Création d'un mini-tutoriel
- Création d'un extrait et validation de ce dernier
- Edition de l'extrait, prévisualisation et validation. Aucun message
- Edition de l'extrait, deux prévisualisations. ** Aucun message**

Puis : les tests des tutoriels sont toujours au vert.

QA ok pour moi.

rapport de QA d'un contributeur

On est sur la même logique avec un outil comme lettuce. Et plutot que ce soit quelqu'un qui lance le site, clique par ci et par là, c'est celui qui fait la QA qui s'en chargerait tout simplement en rédigeant les cas de tests un peu tordu et en laissant faire la machine.

L'avantage ici étant qu'on teste presque tout de manière automatique et que ça reste plus lisible pour quelqu'un qui ne connait pas le python que les fichiers de tests écrit en python.

En gros, ça revient à rédiger un cahier de recette qui sera déroulé automatiquement. L'outil ne fait que tester que ton site affiche ce qu'il doit affiche quand tu appuie sur les bon bouton. En tout cas de ce que j'ai pu voir en le testant, ça me parait tout indiqué.

+3 -0

Après y'a en effet un usage… Au boulot, ça va faire deux ans qu'on est passé sur du Gherkin, mais dans un excès de zèle, on a fait trop de phrases spécifique a une action. Alors, développant une API REST, on aurait du se limiter à ce genre de trucs (c'est d'ailleurs dans les cartons) :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
Scenario: Foo
  Given I am authenticated as test
  When I prepare a "GET" HTTP request to "/foo"
    And I add a parameter "bar" with a value "baz"
    ...
    And I send the request
  Then the response status code should be 200
    And I should have a json response
    And I should have a key `success[data]`
    ...

Ce qui est tout de même assez clair, ne demande pas beaucoup de contexte à développer, … et reste surtout compréhensible par un péon qui arrive plus tard sur le code (ou pour nous, un dev front qui veut utiliser notre api). C'est en effet le standard introduit par Cucumber (Given, When, Then).

Édité par Talus

Quantiquement votre. Extension de tests d’API via Behat (PHP) : Behapi

+1 -0

En fait cela soulagerait la QA qui n'aurait plus à se tapper les erreurs 500 mais la QA teste aussi l'UX donc ton scénario elle devra le faire quand même, malheureusement.

Édité par artragis

+0 -0

En fait cela soulagerait la QA qui n'aurait plus à se tapper les erreurs 500 mais la QA teste aussi l'UX donc ton scénario elle devra le faire quand même, malheureusement.

artragis

Les seules fois ou on aurait besoin de tester l'UX serait en cas de modification de css. Et encore c'est le genre de chose qu'on peut se permettre de découvrir en phase de release (car un problème d'affichage css est vite hotfixé).

+0 -0

la QA teste aussi l'UX donc ton scénario elle devra le faire quand même, malheureusement.

artragis

Attention à ne pas confondre UX et design. Je ne doute pas une seconde que tu fasses la différence, mais c'est pas clair dans ton message.

L'UX est couverte par ce genre de tests. C'est même leur intérêt premier.

Typiquement : "Je dois pouvoir envoyer mon tutoriel en validation par un simple clic sur la page A" c'est de l'UX, et c'est couvert : le bouton est présent, quand je clique dessus je suis redirigé vers la bonne page et mon tutoriel est passé en attente de validation.

Par contre, le fait que le menu soit à gauche et pas à droite, ça c'est hors scope. On sait que la fonctionnalité est disponible de la façon dont on l'a pensée (donc on est pleinement dans l'UX : c'est le clic sur un bouton qui permet la fonctionnalité) donc on couvre une partie seulement de l'ergonomie (on est agnostique de l'agencement des boutons par exemple). Juste pour clarifier ton propos si tu permets.

Édité par Javier

Happiness is a warm puppy

+2 -0

L'UX est couverte par ce genre de tests. C'est même leur intérêt premier.

Non. elle ne teste pas la facilité d'accès, la rapidité de réaction etc. Elle teste juste la fonctionnalité et peut être sa fluidité mais pas plus. Tu peux faire ressembler ZDS à blender, ton UX sera pourrie, tous les tests fonctionnels passeront.

Typiquement : "Je dois pouvoir envoyer mon tutoriel en validation par un simple clic sur la page A" c'est de l'UX

typiquement "le bouton se trouve en gros est le premier à être accessible, n'est jamais supperposé à un autre élément d'interface quand on scroll, ne doit pas être caché dans un menu… ça c'est de l'UX qui ne peut être testée fonctionnellement.

Je parle de ce qu'il s'est passé lors de l'élaboration de la ZEP03 là, pas d'hypothèse, de réalité.

Édité par artragis

+1 -3

typiquement "le bouton se trouve en gros est le premier à être accessible, n'est jamais supperposé à un autre élément d'interface quand on scroll, ne doit pas être caché dans un menu… ça c'est de l'UX qui ne peut être testée fonctionnellement.

artragis

Oui, c'est bien ce que j'appelle problème dans le css. Il n'existe pas encore de méthode fiable pour tester automatiquement que le code sera fidèle à la maquette attendue. En fait si, on peut toujours screenshooter un écran automatiquement et comparer le rendu avec une maquette pré-designée (comparaison d'image toussa), mais ça serait un peu overkill.

+2 -0

Comme l'exprimait très justement AlexD à l'époque le front n'est pas que le design et si l'UX s'appuie clairement sur la maquette visuelle, elle ne contient pas que ça.

Ce que tu appelles dse "problèmes de css" sont bien plus que ça. Penses-tu que l'accessibilité aux personnes qui sont obligées d'utiliser un lecteur d'écran ne se règle qu'avec du CSS? Crois-tu que c'est un simple "problème de CSS" que d'avoir ZDS qui fait crasher IE sur Windows Phone? Crois-tu que l'ajout du lien vers les messages privé dans la ZEP03 soit un "problème de CSS"? Pourtant on est en plein dans l'UX. De même, lorsque le validateur valide un tutoriel, dans l'ancien modèle un MP était envoyé un chaque auteur. Fonctionnelement parlant le test aurait dit "trop cool", mais côté UX, ça faisait deux discussions cloisonnées jusqu'à ce que le valido ajoute un participant.

Les tests fonctionnels sont des tests de non régression, soyons honnêtes, ZDS n'est pas développé selon la méthode du TDD. En fait, on n'est même pas dans les clous de n'importe quelle méthode existante. Tant que nos membres s'y retrouvent c'est bien mais il va falloir être honnêtes : nous allons devoir quand même faire des tests de QA chez nous. Ne serait-ce que parce que notre site est responsive et donc doit être testé sur plusieurs plateforme. Une QA c'est long parce que je dois tester sur mon ordi ET sur mon mobile. Un jour peut être même sur tablette.

+1 -1

Penses-tu que l'accessibilité aux personnes qui sont obligées d'utiliser un lecteur d'écran ne se règle qu'avec du CSS?

L'accessibilité est un vaste de domaine. Et oui, les tests fonctionnels (tels que décrit ici) peuvent couvrir une partie d'accessibilité. Vérifier que les balises img ont toujours un attribut alt, verifier que la touche Echap te permet de fermer une modale, vérifier que ta page contient des titres, etc. Tout ceci peut être englobé dans une directive "Je m'assure que ma page est accessible". Il te reste des choses que tu ne pourras pas tester, mais si ça arrive, le problème sera sans doute coté css.

Crois-tu que c'est un simple "problème de CSS" que d'avoir ZDS qui fait crasher IE sur Windows Phone?

Ce problème est couvert par les tests fonctionnels car il te suffit de demander à selenium de démarrer un webdriver windowsphone et de lancer ses tests dessus.

Crois-tu que l'ajout du lien vers les messages privé dans la ZEP03 soit un "problème de CSS"?

Ce cas est lui aussi couvert. Et comme pour tous les tests, il faut avoir écrit quelque part "Je veux que sur ma page d'aide, un lien soit affiché pour contacter l'auteur".

Les tests fonctionnels sont des tests de non régression, soyons honnêtes

Là c'est peut être parce que tu ne les a jamais utilisé comme il faut. L'idée n'est pas de dire qu'on ne fera plus jamais de QA, mais que l'idée de la QA se résumerait à rajouter un cas non testé dans le tableau.

Si je prend le cas de j'ai écris en gherkin :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Fonctionnalité: Inscription
    Pour parvenir à utiliser le site pleinement en tant qu'utilisateur nous devons être inscrit

    Scénario: Accéder à la page d'inscription étant déconnecté
        Je ne suis pas connecté
        Quand je vais sur le lien inversé "register"
        Je vois dans le titre1 "Inscription classique"
        Je vois dans le titre1 "Inscription via reseau sociaux"

    Scénario: Réaliser une ou plusieurs inscription(s)
        Utiliser selenium
        Je ne suis pas connecte
        Je vais sur le lien inversé "register"
        Je remplis le champ "id_email" avec "<email>"
        Je remplis le champ "id_password" avec "<password1>"
        Je remplis le champ "id_password_confirm" avec "<password2>"
        Je remplis le champ "id_username" avec "<username>"
        Clique sur le bouton "input[name=submit]"
        Le résultat de la soumission du formulaire doit etre "<result>"
        Si "<result>" est OK alors j'ai reçu un mail dont l'objet est "Confirmation Inscription"
        Si "<result>" est OK alors j'ai reçu un mail avec dans le message "Merci"
        Si "<result>" est OK alors je ne peux pas encore me connecter avec "<username>" et "<password1>"
        Si "<result>" est OK alors je clique sur le lien d'activation dans le mail
        Si "<result>" est OK alors je peux me connecter avec "<username>" et "<password1>"

    Exemples:
        | email             | password1   | password2   | username | result |
        | user1@gmail.com   | password1   | password1   | user1   | OK      |
        | user2@gmail.com   | password1   | password2   | user2   | KO      |
        | user3@gmail.com   | user3       |  user3      | user3   | KO      |
        | user1@gmail.com   | password1   | password1   | user4   | KO      |

C'est assez simple de lire ce que je teste et ce que je n'ai pas testé. Tout aussi simple de rajouter un nouveau cas de test.

Cependant les test unitaires pures doivent rester. Mais les tests d'intégrations que l'on fait aujourd'hui en python ne sont pas efficaces

+0 -0

@artragis:

Déjà, du calme. Je te trouve bien véhément, surtout quand tu parles de "pas d'hypothèse, mais de réalité". Je sais pas trop comment je dois le percevoir, donc soufflons deux secondes.

il va falloir être honnêtes : nous allons devoir quand même faire des tests de QA chez nous

Bien évidemment. Et personne n'a dit le contraire. Et je pense qu'autant Talus que firm1 (j'imagine ?), moi ou tout autre personne qui emploie cette méthode pourra te dire qu'avoir des tests d'intégration n'empêche pas qu'il y ait une passe de QA manuelle. Les deux sont parfaitement complémentaires (entre autres pour certaines raisons que tu as citées).

L'idée, c'est de pouvoir faire de la QA "le coeur léger". Bien entendu qu'une ZEP qui part en prod va passer par des tests manuels, va être confrontée à des utilisateurs, va passer sur tablette, mobile, etc. Encore heureux…

Simplement, l'énorme avantage de ces tests (outre repérer des régressions) c'est surtout de pouvoir soulager la QA. Et le mot "soulager" est important. La QA ne devrait plus dérouler des scénarios préconçus pour reproduire des bugs. Ce n'est pas intéressant à faire d'une part, c'est rébarbatif et ça ennuie tout le monde. Là, le but du jeu de la QA manuelle devient (grosso modo) : "joue avec l'interface en tant qu'utilisateur et remonte tes attentes/problèmes, la majorité des scénarios et des problèmes bloquants sont déjà couverts".

Quand tu parles d'accessibilité aux lecteurs d'écran c'est le contraire pour moi. Les règles qu'a décrites QuentinC dernièrement sont assez faciles à modéliser à l'aide de ce genre d'outils (les items de navigation sont bien des liens, …). En tout cas bien plus simple que d'installer un lecteur d'écran ou aller demander à un membre qui dispose d'un lecteur d'écran.

Tu t'enflammes pour pas grand chose. Ce que j'appelle ergonomie (et je l'ai précisé dans mon message) n'est pas entièrement couverte par ce genre de tests. L'agencement des éléments, leur affordance, l'organisation d'éléments de formulaire, etc. autant de choses cruciales qui vont manquer.

Par contre oui, on a une garantie partielle que l'interface n'est pas bloquée, que les éléments attendus sont là, même si malheureusement ils ne sont pas placés où on le souhaiterait. Bref, que la fonctionnalité est utilisable. Pas imperfectible, mais décente. Et oui, quand une nouvelle fonctionnalité/page sort, tu auras une passe manuelle très importante à faire dessus. Ça tombe bien, puisque tu auras passé moins de temps à chasser des régressions.

Maintenant, je ne pense pas que ça vaille la peine de s'étriper, je pense que personne n'est assez cinglé pour dire qu'on pourra se passer d'une passe de tests manuels. Faut juste voir la chose suivante : une régression détectée par un test auto, c'est autant de temps gagné en QA (puisque si tu l'avais vu en QA, ça voulait dire re-belotte).

Happiness is a warm puppy

+1 -0

Déjà, du calme. Je te trouve bien véhément, surtout quand tu parles de "pas d'hypothèse, mais de réalité". Je sais pas trop comment je dois le percevoir, donc soufflons deux secondes.

Je ne suis pas véhément, je suis un de ceux qui a poussé l'amélioration des tests unitaires pour ZDS alors tu sais, plus de tests pourquoi pas? surtout si les gens derrière maîtrisent l'outil.

Le truc c'est que je vois firm1 qui dit "ça allégera la QA car ça permettra d'éviter de tester les scénarios". Comme je le disais, cela n'aura pour effet que de tester que la fonctionnalité existe et est opérationnelle. L'UX n'est pas testée. Si lorsque je fais ma QA je vois que sur mobile c'est complexe à utiliser, va quand même falloir que je me tappe tout. La seule différence c'est que les erreurs 500 ne seront pas à tester car le test fonctionnel sera là point.

Quand je dis "la réalité", c'est que personnellement je parle au présent. j'ai vu et j'ai appris de ce que les différents gros développements du site ont manqué. On a déjà pas mal corrigé le tir par rapport à l'instabilité que cela avait causé dans le module de tuto lors de la publication du site. Nous sommes une très bonne équipe et nous apprenons de nos erreurs.

Maintenant quand on présente de manière très incantatoire ce que pourrait nous amener un outil, je me méfie surtout que les plus gros problèmes que nous avons eu se sont situé au niveau… des outils. npm qui plantait, pip qui voulait pas installer lxml, cabal qui mettait des plombes à compiler… Aujourd'hui on nous propose d'ajouter un outil, que finalement peu de personnes n'a utilisé car chacun a utilisé ses propres outils de tests, du selenium de base à cucumber en passant par quelques autres. Alors, oui, je doute.

je doute d'autant plus que la proposition se base sur l'idée que nous sommes sensé faire du TDD mais que l'historique de git nous prouve… le contraire.

Je pense qu'on a pensé que je m'enflammé car l'écrit ne permet pas de transmettre réellement l'état dans lequel on est mais, là je suis calme, j'essaie de voir le pour et le contre. Bon après, je vais aussi avouer que j'ai toujours eu un très mauvais ressenti avec les fuameux outils qui voulaient parler en "langage courant". Encore pire quand on utilise les users story. Les given when then, je suis venu, j'ai vu, j'ai vomis. Il faudrait que je ressorte le cahier fonctionnel d'un de nos projets où d'une fonctionnalité dont on avait une idée très claire malgré sa complexité à implémenter nous avions dû faire une quinzaine d'user story tous trop long à cause des conjonctions et disjonctions. Tout n'est pas fait pour être formulé dans ce formalisme.

Je ne donne que mon avis. J'adore la philosophie ZDS qui prône la démocratie. Si vous mettez en place un outil de test fonctionnel, non seulement je m'y formerai mais en plus je l'utiliserai de manière assidue car je crois en ce projet. Mais pour l'instant, je suis perplexe quant à leur facilité d'utilisation, leur stabilité et le temps (la ressource dont on manque le plus) qu'ils nous demanderont.

+5 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte