聊聊测试开发角色在降本增效大环境下可以做哪些事情

不管是不是寒冬，“降本增效”都是一个明星话题。对于各位测试开发工作者来说，相信最大的体现就是裁员、正编换外包，以此来获取最直接的利益：测试开发人头比。
不管是否有影响，先来个1:10，再来个1:20，再来个目标：业务不崩！
那么吐槽归吐槽，接下来我们共同探讨一番，在这样的背景下，我们可以如何开展工作吧～

零、先来个大分析

• 降本 = 降低成本（人力成本、硬件或资源成本、时间成本、机会成本、沉没成本 等）；
• 增效 = 合理分配有限资源，持续提升业务（事物）支持效率；
• 质量 = 线上问题保持在低位，不必追求完美无瑕，但不可发生严重事故；（若发生，有1-5-10能力：故障的“1 分钟发现-5 分钟响应-10 分钟恢复”）

基于上述分析，我们再把目标给拆解一下。

一、分主次（业务重要程度和问题容忍程度梳理）

假设平均要求是1:20，但是我们的业务并不是完全一模一样的，如果重营收的业务VS仅对内部使用的业务，孰轻孰重，毋庸置疑，那么我们投入的配比也会不同。
这个理念可以应用在任意的划分中。比如业务的优先程度、单个需求的优先程度、需求中模块的优先程度 等等。
可以通过后续施行数据不停测算比例，遇到问题再调整就是了。
注意，各位测试开发同学在这个过程中所做的所有决策，都需要跟全部合作方通兑，达成一致后才能实施哦～

以下简单介绍下业务配比已确认情况下的实施

• 需求分级：业务需求和技术需求分池（通常技术需求投入总成本不得高于5%，除非有重大影响的），然后分别制定优先级；（分级标准：一般是基于功能本身等级、代码实现复杂度/产品严格要求）【这里如果展开会有很多，本篇中暂不展开】
• 数据埋点：部分埋点用于财报、需求分析，其实是非常重要的，但是埋点如果一开始设计管理的不好，那就真的是又大量、又复杂。（建议单独分级管理）

二、做减法

• 同一套代码的不同应用，可降低测试投入（优先保障使用量大的应用，如出现问题，可以通过hot fix解决）；
• 部分客户量很小的应用，可以不做测试投入；
• 推行端到端测试，减少冗余的工作；
• 回归用例精简（或精准化、自动化）；

三、质量共建，测试左右移

• 建设免测、研发自测标准和流程（注意用例、工具、过程反馈监控）、冒烟测试流程；
• 建设内测、众测流程，引入更丰富和低成本、适配的测试角色；
• 复杂测试方案简单化（数据、环境、测试步骤）；

四、降低线上问题影响面

• 快速发现、快速止损、数据反馈；
• 方案阶段卡点：开关、实验、灰度、降级、回滚 、熔断；
• 线上攻防演练、混沌演练；

五、信息共享、人员培养

• 提效意味着工作变得更加紧凑，很难有充分的时间精力去进行比较大型的培训，所以建议大家讲日常经验做成分享，在每次全员的通兑会（比如周会），简短地分享一下各自的经验，互相取长补短，快速调整阶段性的问题，寻找到适合各自的跟上节奏的工作模式。
• 最后：一定一定要做好数据建设，不仅仅是一些零散的指标，要成体系化，数据能互相关联作证和被分析～