我正与我的客户所在地的一群非常敏锐的开发人员合作。我们正在围绕NullPointerException和其他异常进行正确编码，所以我们没有这些。但是当谈到业务规则时，我们会遇到一些错误，并在已经投入生产时发现问题。我们拥有非常快节奏的环境，并且由管理团队指导生产部署，而不是开发部门。但我们通过了质量保证和数据质量团队的“绿灯”。
在软件开发过程早期找到与业务相关的错误的最佳做法是什么。
答案 0 :(得分：6)
“在软件开发过程早期找到与业务相关的错误的最佳做法是什么。”
有几件事。
用例。
基于用例的整体测试。
基于用例的单元测试。
重要的是将系统 - 作为一个整体 - 与真正的演员联系起来，真正的商业价值。关注技术问题太容易了。为避免狭隘地关注技术问题，请使用用例并对其进行测试。
答案 1 :(得分：3)
User Acceptance Testing专注于这些问题。
答案 2 :(得分：3)
用户故事/用例应具体到足以确定接受评论;验收标准应包括所有业务规则，以防止您描述的情况，如果您的单元测试只是测试技术能力，那么它们是不够的。
你能从你提到的那些事件中学习，为什么他们没有被这些文物所覆盖？
另外，根据我的经验，这是持续集成的第一个好处和“早期和经常交付” - 在编写功能后，您不应该在一两天内发现无效的业务规则。
答案 3 :(得分：2)
我发现FitNesse在许多这样的情况下有所帮助 - 实质上是过度简化，用户指定了“输入数据”的重要示例以及他们期望的相应“输出结果”，以及测试框架检查通信是否正确。检查一下，它不会解决每个错误的业务规则问题，但它会对很多人有所帮助。
答案 4 :(得分：2)
我知道尽早发现业务问题的最好方法是仔细聆听，并提前提出许多澄清问题。 “你的意思是...？”和“怎么样......？”可能会减慢会议速度，但它可以迅速将大量信息提供到桌面上。这听起来像人们在这些对话期间需要在房间内的质量保证和数据质量。
但是，如果是客户的 QA和数据质量的人签署了您后来发现的不正确的东西，他们也有问题，作为供应商/承包商/顾问，这不是你要解决的问题（除了指出它）。
答案 5 :(得分：1)
作为对alf答案的赞美，我想推荐一份全面的指南，User Stories Applied。
答案 6 :(得分：1)
与了解业务的人密切互动。我发现简单的流程图运行良好 - 这些可以用图表形式表示用例，用户更容易理解。
与用户进行早期和频繁的交互也很重要 - 确定用例的每个点的所有数据要求，数据的来源，数据的约束等。使用样本数据的用例对于在这里发现误解。
它还有助于拥有早期原型。 Powerpoint对此很有好处，因为它不会诱使你在早期阶段开始“编码”。
答案 7 :(得分：1)
如果这些业务规则可以（不需要太多努力）在代码中表达，“Design by Contract”可能对您的情况有用。使用断言来确保程序的每个部分都遵守规则。
答案 8 :(得分：1)
你的故事卡应该有
将推动
的创建此外，所有由业务部门设计的用户验收测试都应该在您的自动化功能测试中捕获。
如果您的开发人员使用