Gestions des tests et visibilité

val · Avril 5, 2023, 6:01

Bonjour,

J’aimerais avoir vos retours d’expériences concernant les tests automatiques, voir ce qui se fait le plus.
Ma question est quels tests vous faites et comment sont-ils visible dans votre board Scrum/Kanban?
Voilà ce que j’imagine personnellement :

Test unitaire (mocké) → directement inclus dans la définition of done, fait à chaque fois
Test d’intégration (toujours bas niveau mais qui va toucher plus de méthodes et/ou la bdd) → là je ne sais pas trop si la bonne pratique est d’en faire à chaque fois ou pas, car c’est plus lourd mais c’est souvent là qu’on se retrouve avec des bugs.
Test fonctionnel genre BDD/ATDD (sans le UI) → même sans le UI, est-ce trop d’en faire pour toutes les US (et de l’intégrer dans la DoD)? l’idée est d’éviter la fameuse pyramide de test inversée.
Test de scenarios, end user (incluant le UI) → dans une tâche à part car ça peut prendre plusieurs story, et pas forcement développé dans le même sprint. Ca veut dire que c’est à prévoir dans le backlog.
Test de performance → pareil, dans une tâche à part

Pour le UI j’hésite aussi à l’integrer à plus bas niveau, il me semble qu’avec les nouvelles technos ça aurait peut être du sens, mais par expérience on perd vite du temps avec.
Pour les tests exploratoires fait par l’équipe (pouvant inclure un QA), j’aurais tendance à les garder en dehors du board, à faire « quand on a le temps », sauf si l’équipe n’a jamais de temps.
Je ne parle ici que des tests qui peuvent être fait dans l’equipe, ça n’empêche pas en parallèle d’avoir des tests manuels par des utilisateurs par exemple.

Quelles sont vos pratiques?

Tan · Avril 6, 2023, 7:49

Salut,

(Attention, dans tout ce qui suit, « Test » signifie « Auto Test exécuté dans le pipeline d’intégration ». Je ne parle pas de test manuel).

Rendre les tests visibles dans le backlog peut être utile sur une équipe débutante qui n’a pas l’habitude d’écrire des tests systématique. Au moins avec un ticket « écrire les tests », elle en écrira.

Cependant, cela peut avoir un effet pervers. Le ticket « test » est toujours celui qui saute en période de rush, on ship donc des features sans auto-test, ce qui se paye très cher plus tard

Pour moi, le test fait partie intégrante du développement. On ne développe pas une feature et quand elle est prête, hop, on passe à la phase de test (ça c’est du cyle en V )

Lorsque tu vas changer tes pneus, le devis contient « Pneu, main d’oeuvre ». Il n’y a pas le détail de:

Mettre la voiture sur le pont
Démonter les roue
Changer le pneu
Équilibrage
Remontage du pneu
Ajustement de la pression

Quand on chiffre un dev à 10pt, ça ne veut pas dire « 7pt de dev et 3pt de test et le PO va faire sauter les tests pour gagner du temps ». Ça veut dire 10pt. À prendre ou à laisser.

Les Story « Tests » peuvent avoir un intérêt dans des cas très précis. Par ex, on commence à avoir des problèmes de perf, mais l’infrastructure n’est pas adaptée à faire des tests de perf. On peut donc ouvrir une story du style :

« As a developper, I want a dedicated benchmark machine and a test framework in order to do automatic performance tests ».

Donc voilà. Pour moi, mettre explicitement des tickets « Test » entretien l’idée que le dev et le test sont deux activités distinctes.

Si ça t’intéressé, j’ai écrit un article sur les tests et leur valeur ajouté, tiré d’une formation qu’on avait suivie :

Samuel_Abiassi · Avril 6, 2023, 8:13

To have a high net value, a test should:

Have a high probability of detecting regressions

Have a low probability of creating a false positive

Be fast and easy to execute, both on Test and Dev environment

Have a low maintenance cost

Je rajouterais à ça qu’un bon test est avant tout un test qui s’assure qu’un use-case fonctionne. Parce que ce qu’on vend, ce sont des use-cases. Pas des class, ni des functions, ni des controllers, etc…

Moosh · Avril 6, 2023, 12:13

En marge de cette échange :

Amazon.fr - Le test en mode Agile - Moustier, Christophe - Livres

val · Avril 10, 2023, 12:57

Merci, le livre peut être intéressant aussi :).
Dans vos équipes vous faites quoi en terme de tests à part les tests unitaires back ? (bdd, end user…)

Samuel_Abiassi · Avril 10, 2023, 7:09

Test fonctionnel et end-to-end. On vend des use-cases donc la moindre des choses est de s’assurer que les use-cases marchent. Le reste relève du détail d’implémentation.

jplambert · Avril 10, 2023, 10:47

Salut à tous ! On va faire une vidéo sur le sujet

Samuel_Abiassi · Avril 10, 2023, 11:26

Je rajouterais que pour l’instant, y’a plus de preuves académiques que le TDD est néfaste pour la qualité architectural intrinsèque du code.

Ps: Je n’ai pas dis que le code marchait moins bien hein, simplement que l’architecture d’un code écrit en TDD est statistiquement plus mauvaise.

Tan · Avril 11, 2023, 7:41

Salut Samuel !

Tu as des sources là dessus ?

De mon expérience, le problème vient du fait que la plupart du temps, le dev s’arrête à « Ok, mes test sont vert, je ship comme ça ». Le TDD doit normalement s’accompagner d’une phase de refact une fois les test vert pour justement mettre l’archi au propre, ce qui rejoint les concepts d’Architecture Émergente/Agile.

BenjaminF · Avril 11, 2023, 8:15

Quand je regarde les sources académiques sur le TDD, la réponse est unanime : personne ne sait si réellement ça a un impact positif ou négatif sur le design. Il y a presque autant de pours que de contres.

Comme l’exprime cette étude :
For example, TDD was incorrectly accused of ignoring design while it was actually the developers who ignored the design but still presented their practice as TDD.

J’avais regardé il y a longtemps les nombreuses études sur XP et le TDD… Et autant de personnes contredisent les papiers des autres. Le biais est simple : « qu’est-ce que c’est vraiment le TDD ? » Beaucoup de (sous) pratiques du TDD existe. Ca me semble être difficile de placer le curseur, d’avoir des mesures réalistes, sur un sujet aussi large… Déjà quand tu as 2 grandes écoles qui se séparent, c’est encore plus difficile d’avoir un sujet académique sans biais dessus !

Samuel_Abiassi · Avril 11, 2023, 8:38

https://www.researchgate.net/publication/256848134_Effects_of_Test-Driven_Development_A_Comparative_Analysis_of_Empirical_Studies

Après, comme @BenjaminF , il y a plus d’études qui prouvent que l’efficacité de l’outil est plus relative qu’autre chose, mais même dans des études menées par des personnes pro-TDD comme celle que tu cites on aussi des observations comme celle là:

Another finding of my thesis was that it is extremely hard to put a
number (metric) on TDD (or for that matter any software development
technique) and try to evaluate it that way. The results will be almost always
questionable because they are just too many incontrollable variables. Taking
this into account, the critics of the strong claims that TDD produces better
code had a point. Nevertheless, I still see value in this kinds of research,
though, I just think that it has to be very carefully and thoroughly thought
through.

Ceci étant, les critiques sur le TDD sont en fait plus rapportés aux tests unitaires et l’architecture qui en découle. L’approche BDD de Dan North a pour elle le bénéfice qu’elle remet à plat l’intention première de Kent Beck, à savoir tester un use-case (où le unit est bien le use-case et pas une class).

Samuel_Abiassi · Avril 11, 2023, 8:45

Et puis parce que j’aime bien taclé l’autre réac’ de Martin, je trouve que l’approche de Dan North est beaucoup plus sensible sur pleins d’aspects : CUPID—for joyful coding - Dan North & Associates Ltd

Moosh · Avril 11, 2023, 11:00

Les tests, c’est comme les ceintures de sécurité et les assurances auto. C’est un gros gaspillage.
Les conducteurs n’ont qu’à conduire convenablement et les devs coder proprement.
Surtout si décide de prendre une assurance sur les attaques extraterrestres ou une ceinture pour sécuriser la route de secours.

Samuel_Abiassi · Avril 11, 2023, 11:02

C’est assez bizarre d’exprimer ça comme ça, non ?

Moosh · Avril 11, 2023, 11:16

Surement

D’autant plus qu’on ne sait pas où est le troll ou est le censé.

Le test, c’est un acte de vérification d’un élément attendu.
Si c’est attendu, pourquoi le tester ?

Je n’aime pas le raccourci « les (unit)tests c’est du gaspillage ».

Le gaspillage, c’est de mettre en place ou d’exécuter des tests avec un coût supérieur à l’impact du non-respect de ce qui est testé.

Tester c’est sécuriser le livrable.

Sécuriser c’est toujours générer un coût dont on aurait aimé se passer (quelle perte de temps de mettre un login pass sur un site, et cette double FA, à refaire tous les 15 jours aaaarrggh)

Samuel_Abiassi · Avril 11, 2023, 11:22

Ca va légèrement plus loin que ça malheureusement. L’approche TDD s’attend à ce qu’émerge des tests une architecture du code saine et efficiente. Dans les faits, si le TDD se focus sur les tests unitaires (et c’est là où se trouve le SI), elle a plutôt tendance à être contre-productive au regard d’une approche drivée par le domaine, l’analyse systémique et l’analyse des use-cases (BDD fait ça très bien). L’approche à sa création se plaçait orthogonalement vis-à-vis de ces pratiques et souhaitait éviter ce qu’ils ont appelé avec dédain le Big Design Up-Front.

Alexandre_Quercia · Avril 23, 2023, 4:10

Les tests doivent faire partie intégrante de tous les sujets. Il ne devrait pas avoir de tâches même technique disant « Ajouter les tests pour … ».

Leur seule visibilité est sur le board est dans la DoD.

La Définition de terminé contient

Il y a une preuve rapide, fiable et reproductible que le code fonctionne comme il se doit.
La structure du code est améliorée…

Mes pratiques

Travail avec le métier pour énoncer le comportement attendu.
Réalisation du comportement
Branchement du code écrit précédemment pour rendre ce qui a été écrit à l’étape « 1. » automatisé.
Dans une application avec plusieurs composants, il faut s’assurer que ces composants communiquent bien entre eux.
Un ou deux tests qui englobent tout le système.
Utilisation de l’ingéniosité humaine pour chercher des bugs, des failles de sécurité, … Les seuls tests manuels.

Annexe

Précision sur le Test-Driven Development (TDD)

TDD n’est pas une pratique de test, mais une discipline d’écriture du code.

Elle permet principalement de changer le code sans peur. Car cela construit une suite de tests dont on a confiance.
C’est une documentation parfaite pour les développeurs.
Cela permet de réduire le temps de débug
D’avoir une architecture de code découplé
C’est fun

La loi de Kent Beck

Faites d’abord fonctionner le code
Ensuite, nettoyez-le
Ensuite, si nécessaire, rendez-le rapide et petit.

Les mocks ou doublure de test

Ils sont seulement utilisés aux frontières d’architecture.

Le détail des pratiques de développement

1. Travail avec le métier pour énoncer le comportement attendu.

Pratiques : les 3 amigos, exemple mapping, Acceptance Tests Driven Development (ATDD), Behavior Driven Development (BDD)
Langages : Gherkin « given/when/then », un simple tableau
Type de tests : « Component tests »
Résultat : La description du comportement attendu de l’application compréhensible par le métier. Cela permet d’avoir un vocabulaire partagé.

2. Réalisation du comportement

Pratiques : Test-Driven Development (TDD) & Correction de la structure du code
Langages : Le langage de programmation du code
Type de tests : « Unit tests »
Résultat : Du code qui est facile à lire. Qui expose une interface utilisable par le « when ». Un filet de sécurité dans le domaine de définition connu. Les détails de l’implémentation sont ignorés, car les comportements sont testés à travers l’interface public du cas d’usage.
Fréquence d’exécution : Durant le développement. Au moins 2 fois / minutes.

3. Branchement du code écrit précédemment pour rendre ce qui a été écrit à l’étape « 1. » Automatiser.

Résultat : La réalisation avance du comportement attendu par le métier.
Cela peut être monté comme information d’avancement, combien de pourcentage des scénarios sont terminés.
Fréquence d’exécution : Durant le développement. Au moins 1 fois / heure

4. Dans une application avec plusieurs composants, il faut s’assurer que ces composants communiquent bien entre eux.

Pratiques : Test-Driven Development (TDD) & Correction de la structure du code
Langages : Le langage de programmation du code
Type de tests : « Integration tests »
Résultat : Un filet de sécurité qui assure la bonne communication en composant, la chorégraphie. Aucuns règle métier est testée ici. On y trouve les tests de performance.
Fréquence d’exécution : Dans l’intégration continue. Ou périodiquement.

5. Un ou deux tests qui englobent tout le système.

Type de tests : « System tests »
Résultat : Un filet de sécurité de bout en bout qui assure que les branchements sont bons depuis l’interface utilisateur à la base de données. Ici pas de mock.
Fréquence d’exécution : Au moins une fois par semaine. Si possible avant chaque déploiement en prod.

6. Utilisation de l’ingéniosité humaine pour chercher des bugs, des failles de sécurité, … Les seuls tests manuels.

Type de tests : « Exploratory »
Fréquence d’exécution : 1 ou 2 fois par an

Samuel_Abiassi · Avril 23, 2023, 4:17

Ah bon…?

Gosh… pas la pyramide, par pitié T_T

Alexandre_Quercia · Avril 23, 2023, 4:25

Quel point t’a surpris ?

@Samuel_Abiassi as-tu un autre schéma permettant d’illustrer ? Actuellement, je n’ai pas mieux.

Samuel_Abiassi · Avril 23, 2023, 4:55

Ouais… si t’es certains à 100% que l’interface n’est pas susceptible de changer. Dans le cas contraire, c’est 0% utile.

Sur quel critère on se base pour dire ça ?

Des preuves factuels sur ce point là ?

Le code doit être couplé. Mais aux bons endroits, genre au runtime dans un use-case qui devient un context.

Tu remarqueras aussi que DCI est plus proche de ces façons de faire…