2、编码阶段：
完成了需求设计阶段，就要开始进入编码阶段了，虽然说开发与测试需要同步的，但是功能还没做完也没法同步去测吧，不过还是有事做的，就是可以同步开始写测试用例，这个就用到DevTest工具了。DevTest主要用于管理测试用例，以及根据测试用例来进行在不同环境下、不同时间下和不同的范围里进行的手动测试与自动测试，并且可以生成报表供评估测试质量和产品质量。
也许有人有疑问，敏捷测试还需要测试用例？我的答案还是“是”又“不是”。
先说“不是”，对于敏捷测试本身而言，我们实际新功能测试中其实没有用到测试用例，完全是根据设计文档来进行测试的（也许又有人来问敏捷好像不需要测试文档，这个在这里不多说，详见我另外一篇文章《结合工具来实现敏捷开发》），所以这个时候是不需要测试用例的；
而为什么又说“是”呢？因为敏捷在不同的公司不同的情况可以有不同的实现方式，我们公司不是做项目的而是做产品的，也就是说像微软的Windows一样，我们公司的产品也是1.0，2.0这样做下去，现在已经9.0了，在这期间，或多或少有很多功能是在不同版本里都有的，特别是那些基本功能，为了测试新功能是否破坏原有功能，我们需要测试这些老功能是否能正常工作，也许有人说，那我只要在测试新功能时测一下老功能就行了，测试用例也不需要吧？是的，也许你们公司不需要，但是对于我们公司而言，特别对于9.0而言，之前所有版本的功能都是老功能，之前的老功能有几百个，几千个，你能在测试新功能时测一下吗？很显然，这个是很难做到的，新功能做完时，一般情况，测试人员会检查是否能正常工作，是否对一些基本功能没影响，至于对其他看起来不怎么搭嘎的功能其实不太会去关注，而且时间上也不允许。这样子的话，测试用例就显得很重要了，因为测试用例从本质上来说就是介绍需要测试的功能点以及怎么去测试它们，把每个版本的每个的功能点都通过测试用例的方式保存下来，测试时想漏掉一个测试点都难。所以测试新功能时没测到的地方，都可以在用测试用例生成测试任务时重新覆盖全面，不过这一步由于测试覆盖面太广，也就意味着所花时间会很多，所以一般情况下，一部分测试点会用自动化测试工具跑掉，另一部分只能人工来跑的也只在最后系统测试的时候做掉。
看了这个“是”与“不是”，大家应该知道我们公司的“敏捷测试”其实是结合了敏捷测试与传统测试，也即是兼顾速度与质量，所以有时候我们称之为有我们公司特色的敏捷测试，呵呵。
在写测试用例的时候，测试人员需要和设计人员进行大量的沟通，以彻底理解这个功能为接下来的实际测试做好准备，“沟通”在敏捷里是一个重要的原则，在实际工作，我们也真正体验到它的好处，只有通过沟通，几个部门之间对于产品才有一个认识高度上统一，才能设计出、开发出、测试出一个好的产品来。不过这点，我觉得大家也只能真正通过实践才能体验，我说得太多，其实也没法让大家信服的。
3、敏捷测试阶段：
好了，写完测试用例了，开发也做完几个功能了，咱们也可以开始测试了，《结合工具来实现敏捷开发》里也讲过，我们公司是采用Scrum方式的，所以会生成很多迭代周期（Sprint），每个迭代周期中会从Backlog里分配一些Story来做，咱们测的也就是做好的Story，其实也就是功能点了。
这部分工作主要在DevTrack中完成
DevTrack的主要用于开发完成功能点编码以及测试人员完成敏捷测试。当需求设计完成后，项目经理会通过DevSpec/DevPlan来分配开发任务给相应的开发人员，并且同时生成敏捷测试任务，而开发一旦完成功能以后，就会在DevTrack中把相应的敏捷测试任务打到“可测试”状态，这样子，测试人员就开始进行测试了，测试完了，就把任务关掉，这个功能点就算测试完成了，项目经理会通过检查测试任务是否已经关掉来判断这个功能是否已经完成。
由于之前测试人员已经把当前迭代周期中的功能点写成测试用例了，对于做好的功能点其实已经从理论上很了解了，所以测试起来就“轻车熟路”了。测试总会发现Bug，但是Bug有严重和不严重之分，我们现在处理Bug的原则是，对于影响到这个功能让客户评估的Bug都必须在这个迭代周期和下个迭代周期中修复，这些Bug可能包括报错，功能彻底没法工作，也可能包括一些页面上的美观，因为我们的产品会定期给客户做评估，以让客户看看做完的功能是否符合他们的要求，所以对于做好的功能点起码需要能让客户能用起来，所以客户会最直接用到的看到的地方就需要优先处理掉。而对于其他普通的Bug，DevTrack会有专门的一个文件夹保存，这些Bug会在Release之前通过优先级来一一进行修复，有些实在优先级很低的或者暂时不能完成的可能就会推迟到下个版本再做或者直接就不修了，因为有时候修一个Bug可能会带来一些意想不到的问题，如果可修可不修的Bug，就不需要冒影响产品质量的风险去修了。
不知道大家有没有注意到，上面说了Bug需要在这个迭代周期与下个迭代周期中修复，为什么不在这个迭代周期中修复呢，其实是这样的，因为测试总是在开发后面开始的，如果一个功能点在一个迭代周期的后期完成，从时间上可能测试无法在这个迭代中完成，但是迭代周期的时间又不是想改就可以改的，所以这种情况下，我们就会在下个迭代周期中把这个功能点测完。不过一般情况下，我们还是建议不要延迟到下个迭代周期中完成，因为一个迭代完成后，我们会给一个Build给客户做评估，如果有没测试完的功能，可能就有一些潜在的影响客户使用的Bug，这样子对销售就会产生不好的影响。所以，解决的方法就是一个功能点开发完成就必须马上让测试测，发现Bug马上修复，如果有功能点到了迭代末期才做好，则已经Check In代码确保没有严重Bug（主要是表明和这个功能最基本的使用），没有Check In 代码的就等到下一个迭代周期再Check In代码，测试也推迟到下个迭代中测试。
就这样子，迭代周期一个个进行中，开发做了一个个的功能点，然后测试就会把这些测完，在这个周期中，开发与测试的工作量都会在DevTrack中被记录，主要是花费时间与剩余时间，从而得到了产品未来的一个进度趋势图，也就是所谓的燃尽图。
4、需求变更：
敏捷是欢迎变更的，客户有啥想法可以随时提出随时改进，我们公司的产品是定期给客户一个Build来进行评估的，所以客户经常会要求做一些更改，对于还没有测的功能点稍微好一点，因为只要改设计文档，但是对于已经做完或者正在做的，已经测完或者正在测的呢？答案当然是也得更改，做好的重做，测好的做完重测，对于瀑布模型来说，这个也许是难以想象的，但是对于敏捷来说，这个是家常便饭了。
在实际操作中，我们可能会用到一个DevSpec的功能，这个功能比较不错，所以我单独提出来说一下。有些时候，如果一个功能已经在测试了，如果突然有了改动，而这个改动也已经做完了，如何通知测试人员重新测一下呢？口头通知？Email？其实都可以，只是有些时候，改动太多，需要知会的人太多，或者改功能的人不知道要通知哪些人，那怎么办？DevSpec有个功能可以自动提醒跟这个功能点有关任何开发、测试人员，让他们知道他们做的事情有改变了。
本文出自seven的测试人生公众号最新内容请见作者的GitHub页：http://qaseven.github.io/
