如何实现尽早测试？－敏捷在禅道（三）

尽早测试 是 敏捷测试 的一个基本实践，在禅道中，如何实现尽早测试？
禅道的功能极其丰富，一时半会你不可能当然也没必要都了解清楚，依据本文你只需要几步就可以轻松掌握尽早测试的基本流程，立即行动起来吧！

提示：
在一个迭代中，你要规划几个版本（build），才能实现尽早测试。整个迭代过程就是不断实现需求／测试的过程，而没有一个集中解决BUG的过程，但在最后会有一个验收测试和发布的过程。

注：由于对禅道进行了定制，故本文截图的术语和默认的不一致，主要两点：
1. 迭代版本（build）：保持不变，有些字段名称略有变动，不影响理解。
2. 测试版本（testrun）：改为 测试任务。

开发工程师

1. 创建版本
2. 实现需求 | 修复BUG
3. 关联需求 | 关联BUG
4. 提交测试
5. 了解测试结果

创建版本

进入迭代-版本，创建版本（负责提测的开发工程师操作即可），版本定义见 扩展版本，如下：

创建版本.png

本文中的版本指的都是扩展版本，其基本定义为：version# (role#build#)），比如：0.5.0 (C2)。

实现需求

• 规划需求
  你会规划这个版本要实现哪些需求。
• 分解需求
  为了降低复杂性和尽早消除不确定性，应当尽可能地把需求进行分解。
• 尽早测试
  一个或几个功能完成就可以进行测试，越早测试就可以越早帮助开发澄清需求，消除不一致性，不断优化结构，夯实组件可用性。

传统的非要把所有功能都开发完成才提交测试的做法实在满足不了当下时间受限条件下的开发节奏。

具体到分解需求、完成任务的过程，这里不详述，略去千字。

关联需求

进入迭代-版本，查看指定版本的概况（f=view），点击关联需求，即出现未关联需求列表，把你已实现的需求勾选加入即可。

关联需求.png

** 关联BUG **
关联BUG，和关联需求一样方便。

关联BUG.png

提交测试

进入迭代-版本，对指定版本提交测试，意味着这个版本开发自测OK，可以提交专业测试啦。因为你在前一步已经关联了需求，测试人员很容易就可以直奔主题进行有针对性的测试了，是不是很方便？

提交测试.png

然后你就可以开始下一个版本的规划和开发了。

了解测试结果

进入迭代-测试任务，可以查看测试任务的当前状态，测试总结，以及被测版本产生的BUG（嗯，接着回去改），赞！

测试任务列表.png

测试任务概况.png

被测版本产生的Bug.png

测试工程师

从接收到测试任务开始，到完成这个任务。

1. 迭代-测试任务，查看测试任务；
2. 迭代-版本，查看已解决需求|已解决Bug，逐一验证；
3. 发现和记录BUG，出现在产生的Bug；

验收测试

如果在实现需求的过程中已经贯穿实施了尽早测试，那么就已经是一个逐步集成的过程了，最后的验收测试也会是一个轻松的过程。

版本发布

可以这样说，如果版本的质量良好，则这个版本就是一个可工作的版本，就是随时可以向市场发布的版本，就是一个不断实现价值最大化的过程。

组织-权限

• 负责提测的开发工程师
  具有版本和提交测试的相关权限。
• 测试工程师
  具有测试任务相关权限。

如果没看到，请进入组织-权限设置。

测试任务权限

测试任务权限可选项.png

版本权限

版本权限可选项.png

关于禅道

禅道的代码结构清晰，国际化也做的不错，概念也比较统一，这里不详述，见 禅道的定制开发。