我们是否应该在Bug报告中包括“缺陷影响分析”部分？

Question

当测试人员记录一个新的缺陷/ Bug时，是否应该有一节讨论Bug对业务的影响以及它会影响多少模块/特性？

这是一个很好的错误报告实践吗？

Answer 1

是的，在所有bug报告中都应该有一定程度的影响报告。

如果遵循ISTQB/ISEB标准，则通过严重性和优先级度量来实现这一点。

严重程度是功能影响，等级从1到5 (1 -崩溃，5-化妆品问题)

优先考虑的是业务影响和修复它的愿望，分级为1到5 (1 -现在修复！，5-修复它最终)

增加这些措施有助于评估解决问题的紧迫性，以确定问题的全部影响。

例如:我们在一个应用程序中发现两个bug，它们都会使系统崩溃。因此两者都是严重程度1。

但是，如果一个错误只发生在August....the优先级的第三个星期三被称为Zaphod的客户端，那么它就会降低，因为它不太可能经常发生。

分配优先级可能涉及与业务所有者/分析师的讨论，以确保对影响的充分理解，并应构成缺陷管理策略的一部分。

Answer 2

经典的回答是：“视情况而定”

这取决于测试人员参与开发过程的强度。

如果他知道这个问题影响到两个不同的产品，这些产品来自依赖同一个实现的两个独立的分支，他可以在他的bug报告中声明这一点。

一种更实用的方法是尝试在第二个产品/模块/特性中复制相同的问题，并提交另一个bug报告。

Answer 3

我认为QA输入bug是公平的，因为他们认为bug的影响/严重性是什么。这可以很容易地被下游的其他人(例如，对问题进行分类的人、项目经理等)进行更新和重写，但是一个好的测试人员应该知道，如果一个问题是一个节目阻止者，如果它会成为最终用户的一个大问题，也许它只是恼人的，等等。