如何建立测试团队的知识库

后台有同学留言，问了这样一个问题：

刚担任测试负责人，团队流程很乱，需求不甚明确，测试工作基本靠员工的熟练程度，项目交付质量堪忧。

迭代排期紧张，新招来的同学没人带，也没有文档之类的让他们了解业务，感觉就在恶性循环。他团队管理经验不多，问我有没有什么方法或者建议。

他所描述的这些问题，在中小型企业或创业公司很常见，都是很典型的团队管理者必须解决的问题。针对这些问题，我给出了如下几点建议：

• 控制混乱：推流程规范，从需求到交付端到端全流程的规范。
• 避免单点：梳理业务，沉淀技术实践案例，避免员工全凭熟悉程度干活。
• 新人落地：建立老带新机制，辅以业务和技术相关文档，从小需求开始，以战代学。

这几点建议综合来看，其实就是测试团队的基础设施建设工作。而测试团队的基础设施建设中，很重要的一点就是知识库的建立。这篇文章，分享一些我对于建立测试团队知识库的思考和经验。

 

知识库的重要性

首先，对个人来说，做事更多的是凭借技术和经验。但对于团队来说，个人的技术和经验无法作为参考和依据的标准。

如果将某个个体的技术和经验当作团队的标准，那这个个体就会成为团队的最大瓶颈，一切都受其制约。一旦这个个体离职或者转岗，对团队来说会造成很大的影响。

团队管理中很重要的一点是评估并控制风险，进一步找到并解决可能产生风险的因素。

如上述问题中所说的测试工作基本靠员工的熟练程度，这其实就是典型的单点风险。

且每个人的技术能力和经验以及做事的方法习惯都不相同，作为管理者面对这种情况，需要对业务链路和技术实践方面进行梳理，整理出较为规范的内容，并让团队成员以此为基准执行。

其次，面对混乱的情况，如果无人管理或不对其加以控制，则会演变成各自为战的局面。每个人都按照自己的理解和习惯做事，且大概率会认为自己的方法就是正确的，这就是典型的局部最优。

但对于管理者来说，要考虑的是全局优化，局部最优大概率不是全局最优，且可能成为全局最优的影响因素。

要解决这个问题，管理者可以在调研清楚情况后，制定较为合理的研发测试交付流程规范，并尽可能的推动在技术团队中落地，以此来约束团队成员按照统一的方向和流程做事，控制混乱现象持续扩散，避免各自为战。

最后，作为团队管理者，组建和优化团队组织架构，是很重要的一件事。

企业招聘新员工的出发点，即可能是业务扩张需要更多的人来做事，也有一定的因素是充当鲶鱼，刺激老员工不要安于现状，同时也是避免某些关键岗位员工成为单点风险。

但对新员工来说，如果入职后无法很好的适应，那胜任工作就无从谈起，更不要提成为关键岗位的轮替角色。

目前业内的实践方法是：让老员工带新员工，一方面是熟悉工作流程和对接的人，另一方面则是对团队的业务和技术栈及相关工具平台熟悉起来，能快速上手工作。

但老带新更多的是起引导作用，真正熟悉业务和技术还是需要新员工自己来实践。而这些最好的方式，就是沉淀团队的知识库，这样新员工也知道去哪里找参考。

知识库还有一点潜在优势：即使关键岗位的员工离职或转岗，后来者也能通过沉淀下来的东西更快顶上来，这也是知识库作为团队基础设施很重要的一个功能，即风险兜底。

 

知识库的组成部分

以我的实践经验来说，测试团队的知识库，主要为如下几个部分：

组织建设：包括岗位胜任度模型、新人落地计划、OKR和KPI等。

业务沉淀：包括业务链路梳理、业务场景梳理、核心业务和用例关联等。

技术实践：团队技术栈、各工具平台使用手册、接入文档和迭代记录等。

流程规范：包括各项评审、工时评估、任务排期、变更管理、线上发布等技术规范。

案例库：包括历史重大故障、复盘和优化改进记录、团队的最佳技术实践和内部分享等。