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

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.

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.

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

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.

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.