Discussion :

[transgohan]

C'est quand même ton contexte à toi qui est une exception, donc c'est bien à toi de le préciser !

L'informatique est tellement vaste et complexe qu'on pourrait trouver une exception dans chaque travail des bénévoles de ce forum.
Donc si à chacun de mes posts je dois rédiger trois gros paragraphes pour planter le contexte j'ai pas fini, et en plus je suis sûr que personne ne me lirait.

A voir si la prochaine fois que tu me lis tu te souviendras de notre échange pour ne pas prendre mes propos comme étant un cas général et non un récapitulatif de mon expérience.
D'ailleurs pour répondre au sujet on demande bien notre expérience (un avis se base toujours là dessus) et non sortir un cas d'étude.

[MikeRowSoft]

Des deux précédents commentaires résulte la notion de dev seul et dev en équipe...

La chance de laisser des bogues (avant phase test) est plus grandes dans quelles cas ?

En dev seul, vous pensez que recompiler et tester (unitaire/procédure) en cours de dev est monnaie courante ?

Il y a plus de chance de laisser des bogues et/ou compilés souvent en Back-End ? Front-End (sans outil de design assisté visuellement) ? Full Stack ?

[Kikuts]

Le testeur ne peut être qu'un développeur qui programme les tests à effectuer et corrige les tests existants. Le test manuel coute beaucoup trop cher et est beaucoup moins fiable.

Je trouve ta réponse un peu trop stricte ou alors pas assez complète.

Effectivement, la couche d'accès à la DB, tout ce qui est logique métier etc s'automatise et je pense que ça revient moins cher que de faire tester manuellement le soft.

Par ailleurs, je vois très très mal un développeur réaliser les tests d'un logiciel de compta super pointue à moins qu'il possède une formation d'expert comptable... Pour avoir bosser sur un projet comme ça je te jure que ce n'est pas évident car si tu as la chance d'avoir des cahiers des charges complets, qui n'évolueront pas et qui couvre tous les besoins et les non besoins, ce n'est clairement pas la majorité des cas et ça ne signifie pas que tu as compris le métier à 100%. Comme on dit, à chacun son métier.

Ensuite, tu parles de coûts. Alors c'est simple : je ne connais personne capable d'écrire des UI tests multi plateformes qui ne casseront pas, qui ne pénaliseront pas toute la chaine : un UI test qui est cassé empêche toute Pull Request. Du coup tu pénalises tous les développeurs. Ces derniers vont devoir créer une branche, faire un tas de manip pour contourner le problème. De plus, il va falloir corriger le problème puis tout rebasculer, vérifier que tout est bon. Tout ce temps passé est vite énorme. Ca te couvre le prix de plusieurs testeurs manuel à l'année. Si tu externalises les tests dans un pays de l'est, tu peux t'offrir 10 testeurs pour le prix d'un UI test :p

Qui réalise les UI tests ? Des développeurs.
Qui n'aiment pas tester / écrire des tests ? Beaucoup de développeurs !
Donc ça ne m'étonnerait même pas que la productivité d'un développeur chute lorsqu'il doit réaliser moulte tests unitaires.
Pendant que tu codes un UI test, tu n'avances pas sur les features, le projet stagne en qq sorte (du point de vue de l'utilisateur en tout cas. Même si de notre point de vue de développeur, on avance, on est plus solide etc !)
Du coup, pour compenser ça, tu vas embaucher d'autres développeurs (peut être moins bon, qui écriront du moins bon code / de moins bon tests unitaires). C'est le serpent qui se mord la queue

Deuxième remarque : pendant que je réalise des UI tests que des collègues casseront tôt ou tard / pendant que je fixe mes UI tests qui cassent, je ne développe pas, je ne fixe pas de bug. Parfois faire un UI test va m'obliger à changer mon archi juste pour pouvoir mocker des données. Il va falloir faire une réunion avec le chef de projet, chef technique etc, justifier tous ça, écrire des tonnes de mails etc. Alors pour tester que le bouton "à propos" affiche bien un popup avec le nom de l'entreprise, ça peut vite couter un mois. Ah merde l'iphone X est sorti entre temps avec des nouveaux ratio... Certains de mes UI tests ne passent plus sur iOS... Zut de zut !!! Est-ce qu'ils fonctionnent encore sur les autres plateformes ? Oui ? Non ? Pourquoi ? Vont-ils casser ? Bon ça m'a saoulé, je désactive les tests dans mon intégration continue "temporairement" : je les "fixerai"... "plus tard" !

Autre exemple : tu as une appli Android, une appli iOS, un site web, un client lourd UWP pour l'admin. Je pense qu'il y a vite moyen que le coût des tests unitaires dépassent le coûts du projet en développement.

Les tests c'est bien quand ça cible des path critiques, ce qui a sous le capot de l'appli.
De plus, tout se test : "quand y en a plus, y en a encore" c'est une bataille sans fin !

Pour finir, je dirais que rien ne remplacera un testeur humain non développeur. Il testera les choses différemment, peut être il va galérer à tester telle ou telle fonctionnalité, manquera d'info etc.
Ces retours sont parfois presque plus important que de trouver un petit bug
Car tester un logiciel, c'est plus que vérifier que ça ne crash pas ou que le résultat est bon ! C'est aussi s'assurer que les wordings sont correctes, que la charte graphique est respectée, que l'appli respecte les normes high contrast (d'ailleurs je meure d'envie de connaître le % de site web High Contrast Compliant ), qu'il est utilisable avec la loupe, le narrateur etc. Oui oui, ce sont des choses qui peuvent être obligatoire (exemple : il me semble qu'une école ne peut acheter des softs qui ne respectent pas ces conditions)

De toute façon, tester, c'est douter

[MikeRowSoft]

Les rares expériences de dev en équipe que j'ai eu, nous rassemblions les .cpp et .h utiles dans un seul projet, il y avait donc des préposé à la tâche de rassemblement/construction du projet final... Pourtant avec C++ Builder chaque parti avait son propre interface et même du code partagé avec GCC sous Linux.

Côté application EDI, pas de fusion de projets en un seul ou même une hiérarchie ordonnée lors de la fusion de sous projet... (Nous n'avons jamais utilisé ou cherché en vrai, mais tout les codes sources sont toujours réutilisables.)

En binôme il arrivait rarement qu'il y en ait un qui implémente et l'autre qui met des commentaires... Cela chacun son tour, nous nous répartissions les tâches... Celui qui rédigeais les commentaires scrutait aussi le code en cours d'implémentation...

Je ne dis pas qu'avec 32 To de codes sources à compiler en une fois que nous aurions fait pareil...
Je présume que si le développeur A a besoin d'une parti du code source du développeur B, que son code source ne sera valide pour compilation et débogage en cours de dev que si celui de son collègue est "compilable" et plus ou moins correct/cohérent à un instant T... Donc les changements de "modèles" (structure de class, fonctions, etc...) sont encore pire...

[psychadelic]

Je vois pas trop l’intérêt de tester du code si derrière aucun budget pour "corriger" n'est prévu...

Ou alors on est dans un processus de validation de code, et la c'est binaire : acceptable / refusé.
Bien sur tout dépend aussi de la tolérance de ce qui peut être considéré comme acceptable.

D'un autre coté, si on commence à rendre responsable de leur code les développeurs, alors il faudrait aussi reconnaître leur droit d'auteur sur ce qu'ils produisent, avec les intérêts financiers que cela représente.
Parce que le beurre, l'argent du beurre, et sauter la crémière, on à déjà donné dans ce métier.

Produire du bon code, ça prends du temps, et de la concentration. Tester du code, ça prend du temps.Documenter du code ça prend du temps.

En général les boites paient au plus juste pour le temps de développement (dans une ambiance de presse citron), et nada pour tout le reste.

[kilroyFR]

Dans ma boite chaque developpeur est responsable des tests (unitaires et/ou automatisés) sur le code qu'il developpe ou sur lequel ou il fait de la maintenance.
Generalement si un pb genant arrive en PROD c'est lettre d'avertissement pour non qualité car la plupart du temps le client exige des penalités ou en profite pour demander a se faire offrir des fonctionnalités en echange... ca calme.
Apres sur les tests unitaires je trouve que bien souvent quand je fais de la relecture croisée de code, les tests sont assez bidons et simplistes.
Les tests d'intégration de scenarios complets (use case) sont plus pertinents pour moi car c'est la réalité de ce qui se passe sur le terrain. Je prefere passer plus de temps sur ce genre de tests que sur les tests unitaires proprement dits.

Apres je suis d'accord qu'un oeil exterieur (ne venant pas d'un dev) est essentiel car fonctionnellement le dev peut prendre des raccourcis (suite choix technique ou autre) qui remplissent la fonction mais pas de la meilleure maniere.
Personnellement je prefere qu'un non informaticien teste mes logiciels car il aura un oeil different d'un developpeur et aura certainement une approche plus pragmatique et fonctionnelle.
Chez nous on a des dev qui sont en mode geek, ne s'interesse qu'a la techno pour la techno alors que ce n'est pas une fin en soi.
J'ai encore le souvenir d'un gars (validation systeme) qui trouvait trop de bugs (il y a des gens doués pour ça) sur une appli de guichet et du coup ralentissait les equipes de dev qui se plaignaient qu'il etait source de perturbations car il 'faisait chier avec ses faits techniques' (hallucinant non ?). Eh bien ils ont reussi a le faire virer (à tort bien sur) car il mettait en retard le projet. Bon les pbs cachés pendant les devs se sont revelés bien sur de maniere plus catastrophique en PROD devant le client.

Les tests automatisés sont réalisés macroscopiquement sur les fonctionnalités à developper mais ca n'empeche pas d'avoir des bugs regulierement en PROD.
Du coup plus de la moitié des tests automatisés que l'on va coder sont relatifs a des tests de non regression qui n'avaient pas ete codés/identifiés en phase de dev (bref les cas particuliers/exception/cas tordus).
On a pourtant des couvertures de code tres correctes mais il n'empeche que c'est surprenant comme quoi meme si on croit avoir pensé a tout, l'experience du terrain révèle toujours nb de pb non identifiés.
Apres sur le codage des tests unitaire/intégration en general, avec du recul je vois que c'est surtout pour des structures ou le turn over est elevé que c'est important.
Sur des projets ou logiciels ou ce sont les memes personnes qui gerent depuis des années le nb de bug/fiabilité n'est pas plus mauvaise que ceux qui passent leur journée a coder des tests unitaires. Je suis plutot de la vieille ecole (celle ou les test unitaires n'etaient pas automatisés). Avec les années je m'y suis mis forcement car utile mais quand je vois le code que je faisais il y a 20 ans, il n'y avait pas beaucoup d'erreur au final (on passait plus de temps sur le fonctionnel a blinder tout ca). En mode agile le plus souvent on passe notre temps a faire/defaire/refaire au gre des demandes clients qui en profitent pour changer d'avis etc a tour de bras. C'est la flexibilité pour lui certes.
Aujourd'hui on est souvent en mode de dev ou il faut tout faire vite et du coup les tests automatisés permettent d'assurer un minimum de qualité meme si on est amené a changer d'equipe de dev regulierement ou sous traiter off shore comme c'est le cas dans ma boite (objectif : 0 dev en France en 2018) !

[kilroyFR]

D'un autre coté, si on commence à rendre responsable de leur code les développeurs, alors il faudrait aussi reconnaître leur droit d'auteur sur ce qu'ils produisent, avec les intérêts financiers que cela représente.
Parce que le beurre, l'argent du beurre, et sauter la crémière, on à déjà donné dans ce métier.

Produire du bon code, ça prends du temps, et de la concentration. Tester du code, ça prend du temps.Documenter du code ça prend du temps.

En général les boites paient au plus juste pour le temps de développement (dans une ambiance de presse citron), et nada pour tout le reste.

Le developpeur est percu en france comme l'ouvrier des temps modernes (en col blanc certes); remplacable, "pisseur de code"; quant aux responsabilités, generalement tu recuperes les emmerdes mais pas la gratification (pour resumer tu te feras taper dessus si tu n'as pas respecté les process et les delais; mais n'attend rien si ca marche, apres tout tu as ete payé pour ca non ?)
Tellement remplacable que les boites ne se genent plus d'externaliser les devs (ca marche chez nous depuis 1,5 ans). Pour un dev de 1000 h, qu'est ce qui coute moins cher ? le faire en france ou le faire a des ingé de l'ile maurice avec un taux horaire 4 fois moins elevé ? techniquement ils ne sont pas plus mauvais que les metropolitains; fonctionnellement ils apprennent vite car ont l'avantage de parler la meme langue).

Le "bon code" est une notion d'informaticien qui n'a aucun sens chez un manager
(il veut que ca fasse la fonction vendue au client au moindre cout - apres que ce soit codé ou pas selon l'etat de l'art (qui change tous les ans a chaque nouveau concept idée a la mode) il s'en fout royalement. En presque 30 ans de boite j'en ai vu passer des technos et autres concepts, tous plus revolutionnaires que les precedents; pourtant en 2017 on passe plus de temps pour coder les logiciels (la partie IHM explose litteralement tous nos budgets et on ne code pas des jeux videos mais de simples boutons/grilles/formulaires !), la qualité n'est pas meilleure (malgré la batterie de tests automatisées); les devs font de plus en plus les apprentis sorciers en "jouant" avec les dernieres technos a la mode (sans se soucier de la perennité/pertinence car c'est souvent jugé "c'est genial !")...

Si tu veux toucher des droits d'auteur la solution est simple, developpe des logiciels pour ton compte et revend les a ta boite (ou d'autres) ou depose un brevet.
Je l'ai fais pour 2 logiciels dans ma boite et un brevet. Les logiciels ont ete developpés pendant mes loisirs/WE/nuits, mais utilisés en interne par une grand majorité de devs, c'etait donc plus pertinent pour la boite de m'acheter les sources que d'acheter un logiciel du commerce autre qui ne prenait pas en compte les besoins particuliers de ma boite.
Ca demande un investissement et des sacrifices particuliers mais on n'a rien sans rien. Tout ce que tu produis dans tes heures de boulot ne t'appartient pas. Par contre le reste OUI.

[LSMetag]

Il y a le testing de la part des développeurs (certes automatisé et manuel mais souvent basique), mais surtout la recette côté client, qui connaît mieux le métier, et qui est plus doué pour trouver des cas d'utilisation tordus et des erreurs fonctionnelles.

Nous avons bien vu que les tests des développeurs seuls étaient insuffisants, et que certains clients ne faisaient pas correctement leur recette (quand ils ne passaient pas directement du dev à la prod) et nous avons maintenant un testeur attitré qui fait la passerelle. Ce testeur est un ancien développeur peu expérimenté (1 an ou 2) qui a voulu passer dans le fonctionnel. Il faut être très méticuleux, savoir s'imprégner du métier et avoir le sens du contact. Il n'effectue que des tests manuels. Depuis qu'on l'a on ne peut plus s'en passer.

C'est aussi un tremplin pour passer chef de projet puisque la personne discute beaucoup avec les clients et les développeurs, fait des rapports, participe aux livraisons,... Après 1 an, cette personne cumule les rôles de testeur et chef de projet.

Il y a 2 écoles :

1) La nôtre : On fidélise les clients (et faisons marcher le bouche à oreille), certes en étant plus cher ou en prenant du retard (nous travaillons en méthode agile), mais nos livraisons sont de qualité, performantes et robustes. Elles ne requierent que peu de TMA, que l'on effectue nous-même. Les clients fidélisés nous commandent d'autres projets, et d'autres clients arrivent. Nous avons également carte blanche sur la technique, qui nous permet de rester à la pointe.

2) Les prestations sont faites dans un soucis de coût minimum et de rapidité. En gros un appel d'offre par prestation, on prend le moins cher (qui n'est pas forcément en France). Les résultats sont souvent médiocres, testés à la va-vite par les développeurs, puis des mois plus tard par une MOE puis une MOA. Les SS2I (qui ne font souvent que de la TMA) s'enchaînent ensuite, et se battent pour ne pas être remplacées. C'est comme monter une maison pas cher et appeler sans cesse SOS Plomberie. C'est le mode de fonctionnement de la SNCF par exemple. Tu fais ce qu'on te dit à un instant t (tu es mal vu si tu objectes qu'il va y avoir des problèmes), une fois ta tâche terminée, on relance un appel d'offre. Là bas, il n'y a pratiquement QUE de la TMA active, et ce pendant des années et des années.
En tant que client, on voit les résultats...

[Luckyluke34]

Ca dépend tellement du contexte.

Une agence web qui ne fait que des sites pour de la com' ou de l'évènementiel n'en a rien à carrer d'avoir des personnes dédiées à la QA.

Une boîte qui développe des systèmes pour l'aéronautique aura son département QA ou plusieurs personnes QA embarquées dans chaque équipe projet.

Un grand acteur du web avec un seul ou deux produits phares et des cycles de livraison très courts peut se permettre de déléguer toute la QA aux développeurs, parce qu'ils connaissent le métier sur le bout des doigts, que les retours de bugs utilisateurs sont nombreux voire automatisés et le temps entre signalement et bugfix est minime.

En érigeant un exemple en modèle universel on se fourvoie totalement...

[LSMetag]

Ca dépend tellement du contexte.

Une agence web qui ne fait que des sites pour de la com' ou de l'évènementiel n'en a rien à carrer d'avoir des personnes dédiées à la QA.

Une boîte qui développe des systèmes pour l'aéronautique aura son département QA ou plusieurs personnes QA embarquées dans chaque équipe projet.

Un grand acteur du web avec un seul ou deux produits phares et des cycles de livraison très courts peut se permettre de déléguer toute la QA aux développeurs, parce qu'ils connaissent le métier sur le bout des doigts, que les retours de bugs utilisateurs sont nombreux voire automatisés et le temps entre signalement et bugfix est minime.

En érigeant un exemple en modèle universel on se fourvoie totalement...

Pour le grand acteur du web, tu veux dire que comme les cycles sont courts, on peut se permettre de faire des releases bugguées ?

[Luckyluke34]

Pour le grand acteur du web, tu veux dire que comme les cycles sont courts, on peut se permettre de faire des releases bugguées ?

Tu penses à qui ?

Oui et non, comme évoqué dans l'article il y a souvent une plus grande responsabilisation des développeurs sur la qualité et tout un ensemble de techniques autour (chaos monkeys, feature toggles, A/B testing...) ce qui limite les bugs ou du moins ceux visibles par la majorité des utilisateurs. Et quand il y en a, le grand nombre de gens qui vont le signaler et le faible impact économique (c'est Mme Michu, pas une boîte qui va perdre des millions à cause de ton bug) font que c'est vite repéré et pas grave.

[LSMetag]

Tu penses à qui ?

Oui et non, comme évoqué dans l'article il y a souvent une plus grande responsabilisation des développeurs sur la qualité et tout un ensemble de techniques autour (chaos monkeys, feature toggles, A/B testing...) ce qui limite les bugs ou du moins ceux visibles par la majorité des utilisateurs. Et quand il y en a, le grand nombre de gens qui vont le signaler et le faible impact économique (c'est Mme Michu, pas une boîte qui va perdre des millions à cause de ton bug) font que c'est vite repéré et pas grave.

Faut juste que ça ne soit pas du B2B. Nos clients ne sont que des entreprises/administrations donc là... Notre testeur vient de trouver un gros bug en catastrophe juste avant la livraison. Je viens de le corriger. Ouf ! Tu as beau tester, tu teste selon ta manière d'utiliser la fonctionnalité. Une autre manipulation, et ça peut être le drame.

Pour en revenir à la SNCF (vous savez que j'en garde un magnifique souvenir ^^'), je me souviens d'un méchant bug arrivé en prod. Quand une personne lançait l'appli (critique), tout se passait bien (en apparence) pour elle, mais les dizaines d'autres personnes utilisant cette appli se retrouvaient bloquées, avec des messages d'erreur à chaque écran. La première personne qui lançait l'appli et n'avait pas d'erreur perdait toutes ses modifications quand elle la quittait. Tout ça à cause d'une erreur effectuée par l'architecte qui avait mis un "return" dans une transaction (dans le gestionnaire de transactions pour être exact) !

Un test avant la livraison, après le merge, et ça se serait vu, et il n'y aurait pas eu de livraison, la journée et demi de paralysie aurait pu être évitée (surtout que l'architecte s'était barré)... Enfin bon, on ne nous laissait pas non plus le temps de faire des tests automatisés...

[Luckyluke34]

Faut juste que ça ne soit pas du B2B. Nos clients ne sont que des entreprises/administrations donc là... Notre testeur vient de trouver un gros bug en catastrophe juste avant la livraison. Je viens de le corriger. Ouf !

+1, on a la même chose de temps en temps chez nous. Pour ce type de boîte, interpréter cet article comme si c'était la vérité révélée sans tenir compte du contexte est dangereux.

[Marco46]

Je trouve ta réponse un peu trop stricte ou alors pas assez complète.

Un peu trop stricte moui non je trouve pas. Pour le pas assez complète c'est que j'ai du boulot

Par ailleurs, je vois très très mal un développeur réaliser les tests d'un logiciel de compta super pointue à moins qu'il possède une formation d'expert comptable...

Comment pourrait-il le développer dans ce cas ? Tu comprends l'absurdité de la chose ? S'il ne comprend pas assez le métier pour le tester il ne peut pas le développer. C'est absolument mécanique.

Pour avoir bosser sur un projet comme ça je te jure que ce n'est pas évident car si tu as la chance d'avoir des cahiers des charges complets, qui n'évolueront pas et qui couvre tous les besoins et les non besoins, ce n'est clairement pas la majorité des cas et ça ne signifie pas que tu as compris le métier à 100%. Comme on dit, à chacun son métier.

Si tu ne comprends pas le métier tu ne peux pas développer. Faut être clair. Ah si pardon tu peux développer n'importe quoi, mais ce n'est pas ce que j'appelle développer

Ensuite, tu parles de coûts. Alors c'est simple : je ne connais personne capable d'écrire des UI tests multi plateformes qui ne casseront pas, qui ne pénaliseront pas toute la chaine : un UI test qui est cassé empêche toute Pull Request. Du coup tu pénalises tous les développeurs. Ces derniers vont devoir créer une branche, faire un tas de manip pour contourner le problème. De plus, il va falloir corriger le problème puis tout rebasculer, vérifier que tout est bon. Tout ce temps passé est vite énorme. Ca te couvre le prix de plusieurs testeurs manuel à l'année. Si tu externalises les tests dans un pays de l'est, tu peux t'offrir 10 testeurs pour le prix d'un UI test :p

C'est ta pipeline qui est mauvaise. Les tests doivent s'exécuter d'abord sur la machine de dev. Si les tests d'UI sont trop longs et contraignants à exécuter sur la machine de dev alors tu dois adapter la pipeline :
- exit le continuous deployment.
- ta pipe de CI n'exécute pas les tests e2e qui sont à exécuter dans une autre pipe.

En clair si l'exécution de certains types de tests sont trop contraignants il faut les sortir du pipe et dans ce cas effectivement tu dois rajouter des opérations manuelles, soit pour exécuter ces tests, soit pour tester manuellement ce qui n'est pas a

Qui réalise les UI tests ? Des développeurs.
Qui n'aiment pas tester / écrire des tests ? Beaucoup de développeurs !

Il faut adapter le recrutement, les mauvais qui veulent pas tester il ne faut pas les recruter.

Donc ça ne m'étonnerait même pas que la productivité d'un développeur chute lorsqu'il doit réaliser moulte tests unitaires.

Pendant que tu codes un UI test, tu n'avances pas sur les features, le projet stagne en qq sorte (du point de vue de l'utilisateur en tout cas. Même si de notre point de vue de développeur, on avance, on est plus solide etc !)
Du coup, pour compenser ça, tu vas embaucher d'autres développeurs (peut être moins bon, qui écriront du moins bon code / de moins bon tests unitaires). C'est le serpent qui se mord la queue

Ça c'est pareil c'est comme l'argument des couts ça dépend comment on compte. 80% du cout d'un logiciel est dans sa maintenance.

A quoi ça sert de développer des features si tu es incapable de détecter les régressions ou si le cout de détection c'est 3 semaines de QA ?

Une feature est terminée quand elle est en prod, pas quand le développeur pousse son code sur le repo central.

Deuxième remarque : pendant que je réalise des UI tests que des collègues casseront tôt ou tard / pendant que je fixe mes UI tests qui cassent, je ne développe pas, je ne fixe pas de bug. Parfois faire un UI test va m'obliger à changer mon archi juste pour pouvoir mocker des données. Il va falloir faire une réunion avec le chef de projet, chef technique etc, justifier tous ça, écrire des tonnes de mails etc. Alors pour tester que le bouton "à propos" affiche bien un popup avec le nom de l'entreprise, ça peut vite couter un mois. Ah merde l'iphone X est sorti entre temps avec des nouveaux ratio... Certains de mes UI tests ne passent plus sur iOS... Zut de zut !!! Est-ce qu'ils fonctionnent encore sur les autres plateformes ? Oui ? Non ? Pourquoi ? Vont-ils casser ? Bon ça m'a saoulé, je désactive les tests dans mon intégration continue "temporairement" : je les "fixerai"... "plus tard" !

Je crois que tu mélanges un peu tout. Dans ton propos il y a de mauvaises pratiques combinées à du cross browsing testing qui dont l'utilité est de plus en plus discutable, combiné à une organisation défaillante (il te faut faire des réunions pour mocker des données ? WTF ?!?).

Les tests qui doivent absolument être automatisés :
- unitaires, avec la couverture la plus importante possible.
- intégration, couvrir les happy path des endpoints (cas OK et au moins un cas KO)
- fonctionnels (e2e), couvrir les happy path

Et ensuite rajouter des tests au besoin et du type nécessaire identifiés les noms des tickets ouverts afin de vérifier qu'on ne réouvre pas des tickets.

Si tu fais ça tu couvres 95% de tes problèmes.

Je parle pas de jouer à pousse pixel en fonction du device, c'est vraiment une autre histoire et les technos ne sont pas du tout mature sur ce sujet.

Autre exemple : tu as une appli Android, une appli iOS, un site web, un client lourd UWP pour l'admin. Je pense qu'il y a vite moyen que le coût des tests unitaires dépassent le coûts du projet en développement.

Je vois pas le rapport entre les tests muti-devices et les TU.

Par ailleurs le cout de l'automatisation des tests est inclus dans le cout des devs, formulé autrement : "un code non testé est un code non livré" tout simplement parce que ça coute BEAUCOUP moins cher si on compte sur l'ensemble de la durée de vie du projet.

Les tests c'est bien quand ça cible des path critiques, ce qui a sous le capot de l'appli.
De plus, tout se test : "quand y en a plus, y en a encore" c'est une bataille sans fin !

Les happy path c'est déjà pas mal !

Pour finir, je dirais que rien ne remplacera un testeur humain non développeur. Il testera les choses différemment, peut être il va galérer à tester telle ou telle fonctionnalité, manquera d'info etc.
Ces retours sont parfois presque plus important que de trouver un petit bug

J'ai jamais dit que les testeurs humains étaient inutiles, j'ai dit qu'il fallait automatiser au maximum.

Car tester un logiciel, c'est plus que vérifier que ça ne crash pas ou que le résultat est bon ! C'est aussi s'assurer que les wordings sont correctes, que la charte graphique est respectée, que l'appli respecte les normes high contrast (d'ailleurs je meure d'envie de connaître le % de site web High Contrast Compliant ), qu'il est utilisable avec la loupe, le narrateur etc. Oui oui, ce sont des choses qui peuvent être obligatoire (exemple : il me semble qu'une école ne peut acheter des softs qui ne respectent pas ces conditions)

Tu parles beaucoup de concepts qui sont encore à l'heure actuelle très difficilement automatisable, tout ce qui touche au design de l'UI. A part faire du screenshot diffing je vois pas trop. C'est pas encore top. Mais si tu élimines déjà 90% des problèmes de logique métier t'as déjà fait un bon bout de chemin.

[LSMetag]

J'ai jamais dit que les testeurs humains étaient inutiles, j'ai dit qu'il fallait automatiser au maximum.

En fait les tests unitaires c'est un peu le sommet de l'Iceberg dans des applications à UI. C'est là qu'on a vraiment besoin de testeurs humains ! Quand je parlais d'applis à centaines d'écrans (formulaires dynamiques), en MVVM-CROSS (3 applis en fait), notre testeur était là pour faire planter l'appli avec un ordre de clics particulier, ou créer des méga effets de bord avec une saisie pourrie malencontreusement autorisée ^^. Et ce sur chacune des versions ^^.

[Luckyluke34]

Attention au terme test unitaire qui peut vouloir dire un test manuel dans le monde de la QA, et un test auto chez les devs. Je pense que c'est de là que vient une partie de la méprise sur ce que Kikuts disait.

Sinon chez nous les tests end-to-end (UI) sont réalisés par la QA dans un process de travail à part, hors intégration continue (temps d'exécution oblige). Dedans il y a de l'automatisé et de l'humain aussi, car certains bugs sont complexes à recréer/débusquer et l'expérience du testeur n'a pour l'instant pas d'équivalent strict dans le monde des machines.

[cedric57]

J'ai travaillé dans 8 entreprises et j'ai découvert la chose suivante.
1) Les entreprises font des tests poussés sur les projets très critiques (vie en danger si bug). Par tests poussés, je parle de test par robots, tests unitaires ou encore test par des équipes de testeur.
2) Dans la majorité des cas, si le projet n'est pas critique, les tests ne sont alors pas fait sérieusement car le travail du développeur est souvent jugé à court terme. Or avoir une bonne campagne de tests unitaires et de tests utilisateurs n'est pas rentable à court terme. Il faut par exemple un an de développement.
3) Quand on a une mauvaise conception. Qu'on fasse des tests ou de la doc…le développement sera difficile. Quand le contexte change trop avec le temps (très courant en entreprise), une conception qui était bonne au début peut devenir mauvaise. => Dans ce cas une réécriture d'une partie de l'application est nécessaire (voire une réécriture complète).
4) Chaque cas est différent et à chaque observation que je fais on peut trouver une exception

Sinon perso moi avec mon entreprise que je viens de créer, je compte:
1) Me contenter de tests de développeurs / utilisateurs pour les petites applications (moins de 5000 lignes de code…ou alors application non critique où l'on peut corriger les bugs ou jour le jour).
2) Pour les plus grosses applications, je compte proposer un développement en binôme (quand j'aurai le budget pour embaucher un deuxième développeur!). L'un développera l'application. L'autre développera des tests (tests unitaires…tests sur des données…voire tests par robots dans environnement simulé quand possible). Chacun fera régulièrement des revus du code de l'autre.

[Marco46]

Tiens en passant puisqu'on parle de tests je vous invite à check cypress.io qui est une vraie avancée majeure dans le tests d'UI web. La lib a été open sourcée le mois dernier, c'est simplement une tuerie !

[MikeRowSoft]

J’oublierai jamais mon premier stage de Dev, passage à l'€ et cohabitation avec l'ancienne monnaie. Aucune chance de laisser de bug autre qu'algorithmique. Je ne connaissais aucune méthode de test. Et il fallait flashez le firmware/kernel pour y mettre le binaire compilé conforme aux besoins...
Les tests que j'ai effectué avec le langage proposé, je réutiliserai des méthodes similaires avec les langages C ou Assembleur. Par contre l'orienté objets, je fais différemment... Principalement parce que la "littérature" en POO est beaucoup plus longue à lire...

Un ROC et pas mal de monde perdait son travail... Je suppose que cela a finalement eu lieu...

[koyosama]

Il y a une partie des tests qui est souvent réalisé par un développeur, comme les tests unitaires par exemple.
Après si on parle de test du produit final, forcément c'est mieux de passer par des utilisateurs...

Franchement, les tests unitaires c'est la chose obligatoire. Ya même pas d'excuse pour ça. Le fonctionnel devrait être au coeur de la programmation et arrêter de faire des fonction qui fait 10000 trucs.
Un fonction un truc et il le fait bien, c'est très facile à corriger et tester. L'article parle du test d'un logiciel. Après je trouve le TDD limité quand le BDD est mieux pour ce cas là.

On n'ose pas le dire mais je vais le dire. C'est juste que nos entreprises, n'ont pas thunes pour laisser le temps de faire des codes reviews, des tests unitaires.
Tester c'est une reflexion à part, le faire soi-même n'est pas le plus qualicatif que si tu combinais plus que toi, ce serait plus efficaces.

Check cette vidéo.

Croire que le développeur est le meilleur reviewver quand un oeil externe est meilleur. Le développeur sera bon à tester les codes de types "utillity" ou "framework" ou "sdk".
Mais tout code business sera mieux vérifier par une personne qui connait pas le produit ou juste ce qui devrait faire.

J'ai été hanté par les entreprises qui utilisaient leur logiciel avec des bugs et me dire que c'est le quotidien et toujours d'actualité. Après je comprends pourquoi les ricains ont plus de produits logiciels que nous.
J'ai moi-même été pris dans ce piège et je pense tout le monde est humain. Avant j'avais pas le skill pour expliquer les bugs, maintenant je l'ai c'est plus simple et le développeur comprend maintenant sans avoir conflit d'égo et bonus en anglais/français.

Par exemple, j'ai du faire comprendre à un retraité que son interface n'est pas utilisable et le truc qu'il me sort: "Oui mais je l'utilise". Et pendant ce temps, le projet n'avance pas. Des fois le goût du dêveloppeur n'est pas bon et on a du mal à l'admettre. En plus le développeur polyglot pro-code (qui ne s'est jamais intêresser à l'UI) est toujours contre le désign. Combien de gens j'entends, moi je ne veux pas toucher au front ou aux interfaces.