直接原因和根本原因

Distinguish proximate causes from root causes. Proximate causes are typically the actions (or lack of actions) that lead to problems, so that they are described with verbs (I missed the train because I didn't check the train schedule). Root causes run much deeper and they are typically described with adjectives (**I didn't check the train schedule because I am forgetful) You can only truely solve your problems by removing their root causes, and to do that, you must distinguish the symptoms from the disease.

这段话的意思是我们解决问题要找到根本原因，问题才能被真正解决。正好今天复盘的一个TT，可以作为一个很好的例子来说明直接原因和根本原因。

问题复盘
这个版本上线以后，有一个微信查单功能，第一次点查询，结果正常，第二次点查询，查询结果为空，为此紧急上了一个TT修复了这个问题。

问题的直接原因
DEV和QA都专注于需求内容的测试上，都没有想到要测试点两次查询按钮这种情况，所以没有测试出来，QA表示再来一遍也想不到要点两次查询按钮。

这个线上问题是我发现的，其实我也不是一上来就点两次查询按钮发现的，我是按照正常的操作流程，先点查询按钮，再到其它页面，再返回才发现问题的。

问题的根本原因？
然后我表达了我对这个TT的看法和建议：

“在时间允许的情况下，QA能否把我们的系统看成一个玩具，在每个用户故事上多花5到10分钟的时间（如果花太多时间，可能就不值得了），多做一些破坏性测试或组合测试，把系统玩坏？”

然后QA回答说：

“我们的系统太脆弱了，如果我用破坏性测试，肯定能发现很多问题，报出一堆bug，但是开发一定没有时间修。”

听完QA的回答，我想根本原因是不是因为系统脆弱而导致QA在特殊流程上稍稍发力就会暴露很多问题，而暴露出的问题又不能及时修复导致的？

但是从另外一个角度来看，是不是正因为系统是脆弱的，我们更要在特殊流程或操作上做一些测试，把潜在的问题都暴露出来呢？

当然怎么逐步解决暴露出来的问题是另外一个需要解决的问题。