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

简要介绍

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

项目背景：

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，后面逐步再去研究各类非功能测试。