如何鼓励客户进行内部质量检查？

更新/说明我的客户了解他们进行内部测试的必要性，并且他/他们总是发誓他们会“做得更好”（即做某事），但那没有发生。他们没有外部测试的预算。我想我正在（模糊地，我​​承认）问什么可以灌输“尽早测试，经常测试，对目标机器的精神进行测试？

问题：如何鼓励用户花时间明确测试和报告新版本的问题，而不是在生产项目中“按需测试”。

背景：我有一个小客户，为此我编写了一套多媒体演示工具。他们是一个很好的客户，我们有着良好的关系。该项目正在进行中，并随着我们的进行添加了功能。

我有两个问题：

1. 功能定义通常是通过电话即时进行的，可能会进行更改，修订和撤销。（有点像肯尼迪的“我们将登月并做其他事情” –我一直对其中的“其他事情”感到很开心）

2. 实际上，最终没有进行质量检查测试。

我可以或多或少地处理＃1。这个客户甚至不会在会议前阅读规范，更不用说撰写规范了。我习惯了。这是我遇到的问题的项目2：他们不测试或不会测试新版本。他们所做的是将其用于生产，因此，当出现错误时，他们要么找到解决方法而不报告，要么急着着手进行该项目，从而使错误报告模糊不清。

关于这一切，我们进行了很多讨论，但是我只能稍微推翻一下（例如，我们使用github进行问题跟踪-尽管我大多使用它）。根本原因有两个：它们是一家小型咨询公司，没有（或认为没有）测试资源（也没有预算将其外包）。和文化的：尽管他们认为自己是“开发人员”，但实际上他们只是多媒体软件包的用户。（例如，他们对“真实”开发人员的细节没有强迫症）。

如您所料，这会影响到我：没有反馈，我无法告诉您功能是否完整（请参阅＃1），或者是否还有其他后果。这也让我有点懒。

他们没有强迫症，只关注“真实”开发人员的细节

前言：您在这里使用的语言通常对我来说是一个危险信号。当我听到人们谈论“真正的”开发人员或（唯一的）“正确”的做事方式时，我开始思考那些有远见的货运狂热开发人员。

现在，我并不是说您肯定是这些开发人员之一（我没有足够的证据来断言），但是如果您是，那么您可能会从此答案中受益。

回答

听起来您和您的客户正在针对不同的事物进行优化。在软件工程中，不幸的事实是，业务需求和开发人员的需求常常不一定一致。

软件开发人员通常是热衷于即兴创作的人。他们喜欢提高软件性能，开发流程，业务流程，通信方法等。这很棒。专注于这些东西是将工匠和手工艺者与盲目的推键分开的地方。

但是，您的客户不是软件工艺师。您的客户的业务重点完全不同。有时，这些优先级对我们软件技术人员来说似乎很荒谬……但这仅仅是因为我们正在针对不同的事物进行优化。

企业经常希望针对诸如早日投放市场和节省短期成本之类的问题进行优化。为此，他们可能需要牺牲质量检查，用户体验，节省长期成本以及其他使开发人员付诸东流的事情。

那是一件坏事？好吧，不一定。我不能代表所有企业，但以我的经验，我的客户会做这些事情，以增加自己的ROI（投资回报率）。诸如质量检查，用户体验优化和长期计划之类的事情会使他们的投资回报率降低。更糟糕的是，许多企业的投资结构只奖励短期赢利，而不是可持续方法和长期赢利。

因此，尽管您可以尝试将质量检查的想法卖给客户，但可能会浪费您的时间并拉紧与他们之间的关系。在最好的情况下，您会让人急切地尝试您的想法（不太可能）。在最坏的情况下，您必须说服整个公司重新制定激励机制，以使诸如QA之类的长期投资得到回报。无论哪种情况，成功的机率都很低。

有趣的问题是，何时获得报酬，而不是客户是否对自己进行任何测试。

• 如果您根据自己的时间获得报酬，那没问题。
• 如果您提前获得付款，没问题。
• 如果您在客户宣布该项目“完成”时获得报酬，那就是大问题。

问题是您如何知道客户何时接受该软件并向您付款。当客户用含糊不清的新要求不断修改项目时，这显然不起作用。如果这意味着发薪日总是被推迟，并且每次请求都变得不太可能，那么这对您来说就站不住脚了。

固定合同仔细地指定了所有功能，并定义了客户在何种条件下接受这些功能，这显然非常不舒服，但是它允许您提前计划项目（以及下一个项目）。它还保证，如果符合规格，您将可以从自己提供的软件中获得收益。在这种情况下，客户的唯一责任是在合同定义阶段，最后是验收测试。

客户进行的这种验收测试与其他形式的测试是分开的：

• 单元测试
• 系统集成测试
• 可用性测试
• 负载测试
• 发行前测试

在交付功能之前，您将尽可能预期接受测试并亲自进行测试，以免造成尴尬。除了验收测试（仅衡量合同履行情况，而不衡量软件质量）之外，所有质量保证是您的责任。特别是，您的客户不一定具有质量检查心态，必要的技术背景或进行质量检查的合同义务。另外，我发现将漏洞寻找外包给客户非常不专业。

这并不是说不会发生错误。假设您与客户之间存在基于项目的关系，那么您将需要在礼貌和迅速提供修复程序之间走一跳，并说明他们已经接受了足以满足其需求的当前版本-较大的更改需要签订新的合同。如果您有一份持续的支持合同，那么您当然必须遵守约定的服务水平。

在敏捷的环境中，响应客户的需求比遵守合同更为重要，但是您仍然希望获得报酬。因此，许多面向敏捷的项目方法都重视与客户的密切互动，以至于客户可能成为团队的一部分。然后，您可以随时与该“产品负责人”交谈，以阐明任何必要的观点。由于PO有权授予您时间来使用他们认为有价值的任何功能，因此即使从模糊的客户需求入手也可以使用。如果没有这种密切的沟通，则需要遵循更正式的方法。

• 当您了解新的客户需求时，请与客户一起将其转换为需求。这可以帮助客户获得他们真正想要的东西。
• 需求是可以客观衡量的–它们是否满足。这样可以使客户免于只能做那种工作的半解决方案。

• 必须以书面形式提供所有客户请求，以便您可以向他们收费。这样可以避免向您收取您刚刚想做的事情的费用-例如在要求按钮以不同方式对齐时重写整个界面。

  可以亲自或通过电话进行很多沟通，但是最后您需要一张纸记录客户希望您满足这些要求的文件。在简单的情况下，重述电话并向他们发送电子邮件以验证他们要求您执行的操作可能就足够了。

错误报告总是很困难。如果您的客户本身就是开发人员，那么他们应该会有所帮助，因为他们可以了解您的需求：制定清晰的复制步骤。一种获得强大洞察力的简单方法是启用已部署软件的登录。只要可以解决数据隐私问题，就要求每个错误报告都附加当前日志，这不仅可以保证一定的书面沟通，还可以告诉您用户实际做了什么（与他们认为要做的相反） 。

鼓励错误沟通的方法是鼓励频繁，细致地传达功能。如果你培养一个公司，他们可以要求任何与零式上，他们将使用小错误这个功能了。除非对客户的工作流程进行更改，否则请不要进行更改。

让您的客户进行内部测试很困难，但是让他们实际报告错误并不像听起来那样困难。获得更多反馈的方法是减少用户的摩擦……即使这意味着将一些摩擦转移给自己。

1. 使用更简单的工具，即使这些工具不足或不合适。例如，BaseCamp是一个非常糟糕的错误跟踪器（因为它旨在用于项目管理），但是人们实际上愿意使用它。

2. 由于我们使用的错误跟踪器不支​​持图像复制粘贴，因此我实际上编写了一个简单的程序，该程序将当前剪贴板图像复制到磁盘（作为Guid），然后将Guid复制到剪贴板。经过最少的培训，用户只需单击打印屏幕，单击按钮，然后粘贴到Bug提交工具的文件选择器对话框中，即可将剪贴板图像附加到问题上。

屏幕截图（可能在MS Paint中使用注释进行了编辑）和1-2个句子足以确定大多数功能/错误。

这两个建议都针对我遇到的摩擦点，并且这些建议都使报告增加了10倍以上。但是，您将需要针对自己的摩擦点。

使您的客户的测试变得容易，但使客户很难在生产中未经测试的版本中使用任何新功能。这可以通过以下方式完成：

每当您提供新功能时，都首先以“测试版”实现此功能，并明确标有“不用于生产”的符号。您可以将此Beta版本提供给客户端进行测试。您还提供了他将用于实际生产的最新“生产版本”（没有新功能，但已修复了最新的错误），并且您拒绝将新的Beta功能转移到生产版本中，直到获得以下人员的反馈：客户端至少首先尝试过。

如果客户开始在其实际生产数据上使用beta版本，尽管该代码始终在启动程序时始终显示一条大消息“不用于生产”，则您无济于事，但至少您已经清楚地表明，无论何时他放弃生产之所以工作，是因为他将测试版用于错误目的显然是他的错。如果客户端没有从中汲取教训，则可以考虑通过禁用一些关键功能（例如，将结果保存到“ beta”中的磁盘）来禁用客户端在生产中使用“ beta”的功能。

提供单独的“ beta”将迫使您建立适当的版本控制/配置管理，因此您可以轻松地并排管理生产分支和beta测试分支。但是由于您正在使用Github，所以我想您已经使用了类似GIT的工具，这使得这种管理非常简单。