四步就能帮你建立敏捷转型所需的测试思维方式

转载：啄木鸟软件测试培训网：www.3testing.com

啄木鸟之家大吕

本文通过四步就可以帮你建立敏捷测试思维方式：

1） 教育、教育、教育！ 重要事情说三遍。

2） 权衡到底需要多少文档

3） 调整你的度量

4） 改变态度

从传统换挡到敏捷，需要做好教育、文档和度量等基础工作。敏捷研发和测试不仅仅只是一个方法，更多是一种思维方式。根据VersionOne调查，88%的商业都在实践敏捷研发，但很多在转型过程中苦苦挣扎，不成功的主要原因一般归结为：“文化习惯和抗拒变化”。

你在尝试变化前，若没完成测试同学正确思维方式的转变，那你的团队实际上正在开启一场失败之旅。

敏捷技术的采用通常都是开发同学的事，实际上，敏捷测试是该过程里面非常重要的组成部分，值得相当大的关注。主要的挑战在于传统的测试方法不能很好的匹配敏捷方法论。若你的团队正在考虑转型敏捷，或你就是正在痛苦转型敏捷的测试同学，可能需要将你的关注点从敏捷方法论扩展到敏捷思维方式。

到底该如何做？

下面将通过四步帮你建立敏捷测试思维方式。

Step #1 教育、教育、教育！

若要测试拥抱敏捷的思维方式，首先必须从教育开始。

1，测试必须教育自己，很清楚敏捷过程究竟需要什么。新的工作流是什么样的?对他们新角色中的期望？

2，测试团队需要在业务中有自己的声音。他们必须有能力影响和说服管理层或敏捷指导小组。他们对采用敏捷是有贡献的以及能感受到组织能考虑他们顾虑，这很重要。这样才能确保各个层面都坚信敏捷的转型。

3，测试必须积极主动投入每个项目。新项目一开始就要通知到测试，并包括他们。他们必须理解业务价值以及对最终用户需求的深入理解。

Step #2 权衡到底需要多少文档

测试依靠文档的传统习惯必须破除，文档必须要创建的期望值必须重新设置。开发开始前需求文档必须写好，这点不再有效。

敏捷就是围绕着用户的不断反馈，通过一个个迭不断打磨产品，这是一个很灵活的过程。这意味着所有你实际依赖的文档必须在研发和设计演进中保持持续更新。

敏捷测试思维意味着要避免测试工作陷入官僚主义或者繁文缛节。测试在低级工作花费的时间越多，类似编写大量测试用用例，那么他们就越少投入真正有价值的活动，比如寻找深层次缺陷。探索式测试同时能自动产生回归测试所需脚本，就是一个非常聪明的做法。

敏捷的环境需要聪明的文档。我们需要接受并不是所有的东西多需要文档化，而应聚焦敏捷过程真正需要的。

实现敏捷过程最难的部分就是要平衡好：既要记录足够的东西帮助将来的知识传递，又要最小化不必要的工作。

Step #3 调整你的度量

对于成功的敏捷测试转型，替换传统测试在度量方面的思维方式可能是最大的观念转变。QA团队和测试同学在过去已习惯度量测试活动完成的跟踪和测试缺陷创建。这些度量跟敏捷研发中关注客户价值是不匹配的。下列“不应该”列表可能让习惯传统度量的测试不适应，但绝对能驱动团队思考匹配业务成功所需的度量。

1，不应该强调缺陷数量。测试发现的缺陷数量并不能有效衡量他们工作有效性。强调数量胜过质量是错误的。一旦测试在缺陷数量方面感到压力，他们很可能会提一堆有争议的缺陷。特性需求、设计差异、没说清楚的需求细节不应归类到缺陷。

2，不应强调每天执行的测试脚本数量。每个测试用例的粒度是不同的，数量容易误导人，应该聚焦交付质量。

3，不应强调测试脚本整体通过率。测试脚本执行过程中没有发现问题并不能告诉我们这个产品就是可用的或符合最终用户的期望。测试，必须站在最终用户的角度，时刻考虑他们需要。

重心应该转移到最终用户的满意度，而不是活动的跟踪度量。若公司每位同学都能聚焦给用户交付最好的产品，成功就是很自然的事情。

Step #4 改变态度

沟通和协作的意愿对敏捷的成功至关重要。在过去，单独存在的QA部门定位自己是产品质量的守门员，将自己站在开发同学的对立面，是经常能成功做到的。现在时代不同了，需要改造测试同学：教育他们，赋能他们，他们就能交付更大的商业价值。

好比双向的道路，自上而下赋能测试，自下而上考虑他们的发展。这能协调整个公司目标的一致性，才能保证每一个部门和每一名员工都能帮整个团队朝同一个方向努力。

每一位同学尽他最大可能给用户创造最好体验。

顾翔凡言：

自动化测试的目的主要是建立信心，手工测试的主要目的是发现缺陷。

麒怀科技：专注于敏捷转型，产研效能质量提升