技术改进项目的质量保障思路

本文分享一些技术改进类项目(以下简称“技改项目”)的质量保障思路。

1. 技改项目的质量挑战

何为技改项目? 即目标是服务于技术改进或架构升级,而非服务于常规的业务功能更新。常见的技改项目有:大规模的前端重构或后端重构、技术架构升级、数据库拆分、数据迁移、系统上云和云迁移、非对客的支撑性项目等。(非对客:不直接面对前端用户的功能,通常是系统的支撑性需求)

为什么这类项目的质量保障思路值得单独讨论? 区别于常见的业务功能更新,这类项目往往都是在保持原有业务的基础上进行的底层支持或改造,与以往业务功能测试的角度不同,更多的是针对非功能需求的测试。而团队整体缺乏业务视角,或对非功能需求的质量认知不足,可能会引发大量的质量风险或缺陷,破坏已有功能的正常运转。

另外,技改项目面临的情况往往比较复杂,缺失的大量业务上下文,难以偿还的技术债遗产,项目人员往往面临着一边做技改、一边理业务的困境。难上加难的是,还可能同步进行着现有业务的扩充或变更,这就更为技术改进类项目的质量保障过程雪上加霜。

因此,这类项目的质量保障任重而道远,需要特别对待,从长计议。

2. 兵马未动,策略先行

♦ 风险驱动整个过程

技改项目好比暗潮涌动的平静海面,平时不出事,一出就是大事。因此,风险分析和干预应贯穿始终

常见的质量风险盘点如下:
1)低估工作量或研发过程中的工作量膨胀,不能如期上线
2)上线过程不可逆,有失败风险
3)破坏既有稳定功能
4)影响外部集成系统
5)不可抗力导致上线时间变动,提前或延后
6)质量较差造成的大量返工

我们把这些风险放到风险状态矩阵中,可针对不同等级的风险制定不同程度的干预或响应机制。

image

风险状态矩阵:尽早分析 Over 走一步看一步

♦ 构建质量防护网

按理来说技改类的代码变动,类比重构,应保证原有功能不被破坏。但现实往往是“动一行、挂一片”,“动两段,修半年”。

在做大规模的技改前,构建质量防护网尤为重要。 设计良好的自动化测试能被频繁执行,这就构成了质量保障的基础。我们诟病于自动化测试的投资回报率低,通常是因为用错了地方。自动化测试应用于需要大量回归测试的场景,如业务变量较少的技改类项目,会比应用于频繁开发新功能的场景更见效也更经济。

除了自动化测试给代码质量的保障,还需要人工干预的流程保障。 测试人员应坚守质量门禁,即使是一张技术卡或任务卡,也要像对待用户故事一样,坚持开结卡的流程,明确验收标准和完成定义,确保已经做了的事情都是有效且高质量的。

image

质量门禁的意义:破坏引入问题的回路

♦ 为“不可逆”而设计和预演

试想这样的场景:常规的功能发布,经过紧锣密鼓的上线部署和验证,突然发现存在重大问题,来不及临时修复,只能回滚。于是相关的服务回滚后,测试人员又进行了回归验证,确保服务回滚不会造成重大的影响。为了不影响业务运转,往往只能在非工作时间进行部署,折腾完这一圈可能都是后半夜了,好在有惊无险。大家盯着转危为安的软件,露出了欣慰的笑容。

如果是技改类项目呢?一样的过程,上线→发现问题→回滚?无法回滚!若此时遇到问题,内心只有两个字:“绝望”。技改类项目的特点决定了上线过程基本都是不可逆的一锤子买卖,很少具备有多套生产备份或灾备的条件。因此,技改类项目的开发、测试、部署、基础设施、上线过程等等一系列研发活动,都需要为“不可逆”而设计,****并且应在类生产环境进行多轮具备多样性的部署预演。 不能事后补救,只能事前预防。

3.业务视角不能丢

技术改进,并不只是技术范围内的事。 除非这部分代码完全不会在生产环境运行(当然这种情况也不需要上线),否则都需要带着业务视角来看待技术改进。在改进过程中,如何边改边保持业务的稳定运行,如何确保迁移后的数据能在业务系统里顺利流转,如何保证非对客项目的架构设计满足业务系统的支撑性需求?这些问题的探讨都不能独立于技术范围,而需要更多业务侧的输入。

♦ 业务输入与业务评审

业务人员天然具备业务视角,可以从保证业务连续性的角度给技改类项目两类输入,一类是业务知识本身,项目背后的业务沉淀和业务重点;另一类是为了保证业务连续性,需要提供的支撑性需求,如可追踪/留痕、容错性、高可用需求等。

在技改过程中,识别到任何可能影响本系统业务或集成系统业务的改动内容,都需要组织业务评审,充分理解业务背景,再评估改动范围和风险。

♦ 基于风险的业务优先级判断

资源总是受限,以追求经济的投资角度来看,应基于风险来判断业务优先级,**给不同风险等级的业务,投入与之匹配的质量资源。 **如下图,呈现了基于业务优先级的自动化测试设计。

image

基于业务优先级的自动化测试设计

♦ 业务集成要趁早

如有可能,尽早集成。 应从设计时就进行思考,验收时依赖的内部服务尽量不用mock。盘点改进点或迁移数据的业务含义;所需覆盖的业务场景,尽量以端到端的视角去做技改部分的验证。如果早期不考虑集成相关的问题,后期可能面临的就是大量返工,甚至推倒重来。这个沉没成本是不情愿也不应该付出的。

4.技术实现,应知其所以然

♦ 深入技术细节

因技改类项目需维持业务连续性,且通常底层变化难以从外部观测,可测性不高,因此在做技改类项目的测试和质量评估时,需要深入技术细节,对具体的实现过程刨根问底。只有深入技术细节,才能有效避免“错误的输入经由处理后,阴差阳错地返回了正确的、或看上去正确的输出”。

♦ 重视非功能需求

非功能需求,也称跨功能需求或支撑性需求(Non/Cross-functional requirement),是指按照一些条件判断系统运作情形或其特性,而不是针对系统特定业务行为的需求。——维基百科

测试非功能需求的两大质量目标:一是保证系统稳定运行,二是保证系统可持续发展。

  • 运行质量:可在系统运行时观察到的质量,如安全、性能、可用性等
  • 发展质量:与软件系统结构和开发过程有关的质量,如可维护、可扩展等

技改类项目应更加重视非功能需求: 整个改进过程是否破坏了系统原本支持的非功能需求;干系人或用户对改进后系统的非功能需求预期是否发生了变化;对已经捕捉到的非功能需求,应能清晰描述验收标准和期望的系统运行状态。

image

非功能需求示例:针对不同系统特性,应形成相应的非功能需求重点

5.一些经验教训

♦ 1+1<2

由于技改类项目的特殊性,承担这类项目研发工作的大都是研发骨干,这对项目经理提出管理上的挑战。需警惕“1+1<2”的陷阱,避免频繁陷入漫无边际的无意义的技术讨论中。同时兼顾技术决策的投资回报和改进效率,以及核心骨干人员的工作体验。陷于类似困境的同事们都能深刻意识到团队梯队的重要性,全是资深同事并不利于工作的快速推进和高效管理。

♦ 全局视角

影响技改或被其影响的干系方很多,技改类项目需要更宏观的全局视角。不只关注技术,更关心业务;不只关心自己的业务,也关心是否影响外部集成方的业务;不仅关注当下的运行质量,也关心未来的业务或架构演进。一句话总结,这个全局视角需要横跨技术和业务、团队和干系人,还有时间上的现在和未来。

♦ 业务沉淀的必要性

具备高业务复杂度的项目一定要做好知识管理,再忙也别忘了抽空做业务沉淀和知识传递。业务沉淀的必要性就好比人的软实力,平时可能看不出差距,持续做也似乎成效甚微。但凡遇到复杂度上升或面临艰难挑战,管理人员就会发现,在平时点点滴滴的实践过程中,业务上下文的构建和业务视角的赋能,已经在团队中悄无声息的完成了。关键时刻方见奇效。

转:技术改进项目的质量保障思路 (testwo.com)

你可能感兴趣的:(技术改进项目的质量保障思路)