如何在软件开发实践的早期找到与业务相关的错误？

Question

我正与我的客户所在地的一群非常敏锐的开发人员合作。我们正在围绕NullPointerException和其他异常进行正确编码，所以我们没有这些。但是当谈到业务规则时，我们会遇到一些错误，并在已经投入生产时发现问题。我们拥有非常快节奏的环境，并且由管理团队指导生产部署，而不是开发部门。但我们通过了质量保证和数据质量团队的“绿灯”。

在软件开发过程早期找到与业务相关的错误的最佳做法是什么。

Answer 1

“在软件开发过程早期找到与业务相关的错误的最佳做法是什么。”

有几件事。

1. 用例。

2. 基于用例的整体测试。

3. 基于用例的单元测试。

重要的是将系统 - 作为一个整体 - 与真正的演员联系起来，真正的商业价值。关注技术问题太容易了。为避免狭隘地关注技术问题，请使用用例并对其进行测试。

Answer 2

User Acceptance Testing专注于这些问题。

Answer 3

用户故事/用例应具体到足以确定接受评论;验收标准应包括所有业务规则，以防止您描述的情况，如果您的单元测试只是测试技术能力，那么它们是不够的。

你能从你提到的那些事件中学习，为什么他们没有被这些文物所覆盖？

另外，根据我的经验，这是持续集成的第一个好处和“早期和经常交付” - 在编写功能后，您不应该在一两天内发现无效的业务规则。

Answer 4

我发现FitNesse在许多这样的情况下有所帮助 - 实质上是过度简化，用户指定了“输入数据”的重要示例以及他们期望的相应“输出结果”，以及测试框架检查通信是否正确。检查一下，它不会解决每个错误的业务规则问题，但它会对很多人有所帮助。

Answer 5

我知道尽早发现业务问题的最好方法是仔细聆听，并提前提出许多澄清问题。 “你的意思是...？”和“怎么样......？”可能会减慢会议速度，但它可以迅速将大量信息提供到桌面上。这听起来像人们在这些对话期间需要在房间内的质量保证和数据质量。

但是，如果是客户的 QA和数据质量的人签署了您后来发现的不正确的东西，他们也有问题，作为供应商/承包商/顾问，这不是你要解决的问题（除了指出它）。

Answer 6

作为对alf答案的赞美，我想推荐一份全面的指南，User Stories Applied。

Answer 7

与了解业务的人密切互动。我发现简单的流程图运行良好 - 这些可以用图表形式表示用例，用户更容易理解。

与用户进行早期和频繁的交互也很重要 - 确定用例的每个点的所有数据要求，数据的来源，数据的约束等。使用样本数据的用例对于在这里发现误解。

它还有助于拥有早期原型。 Powerpoint对此很有好处，因为它不会诱使你在早期阶段开始“编码”。

Answer 8

如果这些业务规则可以（不需要太多努力）在代码中表达，“Design by Contract”可能对您的情况有用。使用断言来确保程序的每个部分都遵守规则。

Answer 9

你的故事卡应该有

• 验收标准

将推动

的创建

• 测试驱动单元测试（首先编写单元测试）
• 自动功能测试
• 完全回归测试至少每天运行（如果不是每次检入）

此外，所有由业务部门设计的用户验收测试都应该在您的自动化功能测试中捕获。

如果您的开发人员使用

• 对开发
• 测试驱动开发
• 持续整合
• 重构

然而，在UAT和生产过程中，这种做法会将缺陷推向零或接近零。在UAT或生产中发现的缺陷将是例外。如果你不遵循这些练习，很多团队的速度将会丢失并用于修复缺陷。我们发现，如果开发中发现的缺陷成本为1x，则在功能测试期间需要修复2x，在UAT期间需要修复3x，在生产中修复需要4x修复。正如您所看到的，左侧驾驶缺陷（在开发生命周期的早期阶段）不仅仅是为自己付出了代价。