对QA的思考——我的这些年

2012年毕业后怀着一颗忐忑的心开始了测试工作的职业生涯，到现在也有7年啦。经历过奋斗和激情，也经历过徘徊和迷茫，勤恳却不庸碌。虽然对测试也有担忧，但是对这个行业始终保持着一种激情。

接下来结合自己的工作谈一下对测试的一些思考，也回顾下自己过去的测试工作中遵循的一些工作原则。

原则1：正确的认识自己

好多人，自视甚高，傲视一切。但是，实际上，牛人很多。我们能做成一件事情，能力是一个方面，但能力绝对不是全部因素。没有上级的支持，没有同事的协作和配合，没有公司提供的资源，我们是什么事情也做不成的。不能因为自己的工作时间长，对业务了解的深，就对别人横加指责，也不能因为自己职称高就给别人以压力。

原则2：先成就别人，再成就自己

我们经常问QA的价值是什么？

实际上有些东西是很难讲清楚的。好多QA为了证明自己的技术能力、技术价值，做了很多看似高超，但是实际上对业务快速迭代并没有用的事情。

我总觉得，自己的价值不是由自己体现的，而是由别人来体现的。只有先成就别人，才能最终成就自己。这就是我工作以来一直遵循的一个工作原则。不争，不抢，认真做事，认真帮别人做事，认真的帮业务做事情，帮助RD分析线上问题，解决BUG。到了后来，也颇有点：桃李不言，下自成蹊的味道。

好多人也会说，在这个时代，酒香也怕巷子深。如果不主动宣传自己的价值，宣传自己的影响力，别人是不会知道的。但是，实际上，影响力和价值是由别人来评估的，历史交由后人评就是这个道理。并且，影响力是处于某个圈层的，并通过圈层而扩散。我们首先在团队的圈层内做到影响力，才有可能通过圈层的扩散而扩散自己的价值。

原则3：方便别人，方便自己

做测试的同学，每天会写很多测试case，每天也会发很多测试报告，但是如果打开这些邮件，经常发现这些case很难让人理解，这些测试报告虽然篇幅很大，但是如果要从中找到接下来RD要做什么，还是要花费一点时间的。

在测试工作过程中，无论是测试报告，还是风险通报，首先要了解到这些内容的接收者到底是谁，然后需要思考，要以什么样的描述和组织才能方便对方快速了解到内容的含义，也就是要做到：到什么山头，唱什么歌。

我刚入职的时候，因为之前没有做过测试，也不知道测试报告要以什么样的格式来发，所以很害怕发测试报告。虽然学习了其他前辈的测试报告和前辈们的测试报告范式，但是总感觉还是害怕。因为，从RD的角度来看，阅读那些测试报告的成本还是很大的。

然后，我站在RD的角度上想，怎么组织测试报告，才能让RD一眼就知道自己接下来要做什么呢？然后我重新组织了之前测测试报告，在报告的最开始用1句话概括项目的测试结论：该项目测试是否通过，原因是什么？具体的BUG量是多少？然后接下来是详细的测试清单，清单中明确表明每一个case的测试点，前置，预期结果，实际测试结果，是否通过等信息。对于测试通过的case，用绿色来标注；对于测试失败的case，用红色标注；对于有疑问的case，比如建议等，用黄色标注。RD收到测试报告之后，先看结论，然后看非绿色的测试case修复BUG。

原则4：消除门槛，而不是提升门槛

大禹治水之所以成功，最重要的思想就是：改“堵”为“疏”。

但是真正的测试过程中，经常会发现如下的现象：领导质疑QA的测试时间太长，QA质疑RD的提测质量太差，然后QA增加了准入打回的流程，对于RD提测的、没有通过准入的项目不予测试。

实际上，这种现象就是QA在项目的测试环节设置了一个门槛，而如果这种门槛设置的越来越多，那么对于业务而言也会发生“洪涝灾害”。单从测试团队的角度看，确实增加这个门槛，测试效率提升了，测试时间降低了，但是如果从整个业务的迭代来看，效率并没有提升。

我们提了门槛，发了准入case，增加了流程，这一点也不能说不好。但是我们有没有想过：这些准入case别人看的懂吗？我们怎么设计case能够使得RD自测的时候更加方便呢？即便看懂了，我们怎么保证RD确实执行了呢？我们怎么保证增加的这个流程每次都贯彻落实了呢？

QA不应该是一个门槛设置者，而应该是一种有效的武器。不能用看似合理的各种标准和要求卡住事情，而应该成为帮助团队解决问题的秘密武器。

QA不能只报问题，只说现象，只说RD不靠谱，上线不检查。QA需要思考：

• 我们能为快速迭代做些什么？
• 我们能做些什么可以帮助RD快速发现自己的代码问题？
• 我们能做什么可以帮助RD快速发现上线过程异常了？

原则5：不断学习，不做伪学习者

现在，技术更新换代的频率很快，所以一定要不断的学习，持续的学习。还记得刚入职的时候，那时候就会c/c++，java。现在看看自己的github和内网的提交记录，发现语言层面基本上涵盖了：c/c++，java，php，python，go，javascript，shell，object-c，swift，lua。项目类型覆盖了服务端，策略端，iOS，Android，自动化等不同的方向。从原来只会用IIS的小白，到今天了解Apache，Lighttpd，Nginx等各种web服务器。从原来的服务端，到慢慢了解前端，了解策略端，了解客户端。

参加过好多会，和好多人沟通过，大家都希望组织提供学习的机会，提供分享的机会，希望组织能提供自己技术成长的机会。但是，实际上，成长是自己的事，学习是个人的事，为什么要求组织给提供这些机会呢？我组织过很长时间的分享，我也最反对组织大规模的技术学习和分享，因为让太多的伪学习者进入之后，效果并不理想。相反，规模较小的沙龙和讨论对个人的技术成长效果更为明显。伪学习者只是想学习而已，只是想让组织提供学习机会而已，仅此而已。

学习是自己的事情，白天求生存，晚上求发展。凌晨2点的时候，也曾在灯下啃过Nginx的源码，分析一个个的线上问题，没有这些个凌晨2点就不会有《Nginx沉思录》，《Nginx洗冤录》等一系列的总结。

原则6：做积极的抱怨者，不做消极的抱怨者

没有“抱怨”就不会有技术的进步，但是反过来说没有“抱怨”就不会存在那么多的失败，一无是处，庸庸碌碌。关键是要看待我们对待“抱怨”的态度。当“抱怨”还仅仅是停留在嘴上，停留在思想上，被“抱怨”所控制时，基本上也就离碌碌无为不远了。当我们开始和“抱怨”对抗时，利用一切技术手段和努力消灭“抱怨”时，技术就开始进步了。所以，我一般不反对抱怨，并一直鼓励大家抱怨，但是接下来我会仔细分析抱怨的原因是什么？技术上需要什么探索才能消灭这些抱怨？

每一个“抱怨”都是一次机会，都是一个机遇，都是一次成长。逢山开路，遇水搭桥，勇往直前。

原则7：正确认识QA和RD的异同

天分日夜黑白，季节有春夏秋冬，虽然全栈模式有他的优点，但是四季也有四季的美。文能提笔安天下，武能上马定乾坤。关键是，我们需要对QA和RD有正确的认识。

我们不能按照一个原则来评定事情。比如：老驴拉磨，始终走不出那个圈圈。和日行千里的良马相比，当然老驴要羞愧了。但是如果换个角度，拉磨一天，产面千斤。良马再能跑，也跑不出千斤面。

QA和RD虽然都是研发岗，都是技术体系，那他们的差异在哪呢？

我觉得有以下几点吧：

• 从工作关系上讲，QA是RD的下游，RD是QA的客户。
• 从工作重点上讲，QA注重分析，而RD注重实践。RD要做的是解决问题，采用任何可能的方法，快速实现需求，快速上线。而QA没有太大的业务压力，可以有更多的时间来思考每一种技术的优势和劣势，有更多的时间来仔细分析和追查每一个bug的深层原因，帮助RD在快速解决问题后可以彻底解决问题，锦上添花。
• 从涵盖业务上讲，QA关注的业务广度较高，而RD关注业务的深度更高。

实际上，技术是一个很广泛的概念，不能认为只有写代码，设计架构才是技术，我们的思维本身就是一种技术。关键是，我们的技术要为业务的发展而存在，而不是孤立的存在。