让测试敏捷起来.

产品需求变更频繁，缺乏详细的需求和设计文档，开发代码质量不高，提交测试延期而压缩测试时间等。这些问题是我最经常听到的来自测试团队的抱怨。我们和过程改进一起也一直在尝试推进产品和开发持续的改进。但面对快速变化的业务需求和项目进度的压力，这些问题依然存在。与其不断地抱怨产品和开发，不如我们自己积极面对这些难题并想办法解决。

问题1：需求变更频繁，缺乏详细的需求和设计文档，文档更新不及时。

• 到底是通过严格的研发流程增加需求变更的阻力，还是我们自己尝试去适应需求的快速变化？从公司的层面看，产品经理更倾向于迎合业务发展和最终用户的需求，而不是去体谅后端开发和测试人员的痛苦。
• 敏捷宣言主张“个体与交互胜过过程和工具”、“可用的软件胜过完备的文档”。缺乏文档使得我们难以依赖文档设计测试。解决这个问题的关键是“个体与交互”，测试不能总躲在后面等别人把写好的文档给你，我们需要更积极、更密切的沟通来弥补文档的不足。
• 我在考虑成立专门的Team（可以叫它是系统组、或者是架构组），为每条业务线配置专门的测试人员（要求对产品部门和测试工作都富有经验，承担Test Consultant角色）。这个角色相当于测试团队和产品的接口人，与产品保持密切沟通，建立起测试和产品的桥梁，随时把握业务需求，把业务需求细化为可测试性的文档（例如，丰富业务细节和异常业务处理等内容），为测试执行团队制定测试计划和策略。

问题2：开发代码质量不高

• 敏捷测试（Agile Testing）的一个原则是“把开发人员看着测试人员的客户”。凡是可以帮助开发提高代码质量的地方，测试都可以去做。
• 敏捷开发追求持续的集成，持续的进行单元测试和回归测试。我们计划与过程改进一起推进Check-In Test, BVT, daily regression test的自动化，让开发人员随时可以得到关于代码质量的反馈（例如，每一次的check-in是否break了build），帮助开发人员生产出具有良好可测试性的代码，进而提升测试的效率。帮助开发，就是帮助测试自己。
• 通过自动化和测试报告，建立可见的质量度量体系，让产品和代码质量反馈持续可见
• 通过工具（ReviewBoard）促进Code Review的进行

问题3：提交测试延期而压缩测试的时间。面对更快的产品迭代，如何在更短的时间完成测试任务，让测试变得越来越高效？

• 合理的利用自动化。自动化并不是越多越好。自动化可以保证已有功能的回归。对新增的功能，需要评估到底是自动化效率高还是手动测试效率高？我更倾向于对新增功能执行手动或者半自动化的测试，而在产品发布之后再补充完善自动化回归脚本。随着开发的进行，产品质量的提升，以及对产品了解程度的加深，对自动化测试进行持续改进，提供更大的覆盖，更好和更快速的验证。
• 回归测试=自动化+diff。作为一个偷巧的办法，某些情况下，可以对代码进行diff 检查，比较代码改动的部分，让测试更有针对性。
• 让测试用例更有效率，避免在测试用例上面浪费太多的时间。测试用例不是越多越详细就好。太详细的测试用例会降低测试效率，增加维护成本，并且会限制测试执行人员的思维。如果你的Bug大部分是通过执行测试用例发现的，那说明有两个问题：你在测试用例上面浪费了太多的时间，或者你在测试经验上面比较欠缺。如何定义测试用例的粒度——从业务出发，测试用例只要覆盖所有的业务功能和逻辑就够了。而数据检查、边界条件的测试用例，就留给测试人员去执行探索性的测试吧，希望每个人都增强探索性测试的意识。
• 类似Google的Testing on the Toilet，为各系统维护一套测试点的checklist，越精简越好。让负责测试的人员（尤其是新手）能在几分钟之内就知道有哪些测试点是被遗漏的、需要关注的。我们已经把部分的checklist放在在twiki上了（例如引擎测试），希望大家都能参与进来，不断补充完善。
• 前端应用的测试：UI变更频繁，测试非常容易失效？是否可以考虑把测试重心向相对稳定的接口测试倾斜？大家可以一起来思考。
• 最后再提醒大家：开发和测试团队具有同样的质量目标和质量责任。开发人员有义务对产品的可测试性和可自动化负责。如果你有这方面的需求，一定要跟开发人员讲出来。

作者: 

元仲