在敏捷开发中, 我们都知道要将功能切割, 每次做些小功能, 然后持续交付价值给客户.
因此当你在开发每个小功能时, 你会不断进行以下事情:
1. 从主干 check out 程序代码到分支
2. 开发团队在分支进行开发
3. 小功能开发完后, 将分支程序, merge 回主干
4. 在主干进行测试
可是通常这样在第四步时, 就会遇到一堆错误. 这是因为小功能还没确认是否正确, 就和整个系统和起来测试, 将导致问题多多. 如果有很多小功能要放进来时, 这种情况就会更恶化.
因此有些团队可能会这样做:
1. 从主干 check out 程序代码到分支
2. 开发团队在分支进行开发
3. 开发完毕在分支进行测试
4. 在分支测试通过, 将分支程序, merge 回主干
5. 在主干再进行测试
这样做之后, 可以让小功能测试比较稳定后, 再放到主干来. 可是遇到多个小功能同时开发时, 还是会遇到你进来的东西会跟别人不和, 导致整个系统无法运作.
所以下一步你会在这样改进:
1. 从主干 check out 程序代码到分支
2. 开发团队在分支进行开发
3. 开发完毕在分支进行测试
4. 把主干的程序 merge 到分支
5. 把 merge 完后的分支程序进行测试
6. 将 merge 完后的分支程序, 再 merge 回主干
7. 在主干再进行测试
因此你先确认小功能是否运作正常; 然后将主干的程序合并到分支后, 再确认是否正确; 最后合并到主干后, 在做一次确认是否都正常.
看起来到目前为止, 应该考虑的很周到.
可是... 有多少人这样做呢? 似乎很少, 为什么正确的事情, 大家都不做呢?因为这样反复进行的测试工作, 如果你没有自动化, 你就会没有空, 或者讨厌去做这样的事情, 导致大家就很少去做.
有些人说没问题, 我们会把测试自动化搞好, 这是小事. 于是他们就开始处理测试自动化的问题, 接着你又会发现到:
要能自动产生 build, 否则每次手动要花多时间
测试环境要自动准备好, 没有干净的环境, 测试结果可能会有影响
每个小功能整合到主干后, 有可能之后出问题, 要重新回上个版本, 这个事情若是手动做, 也是件崩溃的事情
……
所以再做下去, 你会发现整件事情没有你想象的单纯, 若是没有落实 continuous integration 或是 continuous delivery, 你永远没有机会达到 agile 所说的, 每个 iteration 持续交付价值给客户. 你所有的, 将会是至少落后一个 iteration 的交付. 因为在 agile 中, 每个 iteration 测试和开发要花的代价不同, 测试的代价是随着 iteration 的进行, 逐渐高升.
David: 老板, agile 不是只是去上上 scrum 课就可以的.
经理: 测试自动化我早就知道了, 所以 agile 根本没有什么好学的啦
David: …
最新内容请见作者的GitHub页：http://qaseven.github.io/
