【干货】时间紧、任务重时！该如何做好质量保障？-工具盒子

在当今快速发展的科技和商业环境中，项目时间紧迫和任务重负是常态。面对如此压力，保障系统的质量显得尤为重要。无论是软件开发、产品设计还是服务流程优化，高质量不仅关系到用户体验，也直接影响到企业的声誉和经济效益。本文将探讨在时间紧迫和任务重的情况下，如何通过合理的策略和方法确保系统的质量。

首先，在日常研发项目中，时间紧，任务重，常出现下述两种情形：

第一种，是在项目或版本发布开始之初，就可以预见到
第二种，是在项目或版本发布后期，因为前期需求、设计、编码环节出现延期，导致后面测试工期被严重压缩。

1、常规方法

面对上述两种情形，如何应对？先说几点，通用常规的方法：

1. 明确优先级和关键需求

在项目开始阶段，与所有相关方进行充分的沟通是非常必要的。明确项目的最终目标、关键需求和优先级可以帮助团队集中资源和精力在最重要的任务上。使用如MoSCoW方法（必须有、应该有、可以有、不必有）来确定功能的优先级，确保在有限的时间内完成最核心的功能。

2. 采用敏捷开发策略

敏捷开发是应对快速变化需求和紧张时间表的有效策略。通过短周期的迭代开发，团队可以快速反应并调整开发方向，适应需求变化。每次迭代结束时进行回顾和评估，可以及时发现问题并进行调整，这样可以持续提升产品质量。

3. 强化自动化测试

在开发过程中，自动化测试是保证软件质量的关键。自动化测试可以有效减少人工测试的时间和成本，同时提高测试覆盖率和准确性。集成持续测试（CI/CD）的实践，可以确保每次代码更新后自动运行测试，及时发现并修复缺陷。

4. 代码审查和质量控制

代码审查和质量控制流程也是确保系统质量的关键措施。即使在时间紧迫的情况下，也不能忽视对代码质量的把控。通过团队内部或跨团队的代码审查，不仅可以发现潜在的错误，还可以促进知识共享和技能提升。此外，引入静态代码分析工具可以自动检测代码中的问题，从而保证代码质量。

5. 重视团队沟通与协作

加强团队协作和沟通是提升工作效率、保障项目进度的重要环节。在项目实施过程中，团队成员之间应保持密切的沟通，及时分享信息和进度，协调资源和能力。通过有效的协作工具，如项目管理软件、即时通讯工具等，可以提高团队的协作效率，减少因误解或信息滞后导致的时间浪费。

上述的几点方法中，特别是第3点，强化自动化测试，可能会有人提出，若真的出现时间紧，任务重，连手工测试时间都没有，哪还有时间写自动化脚本啊？针对这种，需要保持客观角度，视具体情形来分析，回归事情的本质。

2、我想说的

遇到**"时间紧，任务重，如何做好质量保障"** ，如果在任务量、上线需求范围不变的情况时，要保障好质量，归根结底是在于测试策略选择上。

不管是项目管理 还是质量管理，管理的三大抓手都是相通的，无外乎围绕：

质量
效率
成本

质量、效率和成本三者之间存在着紧密且复杂的关系、相互影响，提升产品质量往往需要投入更多的时间和资源，可能会增加成本；而追求成本的降低又可能会牺牲产品的质量或生产效率。同样，过度强调效率可能会导致质量控制不足，从而影响最终产品的品质，比如：

提升质量=>提高测试覆盖率=>增加测试点，其他条件相同情况下，会导致效率降低，增加成本
提升效率=>提升执行效率=>提升自动化程度，其他条件相同情况下，会导致项目外的自动化建设成本增加。
降低成本=>降低人工成本或降低机器成本，两种方式通常都会对质量产生负向影响，效率有可能提升也可能下降。

因此，现实中测试策略并没有好坏之分，如何选择合适的测试策略，本质在于如何做选择、做取舍。我们需要做的，就是要让这三大抓手之间的关系处于平衡状态，不仅要关注单一的方面，而且要综合考虑三者之间的互动和协调。

质量要求越高，测试范围则越大，测试覆盖率、测试精准度也随之越高。如果当下业务对效率要求更高，那么可以增大成本提高并发执行效率，如果成本有上限，那么为了效率可以对质量目标打一点小折扣，或者为了质量可以接受一定程度的低效率，把三者调整成符合业务需求的平衡状态。

大家日常可能会吐槽说某某团队不重视质量，仔细回想下，这个团队能接受质量极差，天天故障的状态吗？不可能的。换句话说，有什么业务会嫌弃质量太好吗？如果你感知到你的主管或业务方对质量的要求不高，和你标准不一致，可以细细分析下，是不是高质量标准带来的效率、成本，有点拖后腿了？如果我们能解决效率成本问题，高质量绝对是我们的一贯追求。

上述讲了这么多，除了一些通用的方法，还有哪些做法或思路可以落地实施的呢？分享几点笔者的建议，仅供参考：

1、不同环节、阶段，发挥合适的角色参与验证

可能有读者，会觉得多此一问：不是所有的内容都应该是测试人员来负责测试吗？如果你也有这种想法，可以把此处作为一个提醒，要先练习跳出测试角色看质量工作。

首先大家都懂的一个道理，质量不是单纯靠测试出来的！具体"什么角色来测"，取决于各角色知识、技能、工作流程的最优匹配，而不应被已有分工所限定。

比如单元测试，为什么通常是开发在测？不是因为测试做不了单元测试，而是测试负责单元测试的信息成本太高（开发写代码自然知道代码的设计细节，而测试需要额外付出了解成本）。
再比如为什么在研发流程中，需要产品方/业务方验收环节？是因为验收过程不仅能验证产品实现是否符合prd设计，还能兼顾prd没有覆盖的用户体验部分，因为产品方/业务方在这方面也比技术角色更擅长。

2、能"免测"的，尽量免测

对于时间赶，任务重的项目，组织内可商量达成共识，让其中一部分功能由开发直接负责自测（自测后可直接发布上线），特别是对于改动小，风险小的项目，开发、测试完全能够达成一致的质量结果，且如果测试方法明确，测试工具易用，开发也能够做到和测试持平的效率表现，两角表现相等情况下，开发还能够节省一份沟通协作成本（类似单元测试，节省自我沟通成本）。

当然，虽然笔者提倡，在某些情况下适当可以允许有一部分由其他角色参与测试，但不代表所有工作测试人员都不参与，否则就没有测试工作存在的必要性了，那么什么样的项目不适合开发自测？从上文可以看出，适合开发自测的项目前提是两个角色在质量、效率表现相同，如果这个前提被打破（由于岗位职责、专业能力差异，测试比开发表现更优），这类项目就需要做取舍，比如一些复杂、大体量业务中只有部分项目能够开发自测，高风险项目一定需要专职测试人员承接。

3、部分功能先发布后，再补测

若时间紧张，部分功能可先发布后再测试。例如理财业务中，有一种最低持有期的理财产品，申购后一定日期后才能赎回，那么可以和业务技术协商，先保证申购功能的测试覆盖，再在项目发布后，赎回功能尚未打开这个短短的小窗口内，补充保证赎回功能的测试覆盖。这样可以把一些功能的质量保证工作后置，减少倒排周期的影响。

4、经评估后，裁剪部分回归用例集

测试执行时间主要会花费在新功能验证和主流程、关键业务（变更不涉及修改，但又不得不验证的功能）的回归测试上，新功能验证往往是很难裁剪或省略掉的，但我们可以在回归测试上面下好功夫。

如果时间非常紧张，且没有过往成熟的回归自动化快速执行，那么可以通过评估系统实现方案+CR后确认是否有部分回归功能不受此次变更影响，然后裁剪该部分回归测试用例。

对核心回归功能，建议做功能场景覆盖调整。一个功能的用例集可以细分为多种触发场景条件的具体用例（case），这里也参考遵循二八原理：80%的用户操作落在20%的场景上。（具体需要结合历史业务数据分析）