我过去开发的产品和我现在开发的产品都有一个相当大且复杂的矩阵，包含可能的配置、工作流程和数据场景。不开玩笑，一个产品有接近（如果不超过）100 个布尔配置标志，不一定都在一个地方，但它们中的许多相互不兼容（如果我将此位设置为 true，我无法使用激活时激活的功能我将该位设置为 false），而没有在应用程序中进行任何真正的内部验证以防止无效配置。此外，虽然该产品的大多数用户使用标准配置，但所有用户都有一些非常独特的配置组合。
该产品的许多新功能开发都是由客户驱动的，因为客户提交了带有要求的更改请求，并且根据这些要求进行了开发。但是在变更单的这些要求中，对于客户的现有配置并不总是透明的，因此对于那些非标准配置的风险因素是什么也不是很清楚。由于新功能一旦发布，就会发布给所有具有当前维护合同的现有客户，风险管理要求我们将大部分时间和精力集中在那些常用配置上。
然而，在过去和现在，我都经历过很多情况，这些非标准配置对我们造成了严重的伤害。真正了解这些的唯一方法是拥有客户端当前配置的精确副本。但是对于拥有数百个客户端的客户端群，每个客户端都有不同的配置，通过所有客户端数据运行测试以进行 EVER 开发工作似乎并不切实际。
因此，有时需要在测试过程中使用客户端数据。但也需要优先考虑那些对大多数客户产生最广泛影响的测试用例。在某种程度上，这些似乎是相互冲突的需求。
那么问题是：构建和修改如此高度复杂的项目的软件开发组织如何确定在发布前测试过程中何时使用客户数据，同时仍保持满足交付期限所必需的时限风险评估？