保险行业大型数字业务转型项目案例

简要介绍

如何根据项目的组织、交付模型和人员结构来设计适用的测试架构及流程

项目背景:

  1. 保险行业大型数字业务转型项目
  2. 使用SAFE模型,有8个敏捷小组(agile team)及其它shared service team。
  3. 测试团队定位为 share service team,敏捷小组中没有测试人员,使用业务分析师(BA)兼职测试,项目成员都没有测试相关背景及相关技能。
  4. 系统复杂性高,集成系统多(有前端,后端,及与现网其它系统集成)。
  5. 项目团队总体人数150人左右,希望测试团队人员越少越好(SAFE中 share service team设计为少量人员,主要行使支持角色)。初始团队人数定为3人。
  6. 分期上线,每个release间隔1-2年。

背景分析:

  1. 行业(保险行业)及系统复杂性(复杂性高,且集成很多),决定了需要设计相对复杂,多层级的测试来保障质量。
  2. 敏捷测试决定了测试需要尽早开展,任何开发活动(业务分析,系统设计,编码这些都算开发活动),都需要相关测试及时跟上。
  3. 项目成员没有测试技能,在布置测试工作的时候,需要好理解,好操作,尽量简化。
  4. BA兼职测试:不好的地方在于测试技能有限,无法测试全面;好的地方在于如果能利用好BA,可以做到业务和系统设计高度一致。
  5. 测试团队的定位:一方面是支持服务角色,质量是每一个项目成员的职责,测试团队需要提高其它项目成员的参与度及专业性;另一方面仍然为最终把关角色,只有通过测试团队的认可,各个阶段性成果才能获准进入下个阶段。
  6. 根据测试架构设计决定测试人员的需求,再向项目组请求增加更多的测试人员。

测试工作开展的方向:

  1. 根据项目背景分析,设计测试策略,测试架构及团队组成,与相关干系人达成一致,取得项目支持。
  2. 对测试进行分级,每一级中设计相关流程,与干系人达成一致,开始运行后,使用测试报告进行监控。低级别测试大致运作起来后,再进入下一级别。
  3. 紧密团结各个敏捷小组,尽量发动敏捷小组中的成员执行测试活动,使用测试团队人员执行关键活动,给各个敏捷小组提供培训、测试监控、工具支持等服务。
  4. 从第一次上线的scope入手,先保证第一次上线,其余部分先往后推。
  5. 尽快展开功能测试,向项目组获取额外的功能测试人员,非功能测试及自动化测试先放1-2个人进行调研,后期再展开。

测试架构设计:

1. 测试分为四个级别:

 

 

2. Development Test 流程

开发提交代码到CI/CD之前,必须完成code review及单元测试,此处测试团队负责QA,需要设计单元测试规范,提供代码覆盖率定义及代码覆盖率抽检工具,将各个敏捷小组的代码覆盖率公示出来,以此督促各个团队提高。

3. User Story 测试流程

 

 

该测试流程的关键点在于:

  • 每个US必须有至少一个TC覆盖 ,设计TC的时候,先做测试分析(例如根据Acceptance Criteria得出可能的test scenario),再做测试设计,测试团队要给各个敏捷团队提供培训,教会BA做基本测试分析及测试设计的套路。
  • 每个TC必须由该敏捷小组内的另外一个角色来进行review并最终approve。各个敏捷小组自由选择review人选。
  • 每个approve过的TC才能执行,执行通过后由PO检查,无疑义后可以关闭user story。
  • 测试经理需要根据每个PI/Sprint给各个敏捷小组建立User Story的测试计划,每周定时出测试报告并在类似PO会议或者SoS会议中讲解,目的是给出每个敏捷小组的对比并督促执行。
  • 每个sprint各个敏捷小组都要考虑回归测试,根据该sprint各个user story的change impact,选择过去已经通过的TC重复执行,后期自动化加入后,可以做成每天定时的自动化回归测试。

4. E2E Test 测试流程(包含Feature测试/系统测试/端到端测试/UAT测试)

 

 

当某个feature下的所有user story都关闭后(即US都测试通过并接收),该feature可进入这一阶段的测试,这一阶段测试我自己起了个名字叫E2E Test(没办法,大家说叫别的没法理解,只好照顾大家的感受了),由测试团队执行。各个子类测试流程如下:

4.1 QA of User Story Test

测试人员(特指测试团队人员)需要对敏捷团队进行的user story test进行检查,通常关注点为:

  1. 需求描述及AC的质量检查
  2. 测试案例对AC的覆盖程度
  3. TC的执行结果是否真实有效
  4. 该QA可以融入US Test过程中,例如在test review阶段加入测试人员的review。

4.2 Feature Test

  1. 测试分析:根据Feature / US的需求描述及AC,构建尽量多的test scenario,对每个场景给出优先级(这里可以加入Risk-based test的内容了)。重点在于找到US Test没有覆盖到的场景,以及各类异常场景。同时对需求或设计有不清楚的地方,也要记录下来。
  2. 测试设计:优先级高或有必要的场景,书写测试步骤。
  3. 测试评审:评审由测试人员组织,主要评审人为PO或BA,评审中需要澄清测试提出的问题,对测试场景达成一致(哪些场景要测,哪些不用测,为什么),对各个场景的测试步骤达成一致。
  4. 测试执行:通常要求在区别于US Test的测试环境进行测试,发现bug就提给各个敏捷小组,全部TC pass后提交PO。
  5. 关闭Feature:PO验收测试结果后关闭Feature。 (注意不能由测试来关feature)
  6. 自动化上来以后,每个feature可以总结出关键场景,创建新的自动化案例或者更新已有自动化案例,加入每晚的自动化回归中。

4.3 端到端测试

项目交付的最终目的是能支持实际的业务场景,故第一步是从业务部门得到能够支持的业务场景集合,这里我找的是Product Management,每一个PI,Product Management都会组织PO进行业务场景的梳理,并以Use Case的形式给到测试这边。(我起了个很土的名字叫E2E workflow,没办法得照顾大家的认知。。。)

端到端测试流程如下:

  1. 获取E2E workflow并进行评审,评审由测试及相关敏捷小组的Scrum Master参加,并将结果反馈给Product Management,最终得到approve的E2E workflow。
  2. 负责相关模块的测试与SM识别各个workflow涉及到的Feature,并初步讨论相关的重要场景
  3. 根据相关feature的进度(何时开发,何时测试等),对workflow进行分解并制定初步的测试计划(即啥时候大概可以测长流程中的某一个小段,啥时候能组装起来)
  4. 按照测试计划及feature的进度,再进行测试分析->设计->评审->执行等.
  5. 最终全流程测试顺利通过后,提交给Product management验收。
  6. 每个PI可能只能解锁某一些E2E workflow的某些部分,但是在准备release前,要保证该release相关的E2E workflow及Feature 全部测试通过。
  7. 自动化上来以后,将关键的端到端案例转换为自动化案例并每晚执行。

4.4 UAT测试

通常UAT测试是和release 测试并在一起,但是这里我们希望终端业务客户能尽早参与,故设计了在端到端测试通过后(即某些E2E workflow全流程测试完成)即开始这部分的UAT。要点如下:

  1. UAT执行者为终端业务客户,测试团队行使测试管理及支持角色。
  2. UAT只能选取部分已经通过的feature /E2E TC进行重复执行,这样才能控制住测试范围,如果UAT tester提出一些没有测试过的需求,那么需要先在之前的测试活动中执行后才能加入UAT 范围。
  3. UAT 的流程仍然遵循 测试分析(确定范围)->测试设计(选择case及更新case)->测试评审(讨论范围,计划,case等)->测试执行。
  4. UAT的最终结果由PO及Product management接收。

5. Release Test 流程

 

 

前述各个测试等级均在开发分支上进行,可以根据需要在适当的时候,开release分支。要点如下:

  1. 根据release的范围设计准入条件,不满足条件不要急于开始release test。
  2. Release test的意义在于验证该release分支上的版本能够上生产,故执行新测试,发现bug并不是测试的目的。根据scope及change impact选择已经执行通过的TC构建测试集合(更像是回归测试),附加各类非功能性测试(通常在staging上进行)。
  3. 如果UAT在前阶段不充分的话,可以合并到release test中进行。

当前进度

现在我进入项目大概4个月时间,测试架构已经得到项目的approve,据此我提出了需要更多的测试人员。

上述测试流程中,Development Test找了个technical tester在研究,主要把关还是在各个敏捷小组。User Story Test已经运转良好。E2E Test刚招到2个新的功能测试人员,主要对第一次上线内容开展feature test。Release Test还未开展。

Technical tester当前主要工作为创建自动化测试平台,探索单元测试的QA,后面逐步再去研究各类非功能测试。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
数字转型升级建设项目方案是一个涉及多个层面的复杂过程,旨在利用数字技术对传统业务模式、流程、组织架构和管理模式进行全面升级、优化和创新,以实现企业的可持续发展和竞争力提升。以下是一个可能的数字转型升级建设项目方案的基本框架: 一、项目背景和目标 首先,需要明确项目的背景和目标。这包括分析当前企业面临的业务挑战和市场环境,以及数字转型的必要性和预期效果。明确项目目标有助于确保整个项目的实施方向和效果。 二、项目内容 技术升级:包括硬件设备的更新和软件系统的升级,以满足数字转型所需的技术基础。 流程优化:对现有业务流程进行全面梳理,通过引入数字化技术实现流程的自动化、智能化和高效化。 组织架构调整:根据数字转型的需要,调整企业组织架构,建立更加灵活、高效的组织形式。 文化建设:加强数字转型的宣传和培训,推动企业文化的转变,以适应数字化时代的需求。 三、实施步骤 前期准备:包括项目立项、团队建设、资源准备等。 需求分析:对企业的业务需求进行深入分析,明确数字转型的具体需求和目标。 方案设计:根据需求分析结果,设计数字转型升级的详细方案,包括技术选型、流程设计、组织架构调整等。 方案实施:按照方案进行实施,包括技术部署、流程调整、人员培训等。 后期评估:对项目实施效果进行评估,总结经验教训,为后续的优化和升级提供依据。 四、风险评估与应对 在项目实施过程中,可能会面临技术风险、业务风险、组织风险等。因此,需要建立风险评估机制,对可能出现的风险进行预测和评估,并制定相应的应对措施,以确保项目的顺利进行。 五、项目预期效果 通过数字转型升级建设项目的实施,预期能够实现以下效果: 提高生产效率:通过自动化和智能化技术的应用,降低人力成本,提高生产效率。 提升服务质量:通过数字化技术的引入,优化服务流程,提高客户满意度。 增强市场竞争力:通过数字转型,使企业在市场中更具竞争力,实现可持续发展。 六、总结与展望 最后,对整个数字转型升级建设项目进行总结,包括项目的成果、亮点和不足。同时,对未来的数字转型进行展望,明确未来的发展方向和目标。 请注意,这只是一个基本的框架,具体的数字转型升级建设项目方案需要根据企业的实际情况和需求进行定制。因此,在实施过程中,建议企业加强与专业机构的合作,共同推进数字转型的进程。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值