敏捷开发？敏捷测试？你怎么看？

案列：当开发人员需要对功能进行比较大的修改，估计需要两天时间才能完成代码，这时测试人员反对这样做，本来只有5天测试时间，验收测试已经很紧张。如果再延迟两天，测试没法完成。而产品经理认为，你们不是在用敏捷测试方法，应该测得很快，三天应该能完成测试工作啊!

敏捷测试当然不能简单地理解测得更快，绝对不是比以前用更少时间进行测试，也不是将测试的范围缩小了或将质量降低来减少测试任务。

敏捷测试应该是适应敏捷方法而采用的新的测试流程、方法和实践，对传统的测试流程有所剪裁，有所不同的侧重，例如减少测试计划、测试用例设计等工作的比重，增加与产品设计人员、开发人员的交流和协作。在敏捷测试流程中，参与单元测试，关注持续迭代的新功能，针对这些新功能进行足够的验收测试，而对原有功能的回归测试则依赖于自动化测试。由于敏捷方法中迭代周期短，测试人员尽早开始测试，包括及时对需求、开发设计的评审，更重要的是能够及时、持续的对软件产品质量进行反馈。

在敏捷方法中，需求变化比较快、产品开发周期很短，我们目前采用四周时间，也就是每个月发布一个新版本。开发周期短，功能不断累加，给测试带来很大的挑战，测试流程要做相应的调整。

在对新功能进行app功能测试和回归测试策略上，测试任务简单地可分为新功能测试和回归测试。在敏捷方法中，针对这两部分的测试建立相应的策略，加上自动化测试，以提高测试的效率，最大限度地降低质量风险。

不需要测试用例，直接基于用例、基于对需求的理解来完成新功能的验证。即使要写测试用例，只要保证各个功能点被覆盖，不要过于详细。

持续地进行验证，一旦某块新代码完成, 就开始验证，而不是等到所有代码完成后才开始测试。这也包括参与到单元测试和集成测试中。

实施端到端的测试，确保完整的业务流程的实现，同时，也容易发现业务逻辑不够清晰、不够合理等各方面的问题。

阅读代码来发现问题，可以和开发人员工作保持同步，消除测试周期的压力。

基于经验，可以实施更多的探索性测试、组合交互性测试和用户场景测试，更有效地发现埋藏较深的缺陷。