浅谈Scrum开发与启发式测试

Scrum开发强调的是变化，并拥抱变化，面对变化，对于测试人员同样是一个非常大的挑战。因为和开发人员一样，面对需求的变化，要不断的要挖掘需求，同样也需要搞清楚客户的真正需求。我们知道在Scrum开发的过程中，鲜有完整的需求文档。然而对于测试来说，就会遇到，这个到底是不是bug呢？因为测试的参考系是期望值，不能测试人员说的是什么值，而这个期望值是来至于用户。所以传统的规模化写case和执行以前写的case就不再适用。

Scrum开发过程中，开发人员也是测试人员，因为单元测试和集成测试开发人员做起来会非常有效率，在持续集成过程中，就会形成持续的自动化测试。然而把测试全部都压到前期的单元测试和集成测试的话，风险略大。因为在Scrum开发过程中，所有信息是对所有人员开放的，自己好不容易开发的东西，被自己推翻了，在脸面和心理上都是抵触的。这就要求强大的监督机制，这个监督机制就来自于独立测试，引入第三方测试，也就是我们Scrum每个迭代的系统测试和验收测试。

系统测试需要包含回归功能测试，看当前迭代对以前功能的影响。还有就是新功能的测试开发和执行，验收。

在每个迭代开始，都需要根据Sprint 任务backlog，在开发人员开发的同时，进行评估这个任务是否是可测试的，是的话，验收测试先写。在daily build过了之后，进行一轮build check/smoke test，这一步是为了检验软件的功能模块是否有大问题，是否可以进一步测试。同时启发式测试时覆盖新功能开始排上用场，我们知道，启发式测试就是跟探索测试基础上加上了测试记录和测试模型，是探索式测试有模型可循，还能够记录测试轨迹（这是公司领导层愿意看到的，不能测试完了，领导问测试啥了，你说测过了），同时也有测试设计和测试执行，还有测试结果一并出来，效率提高的同时，还能够应对Scrum开发这种快速迭代的特点。

假如我们还是原来的先写case，细化case，然后产品出来之后再测试，可能我们的需求中间变化了，或者压根这些需求就没有集成到当前产品，需要其他迭代，这种变化会对传统测试一个沉重的打击，就是没有需求。我在一个大公司，这个大公司是从传统的方法转到scrum开发，测试人员开始时还不能够适应这种变化，使用传统的方法，举步维艰。所以引入启发式测试这种测试思想，对了，这是思想，而不是什么测试技术，在测试过程中，依然可以使用各种测试方法，测试覆盖。在这个过程中强调tester的主动性可挖掘能力。

综上，一个scrum迭代中，一个完整的测试需要单元测试、集成测试，同时也需要有功能测试，启发式测试，回归测试以及验收测试。