IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Méthodes Agiles Discussion :

Recette ou test de validation d'appli informatique


Sujet :

Méthodes Agiles

  1. #1
    Membre à l'essai
    Homme Profil pro
    Utilisateur courant d'EXCEL
    Inscrit en
    avril 2019
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Utilisateur courant d'EXCEL

    Informations forums :
    Inscription : avril 2019
    Messages : 13
    Points : 16
    Points
    16
    Par défaut Recette ou test de validation d'appli informatique
    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

  2. #2
    Expert éminent sénior
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    4 413
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 4 413
    Points : 18 468
    Points
    18 468
    Par défaut
    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.
    Un problème avec Git ? Essayez la FAQ, sinon posez votre question sur le forum.



    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  3. #3
    Membre à l'essai
    Homme Profil pro
    Utilisateur courant d'EXCEL
    Inscrit en
    avril 2019
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Utilisateur courant d'EXCEL

    Informations forums :
    Inscription : avril 2019
    Messages : 13
    Points : 16
    Points
    16
    Par défaut
    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.

    Citation Envoyé par Marco46 Voir le message
    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.

    Citation Envoyé par Marco46 Voir le message
    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.

    Citation Envoyé par Marco46 Voir le message
    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.

    Citation Envoyé par Marco46 Voir le message
    Quelle est la base de travail du presta ?
    Une super ERP de notre très grand client.
    Un ERP classique à nous.

    Citation Envoyé par Marco46 Voir le message
    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.

    Citation Envoyé par Marco46 Voir le message
    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.

    Citation Envoyé par Marco46 Voir le message
    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

    Citation Envoyé par Marco46 Voir le message
    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.

    Citation Envoyé par Marco46 Voir le message
    Quelle est la nature du livrable ?
    Reformuler pour un gnou.

    Citation Envoyé par Marco46 Voir le message
    Code source ?
    Reformuler pour un gnou.

    Citation Envoyé par Marco46 Voir le message
    Binaire ou package déjà construit ?
    Reformuler pour un gnou.

    Citation Envoyé par Marco46 Voir le message
    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

    Citation Envoyé par Marco46 Voir le message
    Quelle est leur base de travail ?
    Reformuler pour un gnou.

    Citation Envoyé par Marco46 Voir le message
    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

  4. #4
    Expert éminent sénior
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    4 413
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 4 413
    Points : 18 468
    Points
    18 468
    Par défaut
    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.
    Un problème avec Git ? Essayez la FAQ, sinon posez votre question sur le forum.



    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  5. #5
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    6 513
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 513
    Points : 30 480
    Points
    30 480
    Par défaut
    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.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  6. #6
    Membre à l'essai
    Homme Profil pro
    Utilisateur courant d'EXCEL
    Inscrit en
    avril 2019
    Messages
    13
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Utilisateur courant d'EXCEL

    Informations forums :
    Inscription : avril 2019
    Messages : 13
    Points : 16
    Points
    16
    Par défaut
    Bonjour,

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

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

    Citation Envoyé par el_slapper Voir le message
    J
    Voilà, c'est en vrac, ..., je vous laisse mettre de l'ordre dans tout ça.
    je vais essayer de faire de faire court.

    Citation Envoyé par Marco46 Voir le message
    ... Ç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.

    Citation Envoyé par el_slapper Voir le message
    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.

    Citation Envoyé par el_slapper Voir le message
    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.

    Citation Envoyé par Marco46 Voir le message
    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.
    Citation Envoyé par Ryu2000 Voir le message
    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, ...

    Citation Envoyé par Marco46 Voir le message
    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 ...

    Citation Envoyé par Marco46 Voir le message
    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

    Citation Envoyé par Marco46 Voir le message
    Assurez-vous de provisionner l'environnement avec un jeu de données qui soit réaliste.
    Nous avons OK

    Citation Envoyé par Marco46 Voir le message
    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

    Citation Envoyé par el_slapper Voir le message
    .... 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

    Citation Envoyé par el_slapper Voir le message
    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).

    Citation Envoyé par el_slapper Voir le message
    d'agile(avec des changements fréquents qui échappent à la hiérarchie),
    j'en reste à Ryu2000.

    Citation Envoyé par el_slapper Voir le message
    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.

    Citation Envoyé par el_slapper Voir le message
    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

    Citation Envoyé par el_slapper Voir le message
    .....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

  7. #7
    Expert éminent sénior
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    4 413
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 4 413
    Points : 18 468
    Points
    18 468
    Par défaut
    Citation Envoyé par an1844 Voir le message
    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.
    Un problème avec Git ? Essayez la FAQ, sinon posez votre question sur le forum.



    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  8. #8
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    6 513
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 513
    Points : 30 480
    Points
    30 480
    Par défaut
    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.

    Citation Envoyé par an1844 Voir le message
    (.../...)
    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)

    Citation Envoyé par an1844 Voir le message
    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.

    Citation Envoyé par an1844 Voir le message
    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é.

    Citation Envoyé par an1844 Voir le message
    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.

    Citation Envoyé par an1844 Voir le message
    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).

    Citation Envoyé par an1844 Voir le message
    - 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.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

Discussions similaires

  1. test de validation
    Par skillipo dans le forum Langage
    Réponses: 3
    Dernier message: 11/09/2007, 14h26
  2. test de Validation de formulaire
    Par Hous321 dans le forum Général JavaScript
    Réponses: 2
    Dernier message: 18/05/2007, 23h13
  3. Réponses: 4
    Dernier message: 07/07/2006, 19h17
  4. Test de validation??
    Par questionneuse dans le forum Test
    Réponses: 3
    Dernier message: 20/12/2005, 09h11
  5. test et validation de votre programme!!!
    Par l'indien dans le forum C
    Réponses: 8
    Dernier message: 25/06/2003, 15h43

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo