ISTQB AL-TM连载系列17：清楚地汇报而非解决缺陷

1. 可以减少被开发人员拒绝从而打回来的缺陷数量。
2. 加快缺陷修复的速度。
3. 增加测试人员测试能力的可信度。
4. 加强开发人员和测试人员之间的团队合作。
5. 更加高效地提高软件质量。

1. 精简的：缺陷的描述应该是清晰而简要的。在缺陷报告中要剔除不必要的无关的信息。在缺陷报告中包含所有缺陷相关的信息，并且确实是相关的，多余的信息只会使得缺陷的描述含糊不清。
2. 正确的：提交的问题确实是一个缺陷。假如提交的缺陷最后证明是由于测试人员的理解错误或者配置错误引起的，可能使得测试人员在开发人员面前失去可信度，同时会对彼此之间的沟通带来一些影响。当然，不能因为害怕提交错误的缺陷，就对可能出现的缺陷视而不见，这比提交错误的缺陷影响更恶劣。因此，在提交缺陷报告之前，测试人员应该针对以下方面仔细检查：确保搭建了正确的测试环境、确保测试的版本是正式的测试版本、确保不是前面执行的测试用例配置的信息干扰了测试结果、确保网络通信没有问题、确保测试人员正确地理解了产品的工作原理等。
3. 中立的：对缺陷及其特征进行实事求是的描述，避免夸张、幽默、讽刺的态度，避免在测试缺陷报告中带有个人感情色彩，因为这种感情色彩可能会影响团队之间的合作和沟通。
4. 准确的：准确而明白地描述问题，不仅对做了什么进行描述，而应该对发生或者发现了什么进行描述。
5. 隔离：尽量寻找简短的步骤复现缺陷，即将缺陷进行隔离，例如：缺陷所属模块、缺陷的触发条件等。对问题进行隔离定位，很大程度上体现了测试人员对测试对象的了解程度，同时可以提高测试效率和项目整体的效率。
6. 推广：确定系统其他部分是否可能也存在同样的问题，以及使用不同的数据时是否也会出现这种问题等。测试人员在缺陷方面的推广有助于节约开发人员修正缺陷的时间，提高缺陷解决的效率。
7. 复现：确定系统是否可以复现这个问题，以及复现该缺陷的步骤。对于能够复现的问题，应该提供简单的步骤和输入。对于难以复现的问题，尽量提供一些告警信息、日志信息；或者问题发现时，可以和开发人员一起进行跟踪调试和定位。对于实在无法复现的问题，在缺陷报告中应明确说明，并且在后续测试中持续跟踪。
8. 证据：如同写测试用例需要测试条件一样，在缺陷报告中，需要提供测试的期望结果和实际得到的输出结果或者行为之间的差距，以及提供测试的依据。
9. 评审：在提交缺陷报告之前，最好有一个有经验的测试人员阅读一遍。

测试人员在提交缺陷报告的时候，不要试图在缺陷报告中解决问题。因为测试人员和开发人员的角色和职责是不一样的，调试和解决问题是开发人员的主要职责。

[文章来源]：专注于测试能力改进