Le sujet est clair pour qq’un d’expérimenté sur le sujet.
Rassure toi, je ne suis pas sur cette mission.
Il n’est donc pas question de travailler avec moi…
Ben au dela de l’offre d’emploi, qques éléments intéressants sur le testing. Certes tes arguments sont valables, et il est vrai que mettre en place une procédure de tests est nettement bénéfique en terme de bugs et de temps passé en correction par la suite.
Malheureusement, mettre en place la procédure prend du temps, et j’ai été amené à travailler dans un contexte où le projet a été sous vendu uniquement pour le gagner (et faire une comm pour le commercial). Du coup, pression pour rendre un bousin dans les temps, avec une vision à super court terme, donc testing à l’arrache (et donc connerie sur connerie à l’arrivée).
Je suis tompbé sur des personnes sans vision à moyen terme, et passer du temps (non facturable à mettre en place des processus), ça ne sert à rien, …
Pour du test utilisateurs, un message sur la liste ErgoIHM est souvent rentable.
Richard dit:Aucun intérêt pour les éditeurs de logiciels tels que ceux que je côtoies actuellement.
En générale, il y a un coeff 2 (en euro) entre une année de dev+exploitation "empirique" et un cycle projet qui intègre une démarche structurée en terme de test.
Comment vendre de la maintenance quand on n'a pas de bugs à corriger ?
Blue dit:Richard dit:Aucun intérêt pour les éditeurs de logiciels tels que ceux que je côtoies actuellement.
En générale, il y a un coeff 2 (en euro) entre une année de dev+exploitation "empirique" et un cycle projet qui intègre une démarche structurée en terme de test.
Comment vendre de la maintenance quand on n'a pas de bugs à corriger ?
La maintenance corrective (correction de bugs) ne se vend théoriquement pas.
C'est donc une perte sèche pour l'éditeur.
Sans parler des pertes en image et en confiance...
Maintenant, ne pas trop se préoccuper des bugs parcequ'on arrive à vendre les corrections à un client est une démarche suicidaire.
Comme anecdote, je connais une banque qui ne fait plus évoluer sa date système depuis le 31 décembre 1999, de peur (avérée) de passer l'an 2000. Imaginez les conséquences d'une telle situation pour cette banque et pour l'éditeur responsable de cette situation.
Richard dit:C'est la théorie...Blue dit:Richard dit:Aucun intérêt pour les éditeurs de logiciels tels que ceux que je côtoies actuellement.
En générale, il y a un coeff 2 (en euro) entre une année de dev+exploitation "empirique" et un cycle projet qui intègre une démarche structurée en terme de test.
Comment vendre de la maintenance quand on n'a pas de bugs à corriger ?
La maintenance corrective (correction de bugs) ne se vend théoriquement pas.
C'est donc une perte sèche pour l'éditeur.
Sans parler des pertes en image et en confiance...
Maintenant, ne pas trop se préoccuper des bugs parcequ'on arrive à vendre les corrections à un client est une démarche suicidaire.
En pratique, quand tous les éditeurs d'un domaine bien spécifique font ça (dans le domaine de la santé, il y en a 3, voir 4 qui sont capables de fournir des applis pour un hôpital de la taille d'un CHU, enfin, aucun n'est réellement capable, mais il se vend comme tel).
Le domaine de la santé est tellement en mouvement (des textes de lois qui peuvent tout changer du jour au lendemain) qu'un petit éditeur n'a aucune chance de s'adapter à un gros établissement.
Parce que ta mission elle pue.
Rédiger des plans et cahier de tests, ça veut dire que tu pars perdant. Le test se rédige en amont dans l’idéal, et est fait soit par la MOA elle même (tests fonctionnels), soit par le dev (tests unitaires). Mieux vaut un accompagnement qui apprend aux équipes à faire les tests par eux mêmes, avec une usine de build qui les exécute en auto, que des cahiers de tests manuels qui vont être joués à moitié.
Keiyan, concret.
Keiyan dit:Keiyan, concret.
Mais Keiyan qui a un avis un peu trop tranché sur un sujet et un contexte qu'il ne maitrise visiblement pas.
Richard dit:C'est sur qu'avec à peine 10 ans d'expertise dans le domaine...Keiyan dit:Keiyan, concret.
Mais Keiyan qui a un avis un peu trop tranché sur un sujet et un contexte qu'il ne maitrise visiblement pas.
Déjà, précise ton contexte : c'est sur un projet qui se lance, sur un truc déjà en prod, sur un truc déjà foireux ? Quel est l'ampleur du projet (parce qu'entre 1 K€ et 1 M€, c'est pas là même) ? Quelle sont les deadlines ? Au vu de ton annonce partielle, désolé, je maintiens, ça pue la galère.
Keiyan, a déjà vécu ça.
Généralement on fait du test dès le début ou bien après que la tour de jenga se soit vautrée 
Après y peut aussi y avoir un mec bien placé dans une boite d’assurance qui entend parler de test unitaires et de la mythologie extreme programming associée dans un MBA et qui se dit que ca serait trop cool de faire ca à la maison.
Je n’en sais pas beaucoup plus que ce que j’ai dit dans l’annonce.
Mais, à ton avis ; 2 personnes pour concevoir des tests pendant 1 an, c’est plutôt quelle taille de projet ?
Richard dit:Je n'en sais pas beaucoup plus que ce que j'ai dit dans l'annonce.30 jours/hommes dans une administration ?
Mais, à ton avis ; 2 personnes pour concevoir des tests pendant 1 an, c'est plutôt quelle taille de projet ?
Keiyan dit:Richard dit:C'est sur qu'avec à peine 10 ans d'expertise dans le domaine...Keiyan dit:Keiyan, concret.
Mais Keiyan qui a un avis un peu trop tranché sur un sujet et un contexte qu'il ne maitrise visiblement pas.
Déjà, précise ton contexte : c'est sur un projet qui se lance, sur un truc déjà en prod, sur un truc déjà foireux ? Quel est l'ampleur du projet (parce qu'entre 1 K€ et 1 M€, c'est pas là même) ? Quelle sont les deadlines ? Au vu de ton annonce partielle, désolé, je maintiens, ça pue la galère.
Keiyan, a déjà vécu ça.
Pour avoir une certaine expérience dans le domaine de la recette et dans le domaine de la mise en place d'outillage sur des projets, je pense qu'en effet Keiyan a raison...
Après, tout dépend en effet du contexte... et du niveau de qualité des livraisons...
Effectivement, tout dépend du contexte : de la maturité de l’entreprise en terme de Test, de la qualité des documents en input des tests, des conditions de délais et de budget du projet et des objectifs qualités.
Je que j’en sais (ou en devine)
Dans cette mission :
> la qualité du code ne rentre pas en jeu car il ne s’agit que de la conception des tests et pas de leur exécution.
> les concepteurs sont en régie dans un Test Center et donc ne sont ni responsable ni impacté par les délais du projet.
> l’entreprise est assez mature en terme de test car elle a professionnalisée et mutualisée le test.
> l’entreprise est assez exigeante sur la qualité car l’application en question est sa seule source de revenu (eCommerce en CtoC) et que chaque heure d’indisponibilité lui coute un gros paquet d’euros.
J’ai toujours eu du mal à comprendre comment externaliser et industrialiser des processus comme les tests. Pour moi les tests demande une connaissance aigue du logiciel, de sa structure technique et de sa logique métier.
Ocelau, de la vieille école
(mais 5000 bugs , ça me semble tout bonnement énorme, ils ont fait des tests unitaires les développeurs ? )
ocelau dit:J'ai toujours eu du mal à comprendre comment externaliser et industrialiser des processus comme les tests. Pour moi les tests demande une connaissance aigue du logiciel, de sa structure technique et de sa logique métier.
Ocelau, de la vieille école
Ben pour un scénario de test, là, oui je conçois que le côté métier rentre en compte, mais pour des tests bêtes et méchants, ça se conçoit.
Sur le fond tu as raison.
Mais en fait, il est tout a fait possible de concevoir un test pertinent sans connaitre l’application ou le métier.
Le “secret” tient à la qualité de la doc qui te permet de concevoir le test.
Par exemple, pour un test fonctionnel on va chercher l’info dans les specs détaillées. Si les règles de gestion sont bien décrites (et qu’elle référence l’exigence qui a abouti à cette spec) , que les cas d’utilisation sont clairs, exhaustifs, que la Stratégie Détaillée t’indique clairement quelle profondeur et quelle granularité tu dois mettre en œuvre, il n’y aucune raison que tu ne conçoives pas un bon test.
Pour les Tests Métiers, il est préférable de faire écrire les tests par ceux qui ont écrit les Exigences Fonctionnelles.
Mais la encore, on peut faire sans.
pourquoi pas c’est possible, je n’ai pas eu l’occasion de voir en pratique de tel structure de projet.
Ces outils de validation me donnent en tout cas toujours l’impression d’être plus politique qu’efficace : Ca permet d’estampiller un label qualité, de produire du doc et du compte-rendu qui font bien et de décharger finalement les responsabilités d’un bug sur un autre service ou une entité externe. Pas vraiment une logique productive et efficace je trouve mais bon tout le monde y trouve son compte : la boite de test se fait son beurre et l’éditeur a un bouc émissaire et des indemnités en cas de problème
Ocelau, toujours vieille école où on programmait en Vi 
EDIT
Richard dit:Pour les Tests Métiers, il est préférable de faire écrire les tests par ceux qui ont écrit les Exigences Fonctionnelles.
Mais la encore, on peut faire sans.
Tout à fait d’accord. Déjà c’est un principe sain que celui qui contrôle ne soit pas celui qui développe et c’est bien l’expert métier qui est à même de voir si le logiciel répond bien au besoin
ocelau dit:Ces outils de validation me donnent en tout cas toujours l'impression d'être plus politique qu'efficace : Ca permet d'estampiller un label qualité, de produire du doc (...) Pas vraiment une logique productive et efficace (...)
Pas vraiment.
1) il y a qq label test (au sens iso)
C'est ce qu'on appelle des CMM (Capability Maturity Model)
Mais pour l'instant aucune entreprise ne communique sur son niveau de maturité auprès de ses clients.
2) l'objectif du test est avant tout de diminuer la charge de correction, le nombre de bugs et les dysfonctionnements qui en découlent (interruptions de service, erreur de la banque en votre faveur,...)
Donc une pure logique productive et efficace