上集书说到，“排查问题”既符合你老板的利益，又符合你的利益，属实是带点双赢属性。
这一集和大家分享下，如何来取这一套富贵。先说下实操起来难点在哪里
难点一，工作量问题，
测试发现 bug —>丢给开发去排查—> 测试继续发现更多的 bug ，这种流程从老祖宗那就开始用了，简直想想都觉得很流畅。如果硬要加一步，等测试排查好了才丢给开发，这就属实有点阻塞了，如果 bug 再多一点，后果不堪想象， 毕竟项目 deadline 可不等人。
难点二，能力问题，
为什么打工人选择打工而非创业呢？因为门槛低、不操心。选择了自己排查问题，就成了“你在坑里挖，大伙围一圈在岸上看”，压迫感有没有？但是换个角度，挖的又快又好的那个人，正是项目最离不了的人。
我给大家举个例子哈，有一个时间段，我们公司大老板十分关注用户体验，时不时就把一些有的没的问题丢到群里问，不分时间，不分场合。群里的中老板们赶紧转发给自己的马仔。后来证明，凡是那段时间，反馈结果最快，最准的小老板或者马仔，都是优秀工程师。如果硬要加上世俗的成功标准，他们后来都成了中老板，而且蹿升的速度都还蛮快的。
看到这里，如果你要打退堂鼓，那很正常，尽管退就是了，没有对错。如果你有点兴奋起来，那继续往下看。
所以如何解决难点一，工作量问题呢？
第一步 、心理暗示。
没错哈，并不是干就完了，而是先暗示，我要开始排查 bug 了。有了这个暗示，你就会开始留意别人是怎么干的了。学习和观察很重要，从此你看 bug 再不是“这个 bug 咋还没解决，我去催一下；这个 bug 解决了我验证一下。”，而是看“这个 bug 是什么原因导致的，他是怎么解决的”，这就是本质的变化。
第二步、找到你偏爱的 bug
留心bug 以后，很快你就会发现，有些 bug 会 让你产生相见恨晚之感，“这个问题要是我排查出来的该多好啊”。不要觉得，这不可能吧，还爱上 bug 了么？知道为什么外行看热闹么？很多时候就是因为输入太少，输入多起来以后，一定会出现你偏爱的 bug。这时候你就有点工程师的范儿了。
第三步、是复盘和学习。
还不是干哈，但是要开始发力了。一旦你偏爱的 bug 出现，就要原地复盘，假设这个 bug 就是你来排查，你怎么查？遇到困难的时候就请教开发，遇到不懂的知识点要下去搞懂。
把你刷小红书找“测试学习线路图”的时间都用来搞懂这个 bug ，放心，你绝对不亏，因为通过这个途径遇到的知识点，肯定都是和你业务强相关的知识点了，这就是你的线路图，哪有什么无差别的线路图，如何干好业务，如何能帮团队解决问题，就是你的学习线路图。
第四步、守株待兔
经过反复的线下练习，肯定哪天就会有一个 bug (注意是肯定哈，不是大概率，是百分百)被你给排查了（在开发之前）。这种事儿多了以后，开发会主动过来找你请教，他们现在没你熟，没你快了。
第五步、 事实上已经不需要第五步了。还记得我开头说的吗？测试负责发现bug，开发负责排查 bug ，这是多么完美的一个流程，我们完全没有必要在中间硬插一步，把测试负责排查 bug 写入流程。你只负责排查自己感兴趣和关键的 bug ，成为项目的关键先生。这不是很好吗？好吧，既然不需要第五步，那么
难点二呢？能力问题怎么解决？
排查bug最重要的能力是肯动脑筋和熟悉业务，熟悉业务最好的途径 是关注每一个bug。而bug 又是以28法则分布在所有模块当中的，也就是说，开发阶段，通常越重要的、用的越多的模块Bug越多，因为关注了bug 你对这个模块的了解也会越多。你看从bug出发去了解业务是不是很完美的策略？连时间和精力的分布问题都顺带帮你解决了
所以如果你已经走到第四步，那说明你对业务的熟悉已经达标或者正在达标的路上，继续前进就可以啦，这就是难点二的解决之道。脱离业务谈技术，或者谈学习路线，对于一线工程师来说，性价比并不高。
This work is licensed under CC BY 4.0
