存储我们的回忆
18030636051
Work hard while others rest

当前位置: 首页 > Bug管理帮助 > bug管理教抹何利用思维优化缺陷管理

bug管理教抹何利用思维优化缺陷管理

发布时间: 2018-12-25 14:40

  在过去,缺陷管理是一个非常明确、易于理解和严格把控的过程,但这些都只不过是无稽之谈。bug管理中,我们要对整个交付团队交付工作软件的整个流程负责,却从未告诉团队究竟应该怎么做。

bug管理教抹何利用思维优化缺陷管理

  如何对敏捷项目进行缺陷管理

  正在进行的缺陷

  场景:交付过程中,在团队内部进行测试时发现了缺陷。

  第一种情况是我希望成为大多数敏捷交付团队运行任何提供新功能的方法的标准。

  在这种情况下,用户故事应该返回给开发人员以解决缺陷,然后重新测试,直到修复缺陷。这里经常有一个关于是否应该以某种方式记录缺陷的辩论。简而言之,这取决于团队知道在开发和测试之间的反馈循环中发生了多少浪费,这是记录缺陷的唯一真正价值。因此,团队使用这些指标或依赖于与故障单一起记录的信息以解决缺陷。

  当您遇到这种类型的缺陷时,我建议您不要重新估计故事的大小,例如故事点数。您的用户故事不应该标记为“完成”,因为它没有完成,不起作用,这点已经通过存在缺陷的事实被证实了。

  “延期”缺陷

  场景:用户故事正在交付过程中,并且由于历史原因或者因为修复开发过程中发现的所有缺陷并不务实,故事被视为“已完成”,以致缺陷被推迟。

  在这种情况下,应该引发一个新的用户故事,因为如果一个缺陷被“推迟”,那么实际上缺陷代表了一个尚未完全实现的故事的子特征。实际上,您已经选择在测试确定缺陷的要求后推迟实施特定的验收标准或子功能。

  回归测试期间发生的缺陷

  场景:应用程序正在进行单独的回归测试或其他一些“后期”测试,并发现缺陷。

  请注意,此类型与类型1之间的重要区别在于测试与特定用户故事的实现分离,或者是因为测试是在用户故事被团队视为“完成”后进行的临时测试,或者是因为无论什么原因,某些类型的测试已经推迟到实施之后。这在安全测试或性能测试中很常见,但有时也包括回归测试,即使在具有相对成熟的敏捷技术的企业中也是如此。

  这些缺陷实际上是技术性债务,处理它们的方法不止一种。大多数团队都没有为这些缺陷记录用户故事或任何内容,这与运行持续集成的团队在“破坏构建”事件中所期望的响应相同。整体效果为团队效率的降低,最迟应在下一次回顾中讨论。

  总而言之,bug管理认为:“完成”的定义应涵盖质量水平。在这种情况下,开发人员应立即修复缺陷并仅在使用指标或通信需要记录时跟踪它。不要重新估计故事,因为这只是将问题伪装成一个糟糕的预期,而要更好地提高质量。