Comment encourager le client à faire des tests d'AQ en interne?

14

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:

  1. 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")

  2. 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.

Pas de prise
la source
3
Si un bogue est si petit que les utilisateurs eux-mêmes ne semblent pas se soucier qu'il soit corrigé ou non, pourquoi insistez-vous?
kamilk
2
@kamilk - la réponse courte est que je suis investi dans le fait que mon client se porte bien, soit productif, etc. La réponse longue est qu'il ne s'agit souvent pas simplement d'un "petit" bug - il peut également s'agir d'un problème d'utilisation, implémentation de fonctionnalité manquante, etc. Si je ne suis pas au courant, je ne peux pas le corriger. De plus, les «solutions de contournement» qu'ils proposent sont souvent une perte de temps énorme pour eux ou même pour les versions antérieures du logiciel.
No Grabbing
18
Si vous êtes investi dans la réussite de votre client; vous devriez voir des tests très solides avant de les publier. Les clients ne sont pas des testeurs. Embaucher un testeur, ou faire vos propres tests, ou écrire des tests codés, mais si vous voulez être absolument certain que vos trucs fonctionnent pour vos clients, testez avant de les leur donner.
Jimmy Hoffa
4
@djechlin - il s'agit de tests (et de rapports) du tout. Et un développeur ne peut tester que tant de choses: je ne l'utilise pas comme le font les utilisateurs.
No Grabbing

Réponses:

18

ils n'ont rien de l'attention névrose obsessionnelle au détail des "vrais" développeurs

Préface : Le type de langage que vous utilisez ici est généralement un drapeau rouge pour moi. Quand j'entends des gens parler de "vrais" développeurs ou de la (seule et unique) "bonne" façon de faire les choses, je commence à penser à des développeurs de tunnels de fret visionnaires .

Maintenant, je ne dis pas que vous êtes certainement l'un de ces développeurs (je n'ai pas assez de preuves pour l'affirmer), mais si vous l'êtes, alors vous pourriez bénéficier de cette réponse.

Répondre

Il semble que vous et votre client optimisiez pour différentes choses. C'est un fait malheureux en génie logiciel que souvent les besoins de l'entreprise et les désirs des développeurs ne correspondent pas nécessairement.

Les développeurs de logiciels sont souvent des gens passionnés qui se concentrent sur l'amélioration. Ils aiment améliorer les performances des logiciels, le processus de développement, les processus métier, les méthodes de communication, etc. Et c'est génial. Se concentrer sur ces choses est ce qui sépare les artisans et les artisanes des pousseurs de clavier stupides.

Mais, votre client n'est pas un artisan logiciel. Votre client est une entreprise avec un ensemble de priorités complètement différent. Et, parfois, ces priorités semblent ridicules pour nous, artisans des logiciels ... mais c'est uniquement parce que nous optimisons pour différentes choses.

Les entreprises veulent souvent optimiser des choses comme la mise en marché anticipée et les économies de coûts à court terme. Ce faisant, ils devront peut-être sacrifier des éléments tels que l'assurance qualité, l'expérience utilisateur, les économies de coûts à long terme et d'autres éléments qui font vibrer les développeurs.

Est-ce une mauvaise chose? Enfin, pas forcément. Je ne peux pas parler pour toutes les entreprises, mais d'après mon expérience, mes clients font ces choses afin d'augmenter leur propre ROI (retour sur investissement). Faire des choses comme l'assurance qualité, le raffinement UX et la planification à long terme leur offre un retour sur investissement plus faible. Pire encore, de nombreuses entreprises ont des structures d'investissement qui ne récompensent que les gains à court terme, par opposition aux approches durables et aux gains à long terme.

Ainsi, bien que vous puissiez essayer de vendre l'idée d'AQ à votre client, vous perdez peut-être votre temps et tendez votre relation avec eux. Dans le meilleur des cas, vous aurez quelqu'un désireux d'essayer vos idées (peu probable). Dans le pire des cas, vous devrez convaincre toute l'entreprise de retravailler ses structures d'incitation afin que les investissements à long terme tels que l'AQ soient récompensés. Dans les deux cas, vos chances de succès sont faibles.

MetaFight
la source
4
+1, en essayant de changer le fonctionnement interne d'un ensemble différent d' affaires , car il ne semble pas le droit de vous élimenera généralement une courte relation. Un professionnel doit indiquer s'il peut prévoir des problèmes graves, en particulier s'il peut également conseiller sur la façon de les atténuer. Cependant, si les problèmes sont si petits que la société ne prend même pas la peine de les signaler, la meilleure chose que vous pouvez faire est d'envoyer un rappel amical de temps en temps qu'il peut y avoir eu un gain de temps si X ou Y sans insister.
Ordous
-1 car, bien que ce soit un article bien écrit, cela ne répond pas vraiment à la question de savoir comment vous y prendriez. La réponse est que vous le faites d'une manière très similaire, vous convainquez les développeurs réguliers de tester: montrez que les tests aident à réduire les risques. Moins de risques == moins de problèmes de production au milieu d'une démo client.
David dit de rétablir Monica
Non - loin de la base mais merci d'avoir répondu.
No Grabbing
@DavidGrinberg, tout va bien, à moins que la réduction du nombre de problèmes de production ne vaille la peine / le coût / le temps pour le client. Si c'est le cas, aucune logique de développeur ne les convaincra de sacrifier leur retour sur investissement juste pour vous satisfaire. Et c'est pourquoi je n'ai pas répondu au comment de la question et je me suis plutôt concentré sur un défaut potentiel dans sa prémisse.
MetaFight
artisans :-)
Toni Leigh
10

La question intéressante est de savoir quand vous êtes payé, et non pas si votre client fait ses propres tests.

  • si vous êtes payé en fonction de votre temps, pas de problème.
  • si vous êtes payé à l'avance, pas de problème.
  • si vous êtes payé lorsque le client déclare le projet «terminé», gros problème.

Le problème est de savoir comment savoir quand le client accepte le logiciel et vous paiera. Cela ne fonctionne clairement pas lorsque le client modifie continuellement le projet avec de nouvelles demandes vaguement définies. Si cela signifie que le jour de paie est toujours différé - et devient plus improbable à chaque demande - cela devient intenable pour vous.

Un contrat fixe qui spécifie soigneusement toutes les fonctionnalités et définit les conditions dans lesquelles le client acceptera ces fonctionnalités est clairement très inconfortablement strict, mais il vous permet de planifier le projet à l'avance (également le prochain projet). Il garantit également que vous obtiendrez votre argent pour le logiciel que vous avez livré, s'il est à la hauteur des spécifications. Dans un tel scénario, la seule responsabilité d'un client est pendant la phase de définition du contrat et à la fin des tests d'acceptation .

Ces tests d'acceptation effectués par un client sont distincts des autres formes de tests:

  • tests unitaires
  • tests d'intégration système
  • tests d'utilisabilité
  • tests de charge
  • tests préliminaires

Dans la mesure du possible, vous anticipez les tests d'acceptation et les réalisez vous-même avant de livrer la fonctionnalité afin d'éviter toute gêne. Mis à part les tests d'acceptation (qui mesurent uniquement l' exécution du contrat , pas la qualité du logiciel ), toute l'assurance qualité est de votre responsabilité. En particulier, votre client n'a pas nécessairement un état d'esprit QA, les antécédents techniques nécessaires ou l'obligation contractuelle de faire QA. De plus, je trouve l'externalisation de la chasse aux bogues au client assez peu professionnelle.

Cela ne veut pas dire que les bugs ne se produiraient pas. En supposant que vous ayez une relation basée sur un projet avec votre client, vous voudrez faire la différence entre être courtois et fournir rapidement des correctifs et expliquer qu'il a accepté la version actuelle comme suffisante pour ses besoins - les changements importants nécessitent un nouveau contrat. Si vous avez un contrat d'assistance en cours, vous devrez bien sûr vous en tenir à votre niveau de service convenu.

Dans un environnement agile, il est plus important de répondre aux besoins des clients que de respecter la lettre du contrat, mais vous voudrez toujours être payé. Par conséquent, de nombreuses méthodologies de projet orientées agile valorisent l'interaction étroite avec le client, au point que le client pourrait faire partie de l'équipe. Vous pourriez alors toujours parler à ce «propriétaire du produit» pour clarifier les points nécessaires. Étant donné que le bon de commande a le pouvoir de vous accorder le temps de travailler sur toute fonctionnalité qu'il juge utile, cela peut fonctionner même lorsque vous commencez avec des besoins vagues du client. Si vous n'avez pas une communication aussi étroite, vous devrez suivre une approche plus formelle.

  • Lorsque vous découvrez les nouveaux besoins des clients, travaillez avec le client pour les traduire en exigences. Cela aide le client à obtenir ce qu'il veut réellement.
  • Les exigences sont objectivement mesurables - elles sont remplies ou non. Cela évite au client des demi-solutions qui ne font que travailler.
  • Toutes les demandes des clients doivent être fournies par écrit afin que vous puissiez les facturer. Cela les empêche d'être facturés pour des choses sur lesquelles vous avez envie de travailler, comme la réécriture de l'interface entière lorsque vous demandez qu'un bouton soit aligné différemment.

    Beaucoup de communications peuvent se faire en personne ou par téléphone, mais à la fin, vous voudrez un morceau de papier pour documenter que le client voulait que vous travailliez sur ces exigences. Dans les cas simples, il pourrait être suffisant de récapituler un appel téléphonique et de leur envoyer un e-mail pour vérifier ce qu'ils vous ont demandé de faire.

Les rapports de bogues sont toujours difficiles. Si vos clients sont eux-mêmes des développeurs, cela devrait vous aider car ils peuvent comprendre vos besoins: avoir des étapes claires pour se reproduire. Un moyen simple d'obtenir des informations puissantes consiste à activer la journalisation dans le logiciel déployé. À condition que les problèmes de confidentialité des données puissent être résolus, exiger que chaque rapport de bogue soit associé au journal actuel garantit non seulement une communication écrite, mais vous indique également ce que l'utilisateur a réellement fait (contrairement à ce qu'il pensait qu'il essayait de faire) .

amon
la source
1
L'argent n'est pas le problème (je suis sur une retenue mensuelle - je suis payé que je code ou non). C'est comment pousser leur culture de bureau ... ou quelque chose que je ne comprends pas.
No Grabbing
2

La façon d'encourager la communication des bogues est d'encourager une communication fréquente et granulaire des fonctionnalités. Si vous formez une entreprise à qui elle peut demander n'importe quoi sans cérémonie, elle utilisera également cette fonctionnalité pour les bugs mineurs. Abandonnez la modification du flux de travail de votre client, à moins que ces changements ne lui facilitent la vie.

Il est difficile de faire effectuer des tests en interne à votre client, mais il n'est pas aussi difficile qu'il le semble de signaler les bogues. Le moyen d'obtenir plus de commentaires consiste à réduire la friction de l'utilisateur ... même si cela signifie transférer une partie de cette friction à vous-même.

  1. Utilisez des outils plus simples, même si ces outils sont inadéquats et inappropriés. Par exemple, BaseCamp est un outil de suivi des bogues assez horrible (car il est destiné à la gestion de projet), mais les gens sont réellement prêts à l'utiliser.

  2. Étant donné que les suiveurs de bogues que nous utilisions ne prenaient pas en charge le copier-coller d'image, j'ai en fait écrit un programme trivial qui copie l'image du presse-papiers actuelle sur le disque (en tant que Guid), puis copie le Guid dans le presse-papiers. Après une formation minimale, un utilisateur peut joindre des images du presse-papiers aux problèmes en appuyant simplement sur l'écran d'impression, en cliquant sur un bouton, puis en le collant dans la boîte de dialogue de sélection de fichier de l'outil de soumission de bogues.

Une capture d'écran (éventuellement modifiée dans MS Paint avec des annotations) et 1-2 phrases suffisent pour identifier la plupart des fonctionnalités / bugs.

Ces deux suggestions ciblent les points de friction que j'ai rencontrés, et ces deux suggestions ont augmenté le rapport de plus de 10. Cependant, vous devrez cibler vos propres points de friction.

Brian
la source
Cette réponse va droit au but. Vous voulez qu'ils mettent en œuvre des protocoles de test rigoureux: c'est très peu probable, surtout si cela vient de l'extérieur de l'organisation (par exemple vous). La meilleure chose à faire dans ce cas, puisque vous êtes payé de toute façon, est de rendre le plus indolore possible pour vous signaler des bogues. Si vous êtes vraiment déterminé à effectuer des tests approfondis, faites-le vous-même et apprenez-en plus sur les processus métier si vous en avez besoin ... C'est une triste réalité que de nombreuses entreprises ne donneront jamais la priorité aux tests.
DrewJordan
1

Facilitez les tests pour votre client, mais rendez très difficile pour votre client d'utiliser de nouvelles fonctionnalités dans une version non testée en production. Cela peut être accompli comme suit:

Chaque fois que vous livrez une nouvelle fonctionnalité, vous l'implémentez d'abord dans une "version bêta", clairement marquée d'un signe "pas pour la production". Vous mettez cette version bêta à la disposition du client pour les tests. Vous fournissez également la dernière "version de production" qu'il utilisera pour la production réelle (sans les nouvelles fonctionnalités, mais avec les dernières corrections de bugs), et vous refusez de transférer les nouvelles fonctionnalités bêta dans la version de production jusqu'à ce que vous receviez une rétroaction que quelqu'un de le côté client l'a au moins essayé en premier.

Si le client commence à utiliser la version bêta sur ses données de production réelles bien qu'il affiche toujours un gros message "Pas pour une utilisation en production" chaque fois qu'il démarre le programme, alors vous ne pouvez pas l'aider, mais au moins vous avez précisé que chaque fois qu'il perd la production travailler parce qu'il a utilisé la bêta à de mauvaises fins que c'est clairement sa faute. Si le client n'apprend pas de cela, vous pouvez envisager de désactiver la capacité de votre client à utiliser la "bêta" en production en désactivant certaines fonctions cruciales telles que l'enregistrement des résultats sur le disque dans la "bêta", si cela est nécessaire.

Fournir une «version bêta» distincte vous obligera à établir un contrôle de version / une gestion de configuration appropriés, afin que vous puissiez gérer une branche de production et une branche de test bêta côte à côte sans tracas. Mais puisque vous travaillez avec Github, je suppose que vous utilisez déjà quelque chose comme GIT, ce qui rend ce type de gestion très simple.

Doc Brown
la source
Je ne suis pas vraiment d'accord avec le premier paragraphe. Souvent, les gens se rendent vraiment compte que quelque chose est important mais ne le font pas (arrêter de fumer par exemple). Les tests sont un exemple classique de quelque chose comme ça: même si vous réalisez que c'est vraiment important, cela demande beaucoup de discipline pour ne pas prendre de raccourcis quand il est confronté à des délais, etc. Cependant, l'idée de la bêta est bonne, étant donné la désir déclaré du client de s'améliorer dans les tests.
J'utiliserais également cela comme une opportunité pour aborder le point # 1. Proposer un processus complet au client où de nouvelles exigences sont écrites, convenues, testées dans un environnement hors production, puis publiées.
Je marque les nouvelles versions comme "alpha" ou "pré-version - pas pour la production", et je fais tout le truc "jalon" de github avec des problèmes (bugs, nouvelles fonctionnalités à tester, etc.) mais il n'a pas fait de différence. Toute la situation me déconcerte. J'ai proposé des trucs comme un truc mensuel de "pizza day" pour tester leur bug (2-3 personnes), un "vote pour votre problème préféré / le plus ennuyeux". C'est un peu bizarre - pourtant ils utilisent mon logiciel pour des présentations majeures tout le temps, donc je ne comprends pas pourquoi il n'y a pas plus de refoulement. Je suppose que cela tombe dans "une autre chose à faire / pas mon travail"
No Grabbing
@TOMATO: refusez-vous strictement de transférer des fonctionnalités de la version préliminaire à la version de production, jusqu'à ce que le client vous dise qu'il a testé la fonctionnalité? Votre client essaie-t-il de contourner ce refus?
Doc Brown
2
+1 pour la version bêta clairement indiquée: si vous distribuez la version de test en violet criard, avec une énorme bannière clignotante verte en haut de l'écran principal criant "VERSION D'ESSAI - PAS POUR UNE UTILISATION EN PRODUCTION - NON SÉCURITAIRE - AAARGH! ", ils ne l'utiliseront pas pour des présentations ni même là où un client pourrait le voir. Vous pouvez retenir la version de production propre (prenez-la en otage, si vous voulez) jusqu'à ce qu'ils donnent une sorte de rétroaction utile.
Christian Severin