登录/注册
CODING 如何助力实践迭代内的持续测试

持续测试带来的变革

持续测试(或者敏捷测试)要求测试作为基础活动贯穿于软件交付的整个过程中。相比起在 DevOps 时代陷入困境的传统测试模式,持续测试首要改变的是“测试后置“的状况:强调测试前置,通过尽早定义测试、测试与开发并行、在过程中保持紧密协作,从而实现快速反馈业务风险的目的。持续测试的实践变革是个关于人、流程和技术的全面工程:既需要技术上的支撑,比如持续集成、持续部署的基础能力,也包括人员自动化代码能力的提升,同时对流程的改进也是其中不可或缺的一环。

正如敏捷宣言开篇指出的四个核心价值,团队应该聚焦在为客户带来价值的行为和结果、而不是传统的按部就班完成既定项目的事项和生产过程交付物,这对测试的要求也是一样。
1)个体和互动高于流程和工具
2)工作的软件高于详尽的文档
3)客户合作高于合同谈判
4)响应变化高于遵循计划

然而,出于上述宣言中的“四个高于”字面上的理解,大家往往容易产生困惑:协作很重要,那么是不是流程、文档、计划就不再需要了呢?其实不然,毕竟软件的内在复杂度还在,那么为了更好的交付软件而进行的计划和文档说明就仍然有着重要的价值。只不过我们需要改变原来的过于臃肿的流程、文档、计划,让其不再成为团队快速响应目标的束缚。所以,“轻流程”、“合适粒度”、“尽早计划”才是我们应该作出的适当的改变。

CODING 如何助力实践迭代内的持续测试

测试过程一般包括计划、设计用例、执行这几个环节,下图就是在敏捷模式的迭代中的测试视角的经典工作流。基于这样的场景,CODING 基于【以测试计划为测试活动的主体】理念,设计并打磨产品,给用户“沉浸式”的测试体验。

接下来,让我们看看如何在一个完整的迭代中开展测试活动:

1、迭代规划会上

首先,从项目协同中规划好的迭代开始,查看/创建团队的测试计划、并关联对应迭代

然后在团队测试计划创建好之后,计划中会展示迭代的需求故事;接着为需求故事创建相应的功能用例,内容上可能只是带上规划会上达成一致的验收标准(Acceptance Criteria,简称 AC),把相关的用例任务分配给对应的测试同学,就形成了一个测试团队视角的迭代看板。
这些操作完全可以在规划会上或会后的短时间内完成,测试计划包括了迭代故事列表以及相应的 AC 作为内容的用例,暂且称之为“测试计划 alpha 版”。

2、迭代进行中

开发同学实现编码的同时,测试同学也应该同步编写该故事的测试用例-多数情况下是对 AC 进行细节性的展开和编写补充完整,用例逐步补充完整的测试计划可以称为“测试计划 beta 版”。当用例编写完毕之后及时进行评审,甚至在接口契约得到保障的情况下实现接口自动化测试的编码。这样的节奏也就实现了测试与开发的工作同步。

需求故事提测后,执行测试用例,对照用例步骤验证功能是否正常。这样,每个故事都是开发完成后马上测试通过、处于可交付的状态。在这样“小步快走”的模式下,迭代在任何时候结束都可以交付有业务价值的需求故事,而不是一批“半成品”。如此通过开发测试的紧密协同工作,逐步接近体现业务价值的持续交付。

3、发布的时候

在迭代最后需求故事都完成之后,我们就可以获得了包含完整测试用例内容的“测试计划正式版”。由此生成测试报告,根据通过率和报告反映出来的风险来判断是否可以发布到下一个环境(如 STG)

总结

CODING 迭代视角的测试工作流的核心理念是引导测试的前置,在过程中增强了测试与其他角色的协作和反馈。目的是通过产品能力来帮助团队固化良好实践,从而实现高效的测试:
首先,尽早规划了测试。从需求规划会开始,在充分理解需求并认领任务之后,我们就可以圈定测试范围,并由此产生简单版本的测试计划、并快速制定验收标准和完成初步用例的编写。
其次,通过建立需求和用例的关系,对高优先级(业务价值)的需求所需测试做到一目了然,为基于风险的测试策略(Risk-based Testing)打下了基础。
再次,测试和开发的工作可以并行。在开发工程师进行业务代码实现的同时,测试工程师可以对测试用例作进一步细化补充完整,甚至实现测试的自动化代码实现。
最后,测试过程中的操作以及产生的数据并记录下来,能够快速的反馈给团队,而这些沉淀下来的数据,将成为工程实践持续改进的指引

注册即用,体验酣畅的开发流程

立即使用