Discussion :

[csik78]

Bonjour à tous,

Tout d'abord je m'excuse si je me trompe de section, ou que le sujet est redondant.

Pour introduire mon problème, commençons par le contexte. Je travaille actuellement dans une start-up sur une plateforme avec l'architecture .NET dont ASP.NET. Nous travaillons avec des méthodes agiles, notamment Scrum.

Nous avons très vite fait le constat que des tests étaient nécessaires avant mise en production sous peine d'avoir de nombreux retour de bug. Nous avons donc commencer à travailler avec Windows Test Manager à rédiger des tests qui s’exécuteront de manière procédurale "Step by Step".

Le nouveau problème qui survient est la perte de temps (Le terme perte est discutable) est grande car nous testons toutes les fonctionnalités avant mise en prod.

J'aimerais savoir quelle est votre point de vue sur la question de tests dans un projet afin de ne perdre qu'un minimum de temps pour une efficacité maximum. Et si vous connaissez les tendances actuelles, je suis également intéressé.

Je suis actuellement en train de lire les spécifications de Scrum, peut être que cette question y est spécifiée.

Les questions qui reviennent souvent dans ma tête sont :

-Les tests doivent-ils se concentrer sur les fonctionnalités critiques de la plateforme ?
-Développer des tests automatisés vaut vraiment le coup quand le produit est susceptible d'évoluer en permanence ?
-Existe-t-il des méthodes qui permettent un bon compromis entre efficacité et temps gagné ?

Je vous remercie de votre participation,

Je ne suis actuellement que junior mais les questions m'intéressent, votre point de vue m'aiderait grandement!

Cordialement,

Csik.

[deusyss]

Bonjour csik78,

Je travaille personnellement en SSII, actuellement sur un projet pour un client industriel. Leur SI, bien que âgé, est en perpétuelle "mise à jour".

De mon retour d'expérience, sur plusieurs années, nous passons effectivement beaucoup de temps sur leurs demandes (jusqu'à 50%), mais cela s'est finalement avéré être indispensable.

Pour commencer, ne pas tester ses applis, c'est prendre le risque d'un bug en production, ce qui signifie un arrêt plus ou moins long de la chaine de PROD. Pour une entreprise cela est extrêmement grave et elle peut ensuite reporter cela sur les prestataires informatique (attention au contrat).

Ensuite, prendre du temps à développer des tests automatisés, c'est certes une "perte" de temps au départ, mais par la suite, cela signifie standardisation des tests (une fois le catalogue validé par le client), et gain de test pour les futurs dev.

Personnellement, je n'ai pas la chance de travailler sur des technos permetant d'automatiser des tests. Mais ces derniers constituent une garantie pour le client, une protection pour toi même, et un gain de temps pour les futurs dev.

Je ne pense pas qu'il existe de recette miracle pour réduire le temps de tests, excepté une certaine rigueur, de la documentation, de l'automatisation de test, et de la communication entre les différentes parties.

[Luckyluke34]

Scrum ne précise presque rien (certains diront malheureusement) sur les tests automatisés contrairement à eXtreme Programming par exemple.

Quand on parle de tests automatisés c'est très vague, il y en a de toutes sortes qui répondent à des besoins différents.

J'aime bien la classification "TestPyramid" de Mike Cohn qui montre qu'on doit tester à différents niveaux pour être efficace :



http://www.mountaingoatsoftware.com/...mation-pyramid

http://martinfowler.com/bliki/TestPyramid.html

[csik78]

Pour le développement des tests automatisés, les problèmes est que les spécifications sont susceptibles de changer à chaque fois. Il n'y a pas de validation d'un module puisque nous développons en interne en R&D. Les tests automatiques sont susceptibles d'être réécrit de nombreuses fois.

Effectivement même dans notre cas, les bugs sont à proscrire absolument lors des mises en productions car nous sommes sur un marché ou les clients ne sont pas nombreux. Toute expérience utilisateur frustrante due aux bugs est donc à filtré absolument.

Avec .NET nous disposons des tests unitaires et des classes de tests visual studio cependant j'ignore si dans notre cas où les spécifications changent régulièrement, ces méthodes sont rentables.

Je vous remercie des premiers avis, ils me seront utiles !

Edit :

Personnellement, je n'ai pas la chance de travailler sur des technos permetant d'automatiser des tests.

Sur quelles technos travaillez vous ?

[el_slapper]

Tout d'abord félicitations, trop rares sont les gens qui pensent à tester.

(.../...)-Les tests doivent-ils se concentrer sur les fonctionnalités critiques de la plateforme ?

Non. Tout doit être testé. Après, les fonctionnalités secondaires, on peut se contenter de les survoler. Mais ce survol est nécéssaire.

-Développer des tests automatisés vaut vraiment le coup quand le produit est susceptible d'évoluer en permanence ?

ça dépend. Comme tu est en .NET, je dirais que pour les tests unitaires(voir l'excellent schéma de Luckyluke34), c'est incontournable. Pour le reste, quand ça bouge beaucoup, c'est plus compliqué. Mais si tu n'a pas fait les tests unitaires, tu deviens vulnérable au changement.

Pour revenir à ta première question, tous tes éléments unitaires doivent être testés. Même si certains plus que d'autres. Mais tous doivent être validés au moins unitairement, c'est le minimum absolu.

-Existe-t-il des méthodes qui permettent un bon compromis entre efficacité et temps gagné ?(.../...)

pas à ma connaissance : chaque projet est différent, et il faut s'adapter.

[csik78]

Pour en revenir à ce fameux triangle, le test au niveau de l'UI ne signifie t-il pas à valider le bon fonctionnement ?

Je suis conscient que les tests au préalable comme les tests unitaires diminueront le nombre de bug sur l'UI mais globalement, le test de l'UI permet de rétro-validé les deux autres si le jeu d'essai est correct, non ?

J'ai entendu parlé d'un outil nommé Selenium pour ce genre de test qui m'a l'air fort sympathique.

Pour le moment, je pense personnellement que les tests des fonctionnalités critiques doivent-être automatisés mais le test des fonctions secondaires comme vous le dites doit seulement être survoler pour ne pas perdre trop de temps à les rechercher. Ils remettront naturellement lors de l'utilisation.

Encore merci de vos avis.

[el_slapper]

Pour en revenir à ce fameux triangle, le test au niveau de l'UI ne signifie t-il pas à valider le bon fonctionnement ?

Il signifie surtout que si tu n'as pas testé unitairement, le test d'UI va tourner au cauchemar. Avec un bug tous les dix lignes de codes sur du code non debuggué(à la louche, ça peut fortement varier), si tu attaques directement le test d'UI sans être passé par les étapes précédentes, tu peux tout de suite apprendre à faire un noeud coulant. Un seul.

Je suis conscient que les tests au préalable comme les tests unitaires diminueront le nombre de bug sur l'UI mais globalement, le test de l'UI permet de rétro-validé les deux autres si le jeu d'essai est correct, non ?

Faux.

Tout simplement parcequ'on ne teste pas de la même manière sur les différents éléments. Quand on test

J'ai entendu parlé d'un outil nommé Selenium pour ce genre de test qui m'a l'air fort sympathique.

Connais pas. NUnit pour les tests unitaires, est très bon. Mais il ne permet pas les tests d'UI.

Pour le moment, je pense personnellement que les tests des fonctionnalités critiques doivent-être automatisés mais le test des fonctions secondaires comme vous le dites doit seulement être survoler pour ne pas perdre trop de temps à les rechercher. Ils remettront naturellement lors de l'utilisation.

C'est plus compliqué que celà. Les tests unitaires gagnent quasiment toujours à être automatisés(ne serait-ce que parceque ça sert de doc quand on a perdu la doc, et ça arrive souvent). Par contre, sur les étapes ultérieures, il s'agit effectivement de mettre plus d'effort sur les fonctions critiques. Y compris, si c'est pertinent, un effort d'automatisation.

Il serait dommage d'accumuler de la dette technique.

[csik78]

Hum.. pourtant la finalité n'est-elle pas que tout soit fonctionnel niveau UI ? J'entends par là que l'UI nous affiche ce que l'on souhaite quand on le souhaite, nous proposes les interactions que l'on souhaite.

Le fonctionnement actuel des choses étant :

Nous développons nos fonctionnalités, nous testons qu'il fonctionne globalement. Par la suite toutes ces modifs effectués iront sur le serveur de pré-prod ou les modifs seront testés avec windows test manager qui nous fera exécuter des scénarios que nous avons rédiger par nos soins.

Exemple de scénario :
Titre : Crée un compte depuis le formulaire initial.
-Cliquez sur le bouton de création de compte. : La page de création apparait
-Essayez de valider sans remplir aucun champs : Le libellé champ obligatoire apparaît sous les champs non remplis.
-Rentrez un email mal formaté : Un message apparait vous indiquant que l'email est mal formaté.

Puis nous validons chaque étape de manière à valider le test. C'est ce que j'appelle les test UI, peut être que je me trompe.

Pour vous donner un ordre d'idée, généralement 7,8 bugs surviennent chaque mois avant une mise en production durant cette étape.

[Luckyluke34]

Je suis conscient que les tests au préalable comme les tests unitaires diminueront le nombre de bug sur l'UI mais globalement, le test de l'UI permet de rétro-validé les deux autres si le jeu d'essai est correct, non ?

En vrac et j'en oublie certainement, ce que les tests unitaires automatisés font et que ne permettent pas les tests d'UI :

• En cas de bug, avoir un feedback extrêmement rapide et précis sur l'objet (voir la ligne de code) qui dysfonctionne, ce qui fait gagner énormément de temps.
• Avoir un harnais de sécurité "au plus près du corps" quand on se lance dans du refactoring (par comparaison, les tests d'UI correspondent plus à un filet placé 150 m plus bas )
• Servir de documentation de la base de code pour les nouveaux venus dans l'équipe de développement.
• Tester ce qui ne passe pas par l'UI ou difficilement testable par l'UI.
• Réutiliser tel ou tel module de code dans le contexte d'une autre application en gardant les tests qui lui sont associés pour s'assurer qu'il fonctionne toujours.
• Vérifier que certaines bonnes pratiques de dev ont été respectées (tel assembly ne doit pas en référencer un autre, etc).
• Savoir précisément quel pourcentage de la base de code est couvert par des tests.
• Couvrir un large spectre de cas et branches conditionnelles en moins de tests.
• Faire émerger la conception de tes objets de façon incrémentale (ça c'est si tu fais du TDD).
• ...

[Luckyluke34]

Hum.. pourtant la finalité n'est-elle pas que tout soit fonctionnel niveau UI ? J'entends par là que l'UI nous affiche ce que l'on souhaite quand on le souhaite, nous proposes les interactions que l'on souhaite.

C'est la fin des fins, mais elle ne doit pas faire oublier tous les objectifs intermédiaires de qualité interne qu'il est nécessaire d'atteindre pour se prémunir de mauvaise surprises au cours de la vie du logiciel, ni tout ce qui n'est pas mesurable à travers l'UI.

Est-ce que tu serais prêt à monter à bord d'un avion dont le constructeur aurait fait des vols d'essai sur des modèles assemblés mais dont les composants n'ont pas fait individuellement l'objet d'un contrôle qualité ? Je ne suis pas sûr...

Il faut aussi voir que la qualité d'une application se mesure certes en nombre de bugs rencontrés mais aussi au coût des évolutions, coût qui tient à bien d'autres choses que la qualité externe refétée par des tests d'IHM.

[Logan Mauzaize]

Je trouve qu'il manque deux mots dans cette discussion : "tracabilité" et "non-regression".

Concernant le premier, il s'agit de "tracer" un lien entre ce qui est demandé (les spécifications), ce qui est testé (le plan de test) et éventuellement de qui est réalisé (le code).
Je ne parlerai pas de la traçabilité du code qui demande un effort plus que conséquent.
Le principe est de découper les spécifications en petites unités appelées "exigences" et de leur attribuer différentes informations telles qu'un identifiant, un (ou plusieurs) catégorie(s), une version et une description.
Ensuite on élabore un plan de test composé de scénario de test. Chaque scénario possède un identifiant, un nom, une description et une liste d'étape. Chaque étape se compose d'un numéro, d'une action, d'une vérification et éventuellement d'une ou plusieurs exigences. Chaque scénario se voulant aussi unitaire que possible.

Alors à quoi ca nous sert tout ça ? Déjà dès lors que l'on touche aux spécifications, on sait qu'elles sont les tests liés et qui composent la base de la "non-régression". Ensuite, il est fortement utile de sélectionner ou d'écrire spécifique des tests à repasser dit "de non-regression" qui seront passés quelques soient les éléments modifiés.

Si la traçabilité va assez loin, elle devrait être capable de tracer des liens entre les exigences des spécifications (on parle d'exigence raffinée par exemple). A défaut (et il est fortement conseiller de le faire), il faudra définir des relations entre certaines exigences car elles peuvent être dépendantes. Ce sont souvent les diagrammes d'UC qui permettent de les mettre en lumière lorsque l'on utilise des "extend" ou des "include".
Ceci vise à définir "l'analyse d'impact" en élargissant la recherche des tests couvrants en incluant également les tests couvrants les exigences liées.


Une autre chose intéressante sur laquelle j'ai travaillé c'est la mise en place d'une base de connaissance pour l'aide à analyser d'impact. Le but est d'instrumenter le code pour définir quelles méthodes/branches/lignes sont appelées lorsque l'on joue un test. Une analyse des mesure permet ensuite de déterminer qu'elles sont les tests les plus représentatifs si on modifie une méthode/branche/ligne. Cependant c'était en Java ce qui est assez simple à réaliser. En .Net, je ne sais pas.


Concernant les tests automatiques d'IHM, Selenium est dédié aux pages Web. J'estime que l'effort est rentable dès lors qu'on passe un test plus de deux fois. Ce qui est assurément le cas pour les tests de non-régression.

[el_slapper]

Nemek a tout dit d'un point de vue technique, mais j'aimerais reformuler de manière plus philosophique.

Des décennies de pratique ont appris aux anciens(dont nous sommes, nous et quelques millions d'autres) la valeur d'un certain nombre de pratique, et l'illusion que représente souvent le "bon sens". Le "bon sens", c'est que si l'appli finale marche, alors tout va bien. Et, en fait, c'est une mauvaise manière de mener un projet.

Mauvaise idée pour le projet lui-même, puisqu'on retarde la detection du bug. Le programeur a oublié ce qu'il avait fait, et il met plus de temps à corriger, le bug pouvait en cacher un autre, etc..... En bref, tester ce que l'on vient de faire, c'est optimiser l'utilisation des ressources en termes de charge, et réduire le délai de correction de bugs.

Mauvaise idée pour la suite, parceque 80% de la vie d'une appli, c'est la maintenance. Un système complet et efficace de tests unitaires est une garantie forte de maintenabilité(la non-regression dont parle Nemek).

L'informatique est un royaume de l'invisible(pour l'utilisateur). Joel Spolsky parle du syndrome de l'Iceberg. Celà veut dire que se contenter d'être satisfait de la surface, c'est une catastrophe garantie par la suite. Si l'iceberg n'est pas construit sur des bases solides, il va se renverser. On doit soigneusement l'équilibrer pour qu'il ne bascule pas, et qu'il ne coule pas les bateaux passant à proximité. Il ne suffit pas de faire un joli sommet de l'iceberg qui à l'air de marcher.

[csik78]

Je prend le temps d'analyser vos réponses d'avantage dès ce soir, elles sont très intéressantes.

D'un point de vue traçabilité et bonne manière, je suis entièrement d'accord avec vous.

Nemek j’interprète ton post comme les bonnes manières à avoir lorsque l'on développe en terme de gestion d'erreur. Cependant généralement les problèmes qui surviennent lors des phases de test sont bien souvent des erreurs liés aux fonctionnements des modules et des méthodes entre eux. Hors les tests unitaires auraient validé le bon fonctionnement de ma méthode.

De plus, dans notre contexte, il faut trouver le bon compromis entre temps dépenser à mettre en place les tests et l'efficacité de ceux-ci. Selon moi, la méthode que tu décris concerne le cas optimal en terme de tests. Hors dans notre cas pour nous permettre d'avancé plus rapidement, nous nous accordons une tolérance aux bugs non critique.

Je suis conscient que d'un point de vue traçabilité le gain de temps peut être énorme. Néanmoins, je ne suis pas sure que les tests unitaires au niveau de la méthode permettent de détecter nos problèmes qui se trouvent au niveau de l’interaction entre les modules / méthodes.

Après c'est peut être ce dont tu parles lorsque tu parles de tracer des liens entre les exigences des spécifications.

Peut être que les tests peuvent également gérer l'interaction entre ceux-ci.

[Logan Mauzaize]

Attention, je parle de tests de validation et non de tests unitaires.
Les tests unitaires visent le code (ex: NUnit) alors que les tests de validation visent le produit (ie ce qui est généré, packagé et déployé). Au dessus, il existe les tests d'intégration, de recette et autres.

Les tests unitaires étant généralement automatiques, il est recommander de tous les passer de manière très régulière et de passer tous les tests couvrants après chaque développement.

[el_slapper]

(.../...)Je suis conscient que d'un point de vue traçabilité le gain de temps peut être énorme. Néanmoins, je ne suis pas sure que les tests unitaires au niveau de la méthode permettent de détecter nos problèmes qui se trouvent au niveau de l’interaction entre les modules / méthodes.(.../...)

Pas au début, en effet. C'est pour ça qu'on ne se contente pas des tests unitaires.

Exemple : on a un module qui affiche les données client. Il appelle le module des données du compte du client(par exemple pour avoir son solde). Hors, quand le client est décédé(ehhhh oui ça arrive), le second module plante.

Evidemment, on a pas pensé à ce cas-là au début. On l'identifie lors d'un test d'integration ou d'homologation(celui-là, généralement, sort assez tard). On corrige donc les modules pour qu'ils papotent différement sie le client est décédé. Et, bien sur, on met à jour les tests unitaires pour tester aussi le cas du client décédé.

Une fois le TU en place, on le retourne automatiquement systématiquement. Et si plus tard on casse quelque chose à ce sujet(en amont ou en aval), on le verra dès le codage. Parceque le TU tourne en permanence.

Autant que le code, le TU est dépositaire de l'expérience accumulée sur l'application. De plus, il en est le garant : une fois qu'on sait ce qu'il faut tester et que c'est codé, on oublie plus de le tester. Alors que si on teste à la main, on finit par oublier des trucs, et un jour, le client décédé casse l'appli à nouveau, et on s'en rend compte bien tard, et ça coute horriblement cher à corriger.

[macatia]

Lorsque Nemek parle de base de connaissance pour l'aide à analyser l'impact d'un test de validation en Java, je comprends que cela permet de mieux sélectionner les tests de non-régression en validation.
Cela permet de répondre peut-être à la question de csik78 sur la validation des interactions entre modules / méthodes.
Comme les tests de validation sont plus lourds que les tests unitaires, la base de connaissance permet de sélectionner les tests de non-régression à appliquer par exemple chaque fin de semaine, si les dernières évolutions du code ne remettent pas en cause ces tests.
Dans ce contexte, les autres tests de non-régression en validation doivent être modifiés pour prendre en compte les évolutions de code pendant la semaine.
Je serais intéressé par votre expérience dans ce domaine en Java.
Quels logiciels de test pour aider à appliquer cette approche ? Vont-ils jusqu'à lire la gestion de version pour faire de la sélection automatique des tests applicables, en comparant avec le code de la dernière version validée ?

[Logan Mauzaize]

De mémoire, j'avais étudié Cobertura et JIP (je me souviens pas du vrai nom) pour enregistrer le code exécuté.
Ensuite, il y avait une moulinette de parsing pour alimenter une base de données en indiquant la version à laquelle appartiennent les données.

Pour le reste c'est du code custo pour comparer et compter les occurences. Avec une IHM avec plusieurs colonnes : arbres, version avec occurence.
En fait c'est surtout du "data mining".

[rimram31]

Bonjour à tous...
-Les tests doivent-ils se concentrer sur les fonctionnalités critiques de la plateforme ?
-Développer des tests automatisés vaut vraiment le coup quand le produit est susceptible d'évoluer en permanence ?
-Existe-t-il des méthodes qui permettent un bon compromis entre efficacité et temps gagné ?
...

Questions récurrentes, notamment dans un environnement start-up initial focalisé sur les "features" négligeant la validation et l'exploitation. J'ignore ton environnement mais j'ai connu par deux fois cette expérience (start-up, nouveaux produits, évolutions permanentes ...) et une évolution similaire: d'abord je créé a tout va, je me pose ensuite la question des tests, plus tard celle des problèmes d'exploitation.

La mauvaise nouvelle (pour ta boite!), c'est que tests/validation (puis plus tard exploitation) sont des activités coûteuses que l'on va négliger en se racontant des histoires, surtout que par nature, les compétences en place initialement sont essentiellement des développeurs persuadés qu'ils ne feront pas d'erreur (et/ou que le problème sera facile a résoudre). Si votre activité tient la route, a force d'essuyer les plâtres (et de vous faire allumer par les clients), vous vous résoudrez a investir dans des activités (et ressources) de tests, activités et ressources dédiés a l'exploitation. Selon les situations ça peut prendre des années! (vécu) pour finalement avoir des activités et équipes de validations et d'exploitation indépendantes de la "R&D".

Ca c'est une réponse organisationnelle, en pratique, elle ne se réalise que lorsque la réalité économique finit par l'imposer (en clair, quand vous aurez rencontré de gros soucis en déploiement, la question trouvera toute seule sa réponse!). Certes nous n'en sommes plus au "cycle en V" mais quelques soient vos méthodes, scrum, agile ... toute activité de développement a des tenants et aboutissements, il faut se représenter la "chaîne" de production/exploitation de la ligne de code écrite au service "rendu" pour s'en faire une idée plus précise selon la situation.

Sinon, au delà de ces questions philosophiques, en pratique on fait comment?

Déjà répondu au dessus, la question de la granularité des tests (unitaires, services, ui ...). Le principe est simple a comprendre, plus l'anomalie est découverte tôt, moins elle sera coûteuse a corriger, parce que d'une plus rapide a identifier, de deux n'aura pas entrainé de perte de temps pour les autres. Les parties hors fonctionnelles "haut niveau" (UI par exemple) relèvent du développement et de pratiques, un peu lourd au début mais qui doivent ensuite être totalement intégrées au déploiement de sorte que n'arrivent aux tests que des composants déjà dépouillés de boulettes évidentes.

Pour les parties "en surface": UI, services ... qui relèvent elles de vos use case, il est de bon ton de rédiger les scénarios de tests dès la conception (et de les maintenir!). L'UI/service (type web service) peuvent se scripter (quoique des tests "manuels" restent en général nécessaires et utiles). Je connais un peu Selenium mais je l'ai utilisé pour automatiser pas pour les tests, tu as aussi jmeter qui est pas mal. Les deux permettent d'enregistrer et de rejouer ensuite des scénarios.

Autre technique utile, surtout si vous avez des éléments "externes" (avec qui vous devez échanger), des approches de type mock-up (souvent obligatoires d'ailleurs pour les tests).

Enfin un conseil, je ne sais pas si vous travaillez en mode éditeur ou fournisseur de service (type Saas) mais le top est d'introduire des tests en production. Si vous êtes en mode Saas, il faut intégrer dans la chaîne de monitoring le contrôle des fonctions critiques. Il y aura des situations ou vos tests seront passés a coté de quelque chose, un élément qui sera légèrement différent en condition de production vs de validation et ou vous allez planter un composant au fin fond de la plateforme, si une alarme sonne au moment ou vous déployer, facile de faire un retour arrière, quand on s'en aperçoit longtemps après, pas toujours simple de remonter a la cause initiale.

Ca te parait beaucoup de choses, ne t'affoles pas, vous ne ferez pas tout en même temps, prend les divers éléments et montez en puissance peu a peu. Si vous avez du succès, vous aurez nécessairement des phases de crises qui, après coup, justifieront "naturellement" certains investissements.

[macatia]

Merci à Nemek pour sa réponse.
Fondateur de start-up, je confirme la démarche pragmatique conseillée par rimram31.
Il faut se méfier dans le domaine des tests des diverses approches trop rigides.
Personnellement, j'aime bien le principe fondateur des tests chez Google : un test répond à un risque. Le jeu de tests est adapté selon l'expérience passée : un test (automatisé ou non) toujours OK depuis longtemps est un test inutile s'il ne répond pas un risque majeur.
Pour info, le comité français des tests logiciels a publié en début d'année un sondage éclairant sur les pratiques de tests logiciels en France.

[Aqualys]

Je souhaite apporter mon point de vue sur les recettes, pour la simple raison que je suis le référent dans cette activité au sein de mon service. il a fallut beaucoup de temps pour mettre en place des outils et des jeux de données, mais maintenant nous pouvons faire des tests bien au delà d'une recette d'application ( lancement de tests de volumétrie et de tests de charge, très rapidement ).

En avant-propos, je sais que certains ingénieurs systèmes aiment la philosophie ' Tester c'est douter', mais ce qui peut marcher pour des scripts ne peut pas s'appliquer à des applications. Les tests unitaires sont de la responsabilité de chaque développeur, il n'est pas concevable de lancer une recette et trouver des bugs basiques.

Nous avons 3 types de recette, une recette technique, une recette fonctionnelle et la dernière d'intégration. Les objectifs, les enchainements, les résultats attendus sont décrits au travers de plans de test,
La première étape, recette technique, consiste à vérifier qu'en mode 'normal', pour des cas standards, l'appli fonctionne bien. Cette recette peut concerner, aussi, les échanges avec d'autres SI. Les jeux de test sont simples, ils doivent valider les enchaînements.
La seconde recette, fonctionnelle, consiste à vérifier toutes les règles de gestion, règles métier qui influencent le comportement normal ; en clair les exceptions, leur déclenchement, leur suivi. Les jeux de test sont conséquents et sont maintenus à jour.
La dernière recette, d'intégration, sert à vérifier que la mise en exploitation de l'appli, ne mettra pas en vrac le ou les serveurs du SI où se trouve l'appli. Il faut disposer d'un environnement, copie conforme de la prod et qui a la même activité. Les jeux de test sont une reprise de la production ( j-24h par exemple ).

Comme je l'ai écris au début, la mise au point des jeux de données et des plans de test a été longue. Mais maintenant, c'est comme maintenir la documentation, nous gagnons beaucoup de temps sur les étapes de recette, et en fiabilité des résultats, car bien sûr les tests de non régression sont constants.

En 25 ans d'expérience, c'est le meilleur compromis que j'ai trouvé ; cette méthode n'est pas infaillible et lourde à mettre en place, mais il vaut mieux passer du temps sur la recette que de voir des retours d'expérience des utilisateurs qui ne parlent que de bugs au lieu d'évolution...