Mise à jour / clarification Mon client comprend la nécessité de ses tests internes et il / elle jure toujours qu'il "fera mieux" (c'est-à-dire qu'il fera quelque chose) mais cela n'arrive tout simplement pas. Ils n'ont pas le budget pour les tests extérieurs. Je suppose que je demande (vaguement, je le reconnais) ce qui pourrait instiller un "test tôt, tester souvent, tester sur la philosophie des machines cibles?
Question: comment encourager les utilisateurs à prendre le temps de tester explicitement et de signaler les problèmes avec les nouvelles versions, et non à "tester au fur et à mesure" dans les projets de production.
Contexte: J'ai un petit client pour qui j'ai écrit une suite d'outils de présentation multimédia. C'est un bon client et nous avons une bonne relation. Le projet est en cours, ajoutant des fonctionnalités au fur et à mesure.
Il y a deux problèmes que j'ai:
La définition des fonctionnalités se fait à la volée, souvent par téléphone, sous réserve de modifications, de révisions, de renversements. (un peu comme Kennedy "Nous irons sur la lune et ferons les autres choses" - j'ai toujours été amusé par la partie "autres choses")
Pratiquement aucun test d'assurance qualité n'est effectué de leur côté.
Je peux faire face au # 1, plus ou moins. Ce n'est pas un client qui lirait même une spécification avant une réunion, sans parler d'en rédiger une. J'en ai l'habitude. C'est l'élément n ° 2 avec lequel j'ai un problème: ils ne testent pas ou ne testeront pas les nouvelles versions. Ce qu'ils font, c'est de les utiliser pour la production, donc lorsque des bogues surviennent, soit ils trouvent une solution de contournement et ne le signalent pas, soit ils sont tellement pressés de poursuivre le projet, que les rapports de bogues sont vagues.
Nous avons eu de nombreuses discussions à ce sujet, mais je n'ai pu que les pousser un peu (par exemple, nous utilisons github pour le suivi des problèmes - bien que je l'utilise principalement). Les raisons profondes sont doubles: elles sont une petite société de conseil et n'ont pas (ou ne pensent pas qu'elles ont) les ressources pour les tests (ni le budget pour l'externaliser). Et culturel: bien qu'ils se considèrent comme des «développeurs», ils ne sont en réalité que des utilisateurs d'un progiciel multimédia. (Par exemple, ils n'ont rien de l' attention névrose obsessionnelle aux détails des "vrais" développeurs).
Cela m'affecte comme vous vous en doutez: sans retour je ne peux pas dire si une fonctionnalité est complète (voir # 1), ou s'il y a d'autres conséquences. Cela me rend aussi un peu paresseux.