遇到Bug，多问几个为什么，降低漏测率

背景：

测试人员在820版本发现了一个Bug：Bug1

研发人员在824版本修复了该Bug ，

但是又引发了新的Bug：Bug2

研发人员继续修复bug2。

上午我开会回来，测试人员跑过来和我说：研发想在820版本上改bug2。

我提出了几个疑问：

1.为什么要在820版本改？

2.那个824版本上已经修复的bug1在820版本上重新修复吗？

3.研发这次要做哪些改动？

测试人员没有回答。

我让她再去找研发确认。

一会后她过来回复：研发人员之前加的两行代码有问题，这次去掉了一行。

我从她的回答中没有找到我要的答案，又问她：

先不关注他改了几行代码，他改了什么功能。

测试人员回答：加了进程白名单。

我问：把哪些进程加了白名单。

测试人员未回答。

于是我直接给研发打电话，才搞明白问题的来龙去脉。

这中间，我们三个人沟通这一个问题又花了将近半个小时。

如果测试人员有自己拿不准的问题，需要向别人确认时：

1.一定要对这个问题先有自己的理解和分析。

2.准确的抛出自己想要确认的问题。

3.对待问题不要只停留在问题表面，要深入思考，关联思考。

反思：

我以前可能比较关注测试技能的提升，但是有效的沟通也非常重要。每天的忙碌中，可能一部分时间都浪费在无效沟通中。

而且这种无限的沟通可能会带来更多的问题，

比如：

1.测试人员是否能够有效准确的描述bug，是否需要研发花费更多的时间来沟通和确认bug。

2.测试人员在测试时，尤其是验证bug时，能否深入思考bug的影响范围，测试全面，而不是只关注bug本身，否则问题会越测越多。

对于我自己，也要不断的学习有效的沟通方式，去影响组内成员。

按：此文，标题也可以称为「无效沟通」

-

IDO老徐，注：这篇文章，作者 雨停了 ，首发于 「职场在 8 小时内」星球 ，见原文 。

为什么会把这篇文章，分享给各位 ？

1、非常具体的日常工作案例，基本上是 测试工程师每天都会遇到的场景，而且非常考验各位的 「软技能」，这也是很多测试从业者，非常缺的 。

2、除了分享案例，还思考了 价值 & 需要改进的点 ，非常赞 ，值得 每位测试工程师，看看；当然，开发、技术Leader、项目经理等，也建议看看，非常有价值 。

3、不仅是 软件测试工程师 这个 职业，以及不仅是工作；在日常生活中，遇到的问题，多问几个为什么 ，你就能更系统性的了解这个问题 。

4、还记得老徐曾经分享的，「测试准入标准么」？每一个开发提测，你都得了解下，这个版本 1）改了啥 2）测试重点 3）代码提交记录

否则，你一顿瞎测，浪费时间，且存在一堆安全隐患（非常容易，造成线上Bug，漏测）

end