• [^] # Re: Tests différents (ou partiels)

    Posté par . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à 3.

    Je pensais plus aux tests d'acceptance qui sont écrit dans les users stories.

    Mouaif. Je suis loin d’être convaincu. Peut être qu’on bosse comme des porcs chez moi, mais au mieux du mieux, tu va avoir peut être 80% de couverture sur des uat dans le ticket, et uniquement sur la logique métier pure. Toute la partie technique (typiquement, si ton backend se ramasse, backward compat pour appli, race conditions, etc) ne sera pas couverte par ces tests. C’est certainement une bonne base pour commencer ton test plan, mais ça gratte juste la surface.

    Manuellement ça ne monte pas à l'échelle et c'est sujet à nombre d'erreur.

    Pour avoir vu "l’équipe d’en face" à fond dans la mentalité "on test tellement tout via automation qu’on a viré toute la qa", je suis pas sur si je suis d’accord.

    Leur Jira board avait vachement moins de bugs, pour le coup, faut rendre à cesar ce qui appartient à cesar. Mais c’est surtout parce que y’avait personne pour les remonter, en fait. Des bugs, y’en avait absolument partout, et des gros comme le nez. Genre le coup du deuxième bouton get started, ils l’ont eu. Ils auraient du le changer, et ils l’ont pas fait.

    apres, je suis pas sur de suivre. Tu dit que c’est pas raisonnable de tester manuellement chaque nouvelle feature que l’équipe pond?

    Pour clarifier, ma position c’est que l’automation n’est pas fiable pour valider une nouvelle feature, aussi petite soit elle. Une machine c’est con, et ça rate ce qu’on lui dit pas de capturer. Par contre, c’est super baleze pour vérifier que les tests existants passent toujours, de la régression quoi. Un humain va te trouver plein de petit détails à la con. Alignment off by 1 pixel, copie qui sonne bizarre, intégration de la feature dans le reste de l’écran, label tronqué (bon courage pour faire comprendre ça à une machine, en tout cas sur iOS), tout un paquet de petits trucs qui s’additionnent.

    Si tu peux trouver un ingénieur pour écrire le code, tu peux trouver un qa pour le tester. 1 qa pour 3 à 5 développeurs, c’est grosso modo le ratio que tu veux. Ça passe très bien à l’échelle de ce que j’en voit.