研发团队轻量级内部测试流程

对一个研发团队而言，标准化的工作流程是过程资产中必不可少的一个组成部分，尤其对初创型研发团队而言，研发管理的很多方面都不够完善，如何明确研发团队中的各种角色以及充分利用团队现有资源，确保用户和产品需求的端到端管理是研发管理者们需要考虑的问题。

本文中讨论的研发团队内部测试流程就是需要标准化的协作流程中的一种，是一套用于规范需求、开发和测试人员进行服务发布质量控制的流程性指南和说明，确保整个团队对产品质量保证有一个统一认识，促进过程的可记录性和可跟踪性，提高团队协作的信息透明和工作效率。本文面向的是10人以下规模的小型研发团队，流程尽量清晰和简洁，是一种轻量级过程控制的体现。

一．流程说明

内部测试流程通常需要基于持续发布思想，整合版本控制、配置管理、持续集成、过程自动化和部署流水线等多个工程实践，实施过程中需要对以上各点有所了解，同时对开发/测试环境独立性等外部环境因素进行把控。

本文中提到的内部测试流程使用上需要基于一个带有Ticket系统的管理平台，如Redmine、Jira等等，如果使用多个平台可能会导致流程闭环的中断或执行效率的降低；同时，本流程只适用生命周期较长（一个月左右或以上）的产品开发，一两周之内的项目不建议使用，因为流程和管理本身也需要成本；在分布式开发模式下，信息传递和有效沟通是团队协作的一个瓶颈，可以通过使用该流程确保协作的有效性。

内部测试流程中涉及的主要角色及其职责如下：

• PO：产品经理，负责产品规划、方案设计和功能分解
• DEV：研发人员，负责功能实现、进度控制
• QA：测试人员，负责产品质量控制、服务发布

内部测试流程中主要使用如下工具确保流程的运转和信息的传递：

• 邮件：过程数据记录、流程阶段性成果和最终闭环达成的消息传递机制。
• Ticket系统：问题跟踪、范围/时间控制和团队协作统一平台
• Jenkins：系统构建、版本控制和服务发布统一平台

二．流程展开

Ticket系统上的问题我们统称为一个Issue，一个Issue具有5大状态，包含各个状态转变过程和责任人的Issue完整生命周期如下：

结合Ticket系统上Issue的生命周期，内部测试流程总体流程图如下，其中背景为红色的流程需要通过邮件进行信息传递和同步：

2.1   新增Issue到Ticket 系统(PO+QA)

Ticket系统上与测试相关的Issue来源有两大块，新增Issue的状态为“New”：

• Feature：即功能点，来自于每次需求会议，由PO负责进行录入
• Bug：即缺陷，可以包括重大缺陷（Bug）和小问题（Defect），前者直接影响服务的发布，后者可视情况排除在发布范围之内。由QA负责进行录入

2.2   Issue开发 (DEV)

DEV根据Ticket系统上指派给自己的Issue进行开发，开发过程中Issue状态为“InProgress”。

2.3   更新Issue完成状态(DEV)

DEV开发完相应的Issue之后设置其状态为“Resolved”。

2.4   通过Jenkins平台构建服务(DEV)

DEV通过Jenkins持续集成平台进行服务器端、表现端服务自动化构建，构建结果会产生相应的部署和安装包。

2.5   发送提交测试邮件到QA(DEV)

DEV整理本次测试需要提交给QA的测试范围、各种部署资源以及部署步骤和注意点，并发送正式的提交测试邮件到QA相关负责人以告知本次测试需求的正式提交。邮件的标题注明测试的系统名称、测试日期和该日期下的提交测试序号，如：XXX update(X)@2014-XX-XX，表示哪个系统服务哪天的第几次提测：

待测Issue列表：
1. 100
2. 101
3. 102
4. 103
5. XXX

部署资源列表：
1. 服务器包：服务端Jenkins构建链接
2. 客户端包：客户端Jenkins构建链接
3. 数据库脚本：SVN链接

部署步骤：
1. 服务器包部署步骤
2. 客户端包部署步骤
3. 数据库脚本部署步骤
4. 其他部署步骤

部署注意点：
1. 注意点1
2. 注意点2

部署有问题请与我联系，测试过程中需求有问题请与PO联系，功能测试和反馈按照既定内部测试流程进行。

2.6   部署服务到测试环境(QA)

QA使用DEV提供的部署步骤将相关服务资源到测试环境，如果部署过程中任何问题，QA需要与DEV确认部署资源和步骤。

2.7   发送服务部署成功邮件到DEV(QA)

服务部署成功后，QA发送服务部署成功邮件给DEV以告知本次测试工作正式启动。该邮件中需要提供相关服务版本信息供DEV进行确认，确保部署过程的正确性。

2.8   更新Issue测试状态(QA)

QA根据本次测试范围更新Ticket系统相关Issue状态为“In Test”，并指派Issue为QA人员自身。

2.9   Issue测试(QA)

QA根据需求进行Issue测试，测试过程中根据情况创建新的Issue并对有问题的已有Issue需要重新设置其状态为“In Progress”并将其指派给开发人员。

测试过程中如果对需求有疑问，QA需要与PO进行沟通确认。

2.10 发送测试结果邮件(QA)

QA根据本次测试范围完成测试工作之后发送测试结果邮件给DEV以告知本次测试过程正式结束。该邮件除起到闭环告知作用之外，简要列举本次测试新建/重开的Issue数量。

测试结果邮件模板可参考：

本次测试结束（未通过）：

Test Result:REJECT

1bug in progress
2bugs new
具体请参考Tickct系统上更新。

或者（通过）：

Test Result:ACCEPTED

至此一个完整的内部测试流程闭环结束，也意味着下一个测试流程开始启动。

三．小结

内部测试流程从以下几个方面强化流程的执行力：

1. 闭环管理：通过三种邮件的交互使相关干系人明确测试范围和时间节点
2. 团队分工：明确相关干系人职责和分工，每一步均能定位到责任人
3. 信息透明：过程的可跟踪和可追溯性，为回顾提供数据依据
4. 远程协作：使用流程和平台消减地理位置所引起的沟通障碍