敏捷开发对测试的影响
什么是敏捷开发
敏捷开发对测试的影响
不同的公司或组织使用“量身定做”的敏捷开发对测试造成的影响相差也很大，但通常会包括以下影响：
需求和文档通常很少，并且经常会以“参考案例”或者“验收/测试标准”的形式出现。
需求会经常性的发生增删或者变更（有关这一点我会着重在后面的篇幅阐述如何应对）。
迭代开发-测试周期（Sprint）通常会压缩在1-3周内完成，新功能测试和回归测试都必须在每个Sprint内完成。
测试人员需要与开发人员、项目管理、产品经理在内的所有团队成员开展更为紧密的合作。
需要时刻关注每日项目的状态以及所有人都要参与每日“站立”早会。
敏捷项目中通常会包含以测试为驱动的开发，例如单元测试及自动化单元测试，API层级的自动化测试，基于探索性和基于会话的测试，持续集成以及UI测试自动化等。
测试人员可能会大量参与充实需求以及验收标准的工作，其中包括功能性和非功能性需求。
在上述的这些影响中，实际工作中我们遇到的比较多的情况应该是第二点，下面我将着重讲一下在敏捷开发中如果需求不断变化怎么办。
如果需求不断变化怎么办？
在我们日常的开发过程中，应该经常会遇到原始需求发生变化或者验收标准发生变化的情况，甚至尽管有些时候这些需求变化会跨越多个Sprint，但在实际工作中对于需求的变化，我们仍然将其视作一件可以接受甚至可以预期的事情。对于那些希望可以预先确定需求并满足需求的公司或者组织来说，这是一个普遍且耗费精力的问题。如果期望需求保持稳定在合理的范围内，不妨尝试以下方法：
尽早与项目涉及的人员沟通，以了解需求可能如何变化，以便在可能的情况下提前制定替代的测试计划和策略。
如果程序的初始设计就考虑到某些适应性，以便以后的更改不需要从头开始做，未雨绸缪会很有帮助。
如果对代码进行了良好的注释以及文档撰写，将使开发人员更容易进行更改。
尽可能使用某种快速原型制作，以帮助需求提出方确定其需求并最小化更改。
项目的初始时间计划表应留出一些与需求更改可能性相对应的额外时间。
尝试将新需求移至程序的“第2阶段”版本，同时使用“第1阶段”版本满足其原始需求。
协商仅允许将易于实现的新需求引入项目，同时将更困难的新需求移至程序的未来版本中。
确保需求方和决策层了解需求变更对项目计划的影响、固有风险以及重大需求变更的成本。然后，让决策层或需求方（而不是开发人员或测试人员）决定是否需要进行更改。
投入适当的精力进行变更的风险分析，最大程度地减少回归测试的需求。
在测试用例/场景中设计一些灵活性，当然这并不太容易做到，最好的选择是最小化测试用例中的细节。
少关注详细的测试计划和测试用例，更多地关注随机或探索性测试，当然同时也要了解这样做带来的额外风险。
如果需求变更是一个持续存在的问题，并且如果大家都认为可以预先确定需求并保持其稳定是不合理的，那么就需要弄清楚为什么期望与现实严重不符，必要时可能会需要重构整个敏捷开发方法。重构现有的敏捷开发方法有时也是一种无奈之举。需要注意的是，在敏捷过程中，处于Active Sprint中的需求/验收标准应该保持稳定；如果它们在Sprint期间发生变化，则表明该项目的敏捷过程存在问题。