Discussion :

[an1844]

Bonjour à toutes et à tous,

Je ne suis pas sûr d'être au bon endroit sur le forum, merci aux administrateurs du forum de déplacer ma discussion si utile.

J'ai fais une rapide recherche sur le forum sur "recette" et j'ai trouvé des discussions sur "le tri des recettes de cuisine".
Ce n'est pas ce que je cherche, mais j'ai peut être mal cherché ... on est d'accord.

Ce que je recherche, c'est me documenter sur les "recettes ou tests de validation" suite à la mise à disposition d'une appli par un prestataire à un client.
Je "représente" le client et informatiquement je ne suis sûrement pas le mieux placé ... on est d'accord ... ce qui ne m'empêche pas d'essayer de me cultiver.

Avec le peu d'expérience que j'ai, je savais que cela existait, que cela pouvais être manuel ou automatique, ... on est d'accord on vas oublier l'automatique, nous sommes à des années lumières d'être prêt.

Ma cible c'est un test de validation manuel, je cherche à me documenter sur ce sujet :
- les + ... aucun !!

- les - : la formalisation de test de validation semble être une surprise pour le client (le mot important est formalisation ... on serait plutôt "à l'arrache"), je ne suis pas sûr que les process soient maîtrisés, les délais sont évidemment hyper court, ....

Je ne suis pas non plus tombé de la dernière pluie, les tests de validation industriel pour des équipements de production, je connais.
- la pré-étude de faisabilité ;
- la constitution d'une équipe ;
- la validation des process et la fixation de ceux-ci jusqu'à la recette ;
- la formalisation de la documentation ;
- la formalisation du test de validation lui-même ;
- la planification ;
- la définition des responsabilités ;
- la contractualisation de l'ensemble ;
- ... le PV de réception ...

Mais comment ce présente sur "papier" un test de validation d'une appli informatique ?, où sont les pièges de ce type de test ?, ... ?

Entre autre information , j'en suis à lire cela :
https://memsic.ccsd.cnrs.fr/mem_01128924/document

Si vous avez la possibilité de me documenter, merci d'avance.

Merci de votre attention
an1844

[Marco46]

Le problème c'est que cette question n'est pas technique mais d'abord d'ordre juridique.

Un fournisseur a développé une appli pour le client que tu représentes.

Ya écrit quoi dans le contrat pour cadrer tout ça ? Quelle est la base de travail du presta ? Par qui et comment sont qualifiées les anomalies ? Qu'est-ce qui est prévu pour les résoudre etc ...

Il n'y a pas une seule manière de faire, il y en a autant qu'il y a de contrats en fait.

où sont les pièges de ce type de test ?

Les pièges ne sont pas dans les tests mais dans le contrat entre le presta et le client. Quelle est la nature du livrable ? Code source ? Binaire ou package déjà construit ? Les développements se font au forfait dans un centre de service ou les développeurs sont en régie chez ton client ? Quelle est leur base de travail ?

Bref comment tout ça fonctionne.

[an1844]

Bonjour,

Merci Marco46 du temps que tu y consacres.

Je vais essayer de répondre au mieux ... si mes réponses peuvent paraître sèches, y voir plutôt des réponses courtes.
Pour info ... je suis un gnou.

Le problème c'est que cette question n'est pas technique mais d'abord d'ordre juridique.

L'ordre juridique, honnêtement ce n'ai pas ma priorité.
j'ai un chef.
Mon chef à un chef.
Ce chef à un directeur.
Le juridique ... je leur laisse.
A moi, on me demande de faire une recette d'une appli informatique, au pire un truc qui y ressemble.

Un fournisseur a développé une appli pour le client que tu représentes.

Oui, une sorte d'appli de vente en ligne.

Pour faire court :
- le client que je représente est en fait un petit prestataire (parmi des centaines d'autres) d'un très grand groupe ... à bien y regarder ce très grand groupe est notre seul client ;
- dans ce très grand (groupe) client, un jour un col blanc à suggérer d’externaliser notre presta et que nous pourrions faire une proposition ;
- un appli de vente en ligne se prêtait très bien à cette externalisation de presta, donc commande à été passée entre nous et un prestataire informatique, mais rien entre nous et très grand groupe client ;
- tout à été très vite, contractuellement parlant c'est très très flou ;
- et puis patatra, un jour, de ce même très grand client, un autre col blanc à décidé que non en fait externalisé la presta c'était pas une si bonne idée que cela , AIE, que ce soit avec nous ou avec un autre ;
- mais la 1ère copie de l'appli est livrée par le prestataire informatique, faut faire une "recette", quésaco une recette ;
- ... pas grave, an1844 est là pour cela ... ben voyons

- .... je pense que tu l'as compris le coté "vente en ligne" s'écroule ... mais cela ne veux pas dire qu'il n'y a pas quelque chose à tirer de l'appli.

Ya écrit quoi dans le contrat pour cadrer tout ça ?

Surprise surprise ... j'ai pas accès à cette info.
Et je pense que je n'y aurais pas accès.

Quelle est la base de travail du presta ?

Une super ERP de notre très grand client.
Un ERP classique à nous.

Par qui et comment sont qualifiées les anomalies ?

Par qui ? .... heu votre humble serviteur ... moi ... an1844 ... et une équipe de collègues (notez que je n'ai pas écris collaborateurs) ... l'ensemble disposant de peu de temps, parce qu'il n'y a pas que çà à faire ;
Comment ? ... j'ose une réponse ... via une recette
C'est d'ailleurs le sujet de la discussion.

Qu'est-ce qui est prévu pour les résoudre etc ...

A chaque anomalie constatée, via une appli dédié du prestataire informatique (encore une autre), nous soumettons des "tickets".
Si j'ai bien compris,l'idée du prestataire informatique était /
- de livrer une appli ;
- le client fait sa recette ;
- le client émet X tickets ;
- le prestataire informatique traite en UNE fois tous les tickets ;
- le prestataire informatique re-livre l'appli ;
- ... ainsi de suite, jusqu'au PV de réception.

Comme il y a quand même un gros écart entre le projet initial et le projet d'aujourd'hui, et qu'après quelques heures passées, les quelques anomalies constatées de l'appli sont plutôt grossières que subtiles.
Notre idée à nous, serait plutôt :
- de faire une "recette basique" de l'appli ;
- émettre les tickets ;
- voir la capacité du prestataire informatique à corriger au fur et à mesure des tickets, les erreurs grossières ;
- ..... ;
- pour l'instant, j'ai "rejeté" tous les tickets soit disant "résolu" ... , ce qui n'est pas encourageant ;
- ...
- et qu'ensuite on fasse une recette "manuelle" aussi complète que possible ;
- et là on reviens au désir du prestataire informatique ;
- ... en bref ... un truc Agile.

C'est cette recette "manuelle" que je cherche à formaliser.

Il n'y a pas une seule manière de faire, il y en a autant qu'il y a de contrats en fait.

Je me doute

Les pièges ne sont pas dans les tests mais dans le contrat entre le presta et le client.

Comme dit précédemment, le coté contrat je le laisse à mes chefs.

Pour ce qui est des tests, naïvement j'avais imaginé que pendant leur formation, les développeurs qui doivent bien être testeurs de temps en temps, avaient été formés aux recettes.
Et donc que le Béaba de la recette avait une présentation formalisée ... après formation chacun en fait ce qu'il veut / peut ... mais au moins tout le monde à au minima le même "vocabulaire" de base.
Ce que je cherche donc c'est cette formalisation / présentation (peut être sommaire mais efficace pour ce que l'on vas en faire) d'une recette.

Quelle est la nature du livrable ?

Reformuler pour un gnou.

Code source ?

Reformuler pour un gnou.

Binaire ou package déjà construit ?

Reformuler pour un gnou.

Les développements se font au forfait dans un centre de service ou les développeurs sont en régie chez ton client ?

forfait dans un centre de service

Quelle est leur base de travail ?

Reformuler pour un gnou.

Bref comment tout ça fonctionne.

Je fais de mon mieux ... d'autres diraient que je suis en roue libre.

Si cela n'existe pas, ce que je doute, je ferais le job avec ma forme de recette, çà vas piquer un peu, pour ceux qui ne vont pas vouloir adhérer.

Merci de votre / de ton attention.
an1844

[Marco46]

La situation que tu décris est très bizarre.

Bon pour mieux se comprendre je vais simplifier la manière dont normalement ça doit se dérouler pour développer un logiciel.

La manière "old school" que l'on appelle plus communément le "waterfall" c'est d'écrire sous forme de documents (word, pdf ou autre) TOUT ce que l'application doit faire. On commence par une phase d'expression du besoin qui recueille au doigt mouillé ce que l'application doit faire. Cette expression du besoin est ensuite raffinée pour en extraire les règles de gestion, les différents cas d'utilisations, pour établir un dictionnaire des concepts métiers importants et les définir précisément, voire même certains écrans sous formes de wireframe (une vision brute sans design de l'UI), lister les données (pas les modéliser), etc ... Ça abouti aux spécifications fonctionnelles. C'est écrit par des concepteurs fonctionnels, pas par des profils techniques.

Jusqu'ici, aucun développeur n'est entré en action. Généralement quand on fait un développement au forfait c'est cette documentation qui sert de point d'entrée à un centre de service. Ça fait également partie de la base contractuelle pour définir ce qu'est une anomalie.

C'est là que la question juridique est cruciale. Une anomalie ce n'est pas ce que toi tu penses être une anomalie, c'est un comportement de l'application qui n'est pas conforme aux spécifications. La nuance est de taille. Si ça ne fait pas ce que tu veux mais que c'est conforme aux spécifications, alors ce n'est plus anomalie mais une évolution fonctionnelle. C'est important parce que dans le premier cas (anomalie) c'est pour la pomme du presta (mais là aussi ça dépend du contrat, il peut y avoir des limites), dans le deuxième cela entraînera une facturation.

D'où ma question sur le contrat.

Si tu n'as pas cette documentation qui sert de base aux développeurs, tu ne peux pas qualifier (recetter) l'application.

Pour ce qui est de l'agile, si tu as déjà reçu une livraison, c'est mort pour faire de l'agile. L'agile intervient pendant le processus de développement, pas quand il est terminé. On découpe les besoins fonctionnels par petits morceaux (nommés user stories) que l'on donne à développer par lots et que l'on qualifie (recette) par petites itérations (généralement 2 à 3 semaines). Du début jusqu'à la fin. Et on va en prod au fil de l'eau. Ça permet d'éviter l'effet tunnel.

Pour ce qui est de la formalisation de la recette, cela dépend beaucoup du logiciel utilisé pour saisir les tickets. Je rencontre très souvent JIRA en entreprise mais il y en a d'autres. JIRA est pas mal mais nécessite beaucoup de configuration. En tant que développeur j'ai une forte préférence pour les issues de GitHub et GitLab pour leur lien direct avec le processus de dev mais la plupart des organisations n'a pas encore la maturité suffisante pour utiliser ces outils (le markdown semble trop dur à apprendre pour certains). Bref.

Donc il te faut un outil pour gérer les tickets, outil accessible à toi et à ton prestataire.

Un ticket comporte différentes informations dont les plus importantes sont :

- la version impactée (le n° de version du livrable (le livrable c'est l'application qu'on te livre) dans lequel l'anomalie est constatée)
- la criticité (je te renvoie à la doc de SonarQube pour un exemple de classification, je la trouve très bien, il faut simplement compléter les exemples qui sont purement techniques avec tes besoins fonctionnels mais une ano peut aussi être purement technique)
- le protocole de reproduction (comment le dev fait pour reproduire le problème sur sa machine)
- ce qui est attendu (ce que ça aurait du faire)
- ce qui est constaté (ce que en fait ça fait et que c'est pas bon)
- la version corrigée (ça c'est quand le dev aura corrigé, dans quelle version il l'a corrigé)

Il te faudra également un environnement accessible à la fois par toi et ton équipe et par les développeurs de l'application dans lequel l'application est déployée et qui sert pour vous à faire les tests et pour eux à les reproduire. Ils vont reproduire sur la recette puis sur leur propre machines de travail. Important car certains problèmes sont dus à une mauvaise configuration, un problème de jeu de données, un problème réseau, etc... C'est pas toujours l'application elle-même qui a un soucis.

Assurez-vous de provisionner l'environnement avec un jeu de données qui soit réaliste.

Voilà c'est déjà pas mal. Je vais link ce sujet à un membre du forum dont c'est le métier de faire de la recette, s'il a le temps il aura certainement des suggestions pertinentes pour toi.

[el_slapper]

Je ne peux que plussoyer Marco46.

J'ajouterais que dans du waterfall, le travail de recette commence par écrire un cahier de recette à partir des specs. On l'execute tant que le livrable n'est pas conforme. Après, il y a beaucoup de diplomatie sur la gestion des non-dits. Si le bouton "ajouter au panier" met 42 secondes à répondre, même si les temps de réponse ne sont pas spécifiés, on lève quand même une anomalie. Mais ça ne marche que si c'est gros.

Il ya a aussi écrit dans le post initial le mot "arrache". Qui sous entend un mélange hostile de waterfall(avec de la paperasse partout), d'agile(avec des changements fréquents qui échappent à la hiérarchie), et de cowboy(absence de process, on fait confiance aux gens),en prenant le pire des trois, et le pire seulement. Difficile de faire du process propre dans ces conditions. Ce qui est d'autant plus déstabilisant pour quelqu'un qui semble venir de l'industrie(si j'ai bien compris). Dans l'industrie on ne joue pas. On ne joue pas, parce-que très vite on coupe du métal, et que ça coûte super cher. Le logiciel, en comparaison, est gratuit à fabriquer(on compile, même pas toujours, on assemble ou on builde, même pas toujours, on livre plus ou moins, et très vite on a produit ce qui était conçu). Donc les gens prennent de mauvaises habitudes. Même moi, parfois, je prends des raccourcis. Moi, issu de l'industrie, ayant fait de nombreux aller-retours entre le développement et le test, ayant écrit plusieurs manuels et autres formations au métier du test, parfois, quand je développe un outil rapidement, je peux m'oublier et aller trop vite. C'est mal. C'et mal, mais tout le monde le fait.

Après, Outre tout ce qu'a décrit Marco46,et que je soutiens à 100%, idéalement, on a une stratégie de test, document préliminaire qui explique comment on va découper les tests. Et on a un plan de test, qui comporte l'ensemble des scénarios qu'on va dérouler - et qui explicite le jeu de données dont on a besoin. Et on choisit parmi tous les types de tests que je vais dérouler(sans détailler, je ne vais pas faire un cours complet, je copie-colle juste d'une formation que j'ai faite en anglais récemment, pas le temps de traduire) :

Ce qui est ciblé :
+ usability and ergonomics
+ documentation
+ functionalities as specified<=== ça c'est contractuel.
+ inter-operability with third-party components
+ Performance, scalability, stress
+ Regression
+ Security
Quelle est la dynamique du test?
+ A "static" test case will focus on a unit component, like a field, a list, a link, and test all possible behaviours of that unit component
+ A "dynamic" test case will focus on a broader set of components, usually a screen, and go through all components of the set
+ A "through" test case will be a comprehensive, realistic scenario from beginning to end of the lifecycle of the data<== l'appellation Française de "test de bout en bout" est plus parlante, je trouve
Quelle valeurs tester?
+ Usual values are the most common ones - positive testing
+ On-limit values are extreme values - positive testing
+ Off-limit values are beyond the accepted values - negative testing
+ Aberrant values make no sense in the context - negative testing
Quel direction doivent prendre les tests?
+ Smoke testing is a simple validation that the product is working well enough to be tested in depth
+ Sanity testing is a validation of previous bugs correction<=== c'est là qu'on rejette les anomalies corrigées de traviole
+ Functional testing is a validation of the working state of the features, as specified
+ Exploration testing is a free search for bugs through the software, without any planned idea
+ Regression testing is a validation that legacy functions are still working as expected
+ Non-functional testing is a validation of what is not supposed to be in the specifications : Performances, interoperability, security, ergonomics

Voilà, c'est en vrac, mon petit pleure à cause de ses dents, je vous laisse mettre de l'ordre dans tout ça.

[an1844]

Bonjour,

Merci Marco46 et el_slapper, du temps passé, et surement aussi de votre patience.

Toutes vos explications me semblent très claires ...

J
Voilà, c'est en vrac, ..., je vous laisse mettre de l'ordre dans tout ça.

je vais essayer de faire de faire court.

... Ça abouti aux spécifications fonctionnelles. C'est écrit par des concepteurs fonctionnels, pas par des profils techniques.
.... Ça fait également partie de la base contractuelle pour définir ce qu'est une anomalie.
C'est là que la question juridique est cruciale.
Une anomalie ce n'est pas ce que toi tu penses être une anomalie, c'est un comportement de l'application qui n'est pas conforme aux spécifications.
La nuance est de taille.
Si ça ne fait pas ce que tu veux mais que c'est conforme aux spécifications, alors ce n'est plus anomalie mais une évolution fonctionnelle.
C'est important parce que dans le premier cas (anomalie) c'est pour la pomme du presta (mais là aussi ça dépend du contrat, il peut y avoir des limites), dans le deuxième cela entraînera une facturation.
D'où ma question sur le contrat.

Si tu n'as pas cette documentation qui sert de base aux développeurs, tu ne peux pas qualifier (recetter) l'application.

Je suis entièrement d'accord, et je l'étais dés le début.
Mais ok, l'erreur que je fais c'est d'attendre trop de résultat des tickets, puisque à la limite le DEV ... contractuellement ne serait peut être même pas obligé de me répondre.
Merci de la précision entre anomalie et évolution fonctionnelle.

Je vais devoir faire une distinction entre la recette officielle contractuelle (je ne dois pas en attendre grand chose) et la "recette fonctionnelle de ce que l'on attend" (il faut que je trouve un mot de vocabulaire pour simplifié) ... pour nous ... en attendant d'avoir mieux ... ce qui devrait revenir à lister une longue série "d'évolution fonctionnelle" ... donc en quelque sorte faire une recette.

J'ajouterais que dans du waterfall, le travail de recette commence par écrire un cahier de recette à partir des specs.

Même à moi cela parait évident.

On l'execute tant que le livrable n'est pas conforme. Après, il y a beaucoup de diplomatie sur la gestion des non-dits. Si le bouton "ajouter au panier" met 42 secondes à répondre, même si les temps de réponse ne sont pas spécifiés, on lève quand même une anomalie. Mais ça ne marche que si c'est gros.

Franchement je n'en suis pas à compter les sec, et très honnêtement je doute que quelqu'un y ai pensé.
Mais ce que je relève c'est très gros .... donc anomalie.

Pour ce qui est de l'agile, si tu as déjà reçu une livraison, c'est mort pour faire de l'agile.
L'agile intervient pendant le processus de développement, pas quand il est terminé.
On découpe les besoins fonctionnels par petits morceaux (nommés user stories) que l'on donne à développer par lots et que l'on qualifie (recette) par petites itérations (généralement 2 à 3 semaines).
Du début jusqu'à la fin. Et on va en prod au fil de l'eau.
Ça permet d'éviter l'effet tunnel.

Le truc c'est de dire au client "Regardez on a développé une fonction que vous avez demandez. Est-ce que ça répond toujours à vos besoins ?". C'est loin d'être fini, mais il y a un truc utile qui est déjà là.
Avec l'agile on peut réorienté le projet avec l'évolution des besoins.
Mettre un peu d'agile dans la gestion du projet ça permet de développer une solution qui répond vraiment aux besoins.
Sans aucune agilité c'est hyper rigide. Tu livres ce qu'il y a dans le cahier des charges, donc il y a de grandes chances pour que ça tombe à côté des besoins du client...

Mon truc, c'est de mettre en évidence pour mes chefs "Regardez un prestataire informatique a développez une appli de vente en ligne que nous lui avions demandé. Est-ce que çà répond toujours à nos besoins ??, et bien NON, mais c'est loin d'être fini, et voyons le bon coté des choses, il y a plein de trucs utiles qui sont déjà là"

Agile ou pas, nous sommes presque dos au mur, il vas y avoir abandon du projet ou ré-orientation du projet mais seulement avec pas mal de diplomatie et d'implication.
Si le prestataire informatique ne fait que regarder son contrat, ...

Pour ce qui est de la formalisation de la recette, cela dépend beaucoup du logiciel utilisé pour saisir les tickets. .... Bref.

Donc il te faut un outil pour gérer les tickets, outil accessible à toi et à ton prestataire.

Redmine.
Simple, avec un peu de rigueur, cela me vas.
Le défaut, pour l'instant je ne peux pas faire de ticket en mon nom, ni personne de mon équipe, il faut signer chacun de nos tickets, le suivi complet deviens rapidement lourd.
Mais j'imagine que si contractuellement il n'était pas prévu d’identifier plusieurs personnes ...

Il te faudra également un environnement accessible à la fois par toi et ton équipe et par les développeurs de l'application dans lequel l'application est déployée et qui sert pour vous à faire les tests et pour eux à les reproduire. Ils vont reproduire sur la recette puis sur leur propre machines de travail. Important car certains problèmes sont dus à une mauvaise configuration, un problème de jeu de données, un problème réseau, etc... C'est pas toujours l'application elle-même qui a un soucis.

Nous avons OK

Assurez-vous de provisionner l'environnement avec un jeu de données qui soit réaliste.

Nous avons OK

Voilà c'est déjà pas mal. Je vais link ce sujet à un membre du forum dont c'est le métier de faire de la recette, s'il a le temps il aura certainement des suggestions pertinentes pour toi.

merci

.... le travail de recette commence par écrire un cahier de recette à partir des specs. On l'execute tant que le livrable n'est pas conforme.

J'adorerais savoir faire cela ... mais d'ailleurs c'est ce que je suis venu demander

Il ya a aussi écrit dans le post initial le mot "arrache". Qui sous entend un mélange hostile de waterfall(avec de la paperasse partout),

Je promet de faire des efforts ... mais j'ai une certaine pression ... loin de là d'être stressé ... mais pressé ils sont (des 2 cotés).

d'agile(avec des changements fréquents qui échappent à la hiérarchie),

j'en reste à Ryu2000.

et de cowboy(absence de process, on fait confiance aux gens),

Comme je ne me souviens pas avoir écris ou lu cowboy, j'imagine que c'est un lapsus.

Difficile de faire du process propre dans ces conditions. Ce qui est d'autant plus déstabilisant pour quelqu'un qui semble venir de l'industrie(si j'ai bien compris).

Exact

.....idéalement, on a une stratégie de test, document préliminaire qui explique comment on va découper les tests.
Et on a un plan de test, qui comporte l'ensemble des scénarios qu'on va dérouler - et qui explicite le jeu de données dont on a besoin.
Et on choisit parmi tous les types de tests que je vais dérouler(sans détailler, je ne vais pas faire un cours complet, je copie-colle juste d'une formation que j'ai faite en anglais récemment, pas le temps de traduire) :

Intéressant, très intéressant, dans un autre contexte , je serai heureux de suivre une telle formation, ... c'est quoi les pré-requis ?

En résumer:
- il faut que j'abandonne le mot recette, il n'est pas adapté, et surtout je n'ai rein à y attendre;
- il faut que j'invente une formalisation de nos propres tests, parce qu'il semble que cela n'existe pas, et il faut que je lui trouve un nom.

Plutôt que Lucky Luke, vous pencherez peut être plus pour Rantanplan

Merci encore du temps que vous y consacrez.
an1844

[Marco46]

Je vais devoir faire une distinction entre la recette officielle contractuelle (je ne dois pas en attendre grand chose) et la "recette fonctionnelle de ce que l'on attend" (il faut que je trouve un mot de vocabulaire pour simplifié) ... pour nous ... en attendant d'avoir mieux ... ce qui devrait revenir à lister une longue série "d'évolution fonctionnelle" ... donc en quelque sorte faire une recette.

[...]

En résumer:
- il faut que j'abandonne le mot recette, il n'est pas adapté, et surtout je n'ai rein à y attendre;
- il faut que j'invente une formalisation de nos propres tests, parce qu'il semble que cela n'existe pas, et il faut que je lui trouve un nom.

Critères d'acceptations. En anglais acceptance criteria.

C'est ça que tu veux définir en fait. Simplement on fait ça avant les développements normalement

Tu devrais également te documenter sur les user stories. Sans pour autant faire strictement de l'agile il y a derrière ces concepts certaines choses qui pourront t'intéresser.

[el_slapper]

Outre le fait que Marco46 a pointé un truc que j'avais oublié(il est essentiel, en effet, de définir les critères qui définissent le go/nogo),je vais répondre à 2-3 petits points.

(.../...)
Même à moi cela parait évident.

mais ce n'est pas évident pour tout le monde. Et probablement pas pour les gens qui emploient tes services, qui s'imaginent que ça tombe tout cuit, alors que c'est un boulot important(et qui permet parfois de lever des loups dans la spec)

J'adorerais savoir faire cela ... mais d'ailleurs c'est ce que je suis venu demander

ça s'apprend sur le tas, hein. Quand on a les moyens et un client pas pressé, on fait la totale : on teste tous les écrans/traitements un par un, en statique, donnée par données, puis petit à petit on élargit, pour finir par des tests de bout en bout qui reprennent l'intégralité des cas imaginés par les experts métiers. Et pour chaque cas, on met un cas normal, un cas aux limites, un cas hors limites, et tout ce qu'on peut trouver comme cas aberrant possible.

Le sushi, c'est qu'on a rarement les moyens de tout faire, donc on choisit, souvent au pif et à l'expérience, des cas représentatifs. Qu'on pousse dans tous leurs retranchements. Tiens exemple rigolo. Un expert fonctionnel de notre branche écossaise à identifié - et documenté - 1200 cas possibles de comportement sur les listes d'attentes(une part essentielle de la gestion hospitalière pour le NHS, outre manche). Personne n'a jamais testé les 1200 cas. Par contre, en trouvant des grands thèmes qui couvrent à peu près tout, notre gars sur place a collationné une quarantaine de cas qui couvrent l'essentiel des choses que l'on peut rencontrer de manière non exceptionnelle. C'est le genre de choix qui fait un plan de tests. La stratégie de test, c'est décider "on a pas de budget pour tester plus de 40 cas sur les listes d'attente". Le plan de test va choisir les 40 cas représentatifs, décider de ce qu'on va faire dessus, et laisser un petit mot expliquant l'impasse sur les 1160 autres.

Je promet de faire des efforts ... mais j'ai une certaine pression ... loin de là d'être stressé ... mais pressé ils sont (des 2 cotés).

C'est partout pareil, rassure toi. Les commerciaux veulent livrer à tout prix une fonctionnalité dès que le développeur a fini, et déploient de nombreux efforts pour shunter les efforts de la qualité. Pour lui retomber dessus à chaque fois qu'un client trouve un bug - ou que la qualité trouve un bug(et que la livraison est retardée, donc). Dire "merde" diplomatiquement mais fermement est une qualité requise à la qualité.

Comme je ne me souviens pas avoir écris ou lu cowboy, j'imagine que c'est un lapsus.

non, c'est moi qui l'ai ajouté volontairement. Le développement cowboy, c'est quand il n'y a aucune règle, aucun process, et que c'est assumé. Il y a des cas, peu fréquents, ou ça peut être pertinent. Le truc, c'est que souvent, quand on est pressé, on passe sans s'en rendre compte en mode cowboy, et avec des gens qui n'ont pas le niveau, ça multiplie les dégâts.

Intéressant, très intéressant, dans un autre contexte , je serai heureux de suivre une telle formation, ... c'est quoi les pré-requis ?

Faire partie de ma boite. On recherche un chef de projet avec beaucoup de bouteille dans l'hospitalier, si ça t’intéresse - et si tu as l'expérience requise(ils sont très canulants avec ça).

- il faut que j'invente une formalisation de nos propres tests, parce qu'il semble que cela n'existe pas, et il faut que je lui trouve un nom.

plan de tests. C'est ce que tu executes(à la main ou par automates), le plan de tests.