（3）问：测试过程中是否需要开会？
答：需要，测试人员也会有每日立会，跟开发差不多，也是介绍，昨天做了什么，今天要做什么，之前碰到什么问题。会议效果很好，首先让大家知道其他人在测啥，然后如果有问题的话，大家一起讨论就可以共同进步。另外测试也需要有反思会，看看这一轮发生的问题，为什么有些Bug没有找到之类的。
（4）问：敏捷是否需要特别的测试技术？
答：不需要，敏捷只是一种思想，有一些价值观，它不会教你用什么方法去测试一个产品，只会教你以怎么样的一种态度去做测试，以怎么样的时间安排去开展测试。
（5）问：敏捷是否还是需要回归测试？
答：需要，回归测试仍然属于一个比较重要的环节，不管是敏捷还是传统的测试，只是由于敏捷测试中对时间的要求越来越高，使得本来需要大量时间的回归测试越来越难实施，所以目前的趋势是尽可能把回归测试用自动化测试来实现。对于我们公司而言，这也是一个方向，有些部分也在开始，但是由于产品逻辑比较复杂，很多功能有自动化测试实现会比较麻烦，所以现在我们的回归测试有相当一部分还是人工的方式，当然最终必然是会大部分采用自动化测试的。
（6）问：对于重复的Bug，怎么去处理？
答：其实我也咨询过不少公司，很多公司是不允许重复提交Bug的，所以提交之前需要先去确认是否其他人提交过，我相信这个确认过程应该会花费不少时间，不过对于开发而言应该会减少时间，因为不会出现重复的Bug；当然也有一些公司允许重复提交的Bug，原因也很简单，觉得对于Bug而言，只要是必须修的，发现了就得提，别人提过当然最好，但是就怕别人没提过，你却认为提过就不提了，最后客户发现就惨了。所谓“宁可错杀一千，不可放过一个”就是这个道理了，呵呵。我们公司是允许提重复Bug的，当然是在不知道有其他人提过的前提的，你如果已经知道别人提过了，当然就不能再去提了。
敏捷测试差不多就讲到这里了，也许有人清楚有人迷惑，水平有限，也没法讲得太好，望见谅。如有问题，可以私聊。谢谢大家一直看完！
（全文完）
相关链接：
