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

作者：laofo

2023-08-14
北京
本文字数：1979 字
阅读完需：约 6 分钟

因为有的小伙伴看到公司的 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 小伙伴合并到其它部门。这样的结局，作为业务方我看了三遍了。