频繁的迭代产生的测试版本很多时候是不完整的，测试员如何测试这些不完整的代码呢?
“故事”应该从业务价值方面来定义。一个“故事”应该在一个迭代周期内完成。好的“故事”是不容易定义出来的，但是差的故事对测试人员的影响比对开发人员的影响还要大。有时候测试人员需要帮助定义“故事”。
敏捷测试的挑战之三：可接受性测试是否过于简单了?
测试人员如果只是做可接受性测试，只是验证“故事”是否完整，岂不是太简单了?这样怎么能做好测试呢?
其实，每一个迭代都需要额外的测试，而不仅仅是局限于验证“故事”的完整性。
在迭代测试中还要按需进行下面类型的测试 ：
探索性测试：同时学习系统、计划和执行测试，寻找bug、遗漏的特性和改进的机会。
组合交互测试：专注于特性之间的交互。
场景测试：模拟真实世界的场景进行测试。
疲劳测试：长时间地执行软件
业务循环测试：基于月末、季度末等业务循环的边界来执行场景
压力测试：对系统施加强大的压力进行测试
敏捷测试的挑战之四：把测试员作为项目组的一部分
把测试员作为项目组中的一员不是牺牲了他们作为一个组织的完整性吗?
测试员一直被认为是受压迫的对象，经常坐在一起互相诉苦、互相支持。现在是时候结束这种情况了。测试员应该跟开发人员和分析师坐在一起，当项目组中有更多的正式或非正式的沟通时才有可能达到敏捷。
敏捷测试的挑战之五：测试什么时候完成?
没有专门分配的时间来完成测试，我们怎么知道什么时候测试应该结束?
敏捷测试员需要根据项目和产品的风险来调整测试。基本上测试的优先级应该跟“故事”的优先级一致。BUG列表也提供了测试完整性的提示。
一个好的测试员是永远都能找到需要完成的测试来做的。
为什么需要跟开发人员结对进行测试呢?因为开发人员对潜在的错误有一定的洞察力，测试员对约束和错误的时机有一定的洞察力。而他们在一起能使自动化测试更加成功。
文章来源于领测软件测试网 https://www.ltesting.net/
