敏捷测试的挑战（转）

　　敏捷测试的挑战之一：测试员是否不再需要了？
　　既然有开发人员做单元测试了，我们还需要测试员吗？有些项目团队采用了敏捷开发方式后把测试员都给解雇了，然后过了不久他们就后悔了。
　　测试可以是除QA或测试员外的人来做，例如业务分析员，有些项目团队让开发人员来做接受性测试。
　　但是有专门的测试员带来两个好处：
　　1、 专注于用户使用而不是软件的技术实现
　　2、 专注于发现软件的错误而不是证明完整性
　　敏捷测试的挑战之二：测试不完整的软件
　　频繁的迭代产生的测试版本很多时候是不完整的，测试员如何测试这些不完整的代码呢？
　　“故事”应该从业务价值方面来定义。一个“故事”应该在一个迭代周期内完成。好的“故事”是不容易定义出来的，但是差的故事对测试人员的影响比对开发人员的影响还要大。有时候测试人员需要帮助定义“故事”。
　　敏捷测试的挑战之三：可接受性测试是否过于简单了？
　　测试人员如果只是做可接受性测试，只是验证“故事”是否完整，岂不是太简单了？这样怎么能做好测试呢？
　　其实，每一个迭代都需要额外的测试，而不仅仅是局限于验证“故事”的完整性。

　　在迭代测试中还要按需进行下面类型的测试 ：
　　探索性测试：同时学习系统、计划和执行测试，寻找bug、遗漏的特性和改进的机会。
　　组合交互测试：专注于特性之间的交互。
　　场景测试：模拟真实世界的场景进行测试。
　　疲劳测试：长时间地执行软件
　　业务循环测试：基于月末、季度末等业务循环的边界来执行场景
　　压力测试：对系统施加强大的压力进行测试
　　敏捷测试的挑战之四：把测试员作为项目组的一部分
　　把测试员作为项目组中的一员不是牺牲了他们作为一个组织的完整性吗？
　　测试员一直被认为是受压迫的对象，经常坐在一起互相诉苦、互相支持。现在是时候结束这种情况了。测试员应该跟开发人员和分析师坐在一起，当项目组中有更多的正式或非正式的沟通时才有可能达到敏捷。
　　敏捷测试的挑战之五：测试什么时候完成？
　　没有专门分配的时间来完成测试，我们怎么知道什么时候测试应该结束？
　　敏捷测试员需要根据项目和产品的风险来调整测试。基本上测试的优先级应该跟“故事”的优先级一致。BUG列表也提供了测试完整性的提示。
　　一个好的测试员是永远都能找到需要完成的测试来做的。
　　为什么需要跟开发人员结对进行测试呢？因为开发人员对潜在的错误有一定的洞察力，测试员对约束和错误的时机有一定的洞察力。而他们在一起能使自动化测试更加成功。
　　测试员应该自动化可接受性测试，使用与开发环境一样的编程语言来编写可接受性测试的代码，重用单元测试的框架，使软件更加可测。
　　利用“灰盒”测试。设法弄清楚系统各模块之间的关系，分析变更的影响，看什么是需要测试的，什么是可以不测试的。弄清楚bug，bug的表面现象是什么？产生bug的根本原因是什么？弄清楚风险，使用解决风险的测试策略，调整测试目标。
　　敏捷测试的挑战之六：我们还需要bug跟踪系统吗？
　　有些人说敏捷团队不需要跟踪bug，只需要把发现的bug尽快修正就行了。
　　这种做法只适用于开发过程的测试，如果是一个完整迭代的测试，你就需要bug跟踪系统，因为有些bug不是在这个迭代马上修改的。
　　敏捷测试的挑战之七：用什么质量标准来度量敏捷项目？
　　其中一个最好的质量标准是发布后逃逸的bug数量。不辛的是，这是个事后的衡量标准。
　　采用每个迭代后计算逃逸bug数量的方法能标识代码的质量．