质效提升 ｜ QA不做业务需求测试，你怎么看？

​因为有的小伙伴看到公司的QA不测试业务需求，只搞流程、卡点、规范、技术创新、QA平台，行业洞察，让研发自测、研发担责上线bug和风险，所以问我，你怎么看QA不做业务需求测试这件事。其实我怎么看不重要，这事还是要看公司管理层和QA负责人，我个人倒是可以作为一个业务方来聊一下这件事。

企业架构

公司组织架构很大程度上决定了QA团队的规模和工作职责。QA团队汇报的等级越高，公司对QA团队和QA工作认可度也越高，对QA的工作质量要求也越高。「通常来说」企业架构上，QA和产研运在一个组织汇报维度是比较正常的，也就不会出太大幺蛾子，如果汇报线奇葩，那么里面肯定有很多不为人知的奇葩事情，要避坑。

举个活生生的例子，某公司的QA汇报给运维负责人。我个人对这种组织架构其实是不太看好的。在业务层面去看，QA更应该和业务，也就是合作方，甚至可以说是「自己的甲方」在一起更好，而不应该和「自己的乙方」在一起。QA和运维在一起，挺多在资源部申请和运维支持工作上带来一些便利，可是这样就和自己的业务距离太远了，不利于自己业务的开展。QA和运维都是资源型团队，如果仅仅是资源输出，这样的组织架构产生的价值就更不被看好。如果这样组合是为了建设QA平台，那么至少还需要产研的小伙伴的加入才能完成。总之，这样的组织架构，更像是临时安排，不像是长久之策。如果一直是这样的组织架构，那要小心。就像有个虫子眼的苹果里面大概率是问题的。

同理，联席CEO，联席CTO也是比较差的企业组织架构，其中很多都是权宜之计，时间长了都不是好事。比如58和赶集合并的时候曾经有过联席CEO，过一段时间就有人卸任了。这还算好的，毕竟CEO很多都是把方向，负责很多具体事务的CTO如果也有主备那对公司就更伤、更内耗，各种谣言漫天飞，那谁要退休了那谁要上位了。

质量文化

公司的质量文化强弱决定了QA团队的工作宽度和广度。如果公司的质量文化淡薄，高层对质量要求停留在口头、停留在表面层次，那么QA的工作也会有很大影响。如果充分授权，认可QA团队的工作和价值，那么久而久之就会形成浓厚的质量文化。

举个例子，某公司的主要产品是工具型C端产品，因为起步早，时机好，有大量的用户，但是质量问题一直很大。高层年初提出了质量方面的OKR，但是鉴于经济形势，没有额外的QA HC增加，甚至QA团队还有缩减；同时新的业务需求方面还在紧锣密鼓的进行着，并没有「鉴于经济形势」同步降速，产品和研发的人员也在减，但远没QA人员流失的多。再加上公司强势的「工程师说了算」的文化，重视技术，不重视技术外的其它团队，包括产品、QA、PMO、运维、设计等，其实这样走下去，质量肯定不会有大的提高。

再举个QA做得好的例子，某公司主要做C端交易型产品。涉及到C端+交易型，意味着质量问题就是高优要解决的问题，所有涉及到「钱」的问题都是大问题。QA HC充足，团队梯队建设合理，发版任务是QA同学负责，包括线下环境搭建、功能测试、线上发版流程、质量卡点和规范等。也就是说产研小伙伴把功能开发完成，后面的工作都交给QA了。QA对质量负责，对上线负责，权力大意味着工作内容也多，权责对等是合理的。

抄半套

国内很多公司对国外，尤其是硅谷的工程师文化特别感兴趣甚至是迷恋，经常去看别人是怎么做的，然后自己照着葫芦画瓢。其实有的时候，你要抄就都抄，很多时候抄来的都是皮毛，而精髓没抄来，总是抄半套。

举个例子，500人的QA部门，大部分QA不做业务测试，主要精力是搞流程、卡点、规范、技术创新、QA平台、测试框架。业务部门在那里嗷嗷待哺，来个QA吧，来个QA吧。QA部门甩过去一巴掌，老子没人。所以研发不但要开发自己的业务需求，自己搭建环境，自测需求，回归功能、识别风险、评估风险。一大堆整完了想上线，你还得找个QA来点一下「批准」上线，美其名曰「紧跟硅谷文化」「研发吃自己的狗粮」「技术驱动」「上线流程自动化」「QA只负责测试框架和平台」......那为啥QA要点一下？呜....这是中国特色之「QA质量把关」。结果上线后业务故障告警不断，QA一指：产品需求不明，开发质量太差，运维重复告警......

本篇总结

QA做不做业务需求测试不是什么大事，可以根据自己的业务去看是否要配QA。之前我们做AlphaCloud 的时候，团队没有一个QA，业务也卡卡地向前跑。后来做 Kone 有了专职QA，感觉也挺好，毕竟比我们自己搞专业很多，我们也能把精力更多放到业务发展上。我不能理解的是500人的QA团队不重点支持业务，告诉业务我没人，然后自己瞎搞，这就走偏了。当然最后的结果也显而易见，业务部门无法忍受，QA部门解散，业务QA拆分到业务，与业务闭环到一起，剩下的QA小伙伴合并到其它部门。这样的结局，作为业务方我看了三遍了。