软件测试培训

400-111-8989

热门课程:

软件测试培训 > 软件测试职场

我所误解的敏捷测试团队

发布：软件测试培训
来源：网络
时间：2017-04-17 15:44

在看过了一些有些的关于敏捷测试的文章(比如这篇)，听了许多人在谈论敏捷测试后，我开始意识到敏捷测试跟自己一开始的理解并不太一致。

从一个问题问起

你认为什么样的团队适合打造成敏捷测试团队?

不知道你看到这样的问题时，会怎样去想?或者不妨你可以用几秒钟的时间来想一想这个问题。倒计时，5，4，3，2，1……

叮!时间到。笔者一开始接触到敏捷测试的概念的时候，其实是陷入了一个狭隘的误区(产生了一个误解)，认为敏捷测试团队是为“测试(QA)”团队提出的概念，是为了改变现有测试团队的问题而诞生的。其实这是错误的。我们先来看一看敏捷团队的基本特征之一：

按照在采用敏捷软件开发方式的组织中，配合敏捷软件开发团队进行测试的整体方法。在这样的组织里，通常来说，都不会存在一个专职只做软件测试的部门，因为测试被内嵌入整体研发过程，并且“开发人员”、“测试人员”这些角色的概念和边界也被模糊化，你中有我、我中有你，有基本的分工，但更重视的是彼此合作以便达成团队(甚至部门、产品、组织)的整体目标。——徐毅

这是来自知乎的一个回答(的一部分)，同样的，《敏捷软件测试：测试人员与敏捷团队的实践指南》(下称“指南”)也提出了这样的思想。即不存在所谓的“敏捷测试团队”(传统意义的测试)，只存在“敏捷团队”。在这样的团队中，每一个人都参与到了“测试”这样的活动中。

这样的团队有什么样的特点呢?我们说几个团队文化上非常明显的。

首先，质量上，“以如何定义软件质量的可接受水平的角度来思考组织的质量哲学”。在传统的测试中，我们经常可能会出现这样的一些评估标准，例如“BUG修复率达到85+%，是达到上线的标准”，“所有的崩溃必须全部修复，才能上线”，“测试认为这个问题非常严重，不能带到线上”等。而在敏捷的思想里面，这些都是视具体情况而进行评估的。

其次，整个团队负责质量。当敏捷团队实际运转起来时，团队中的每一个人都参与了质量的保证，不论是产品、开发，还是测试。

第三，合适的节奏。敏捷团队中整体的团队速度是一致的，不存在传统测试中经常发生的场景：开发提测后，只剩下测试在拼命的加班完成后续任务。敏捷团队中依赖大家以最好的状态进行工作，高强度的工作并不是常态，加班只是特例。

第四，有效的沟通方式。传统测试中经常遇到一些实际的困难，例如开发团队在A地办公，而测试团队却在B地办公;或者与一些第三方的公司/团队配合的时候，也需要有效的沟通。敏捷的思路非常强调沟通的连续和有效。通过晨会，通过沟通工具改善，通过角色的转换来保证沟通的高效。

这样的团队中，难免也会出现文化的冲突，尤其当涉及到专家团队的利益时，或者第三方团队的文化产生冲突时。

那作为传统的测试团队，我们需要克服哪些障碍，才能更适应敏捷团队呢?

适应敏捷团队需要克服的障碍

1、丧失身份

由于众多的原因，测试人员坚持组织拥有独立的质量保证团队。经常会担心优先权被开发抢走，害怕缺乏敏捷所需的技能而失去竞争力，害怕在新的团队中迷失方向，害怕在开发团队中得不到支持等。这些是我们需要克服的第一个障碍。

2、缺乏培训

在敏捷团队中，如果没有经过有经验的人的良好培训，可能会发生一些遗憾的情况，例如会有人因为不理解或者不适应自己的新角色而放弃。这样的团队中，尤其是团队建设初期，有效的培训是必要的。

3、过去的经验/观点

当习惯、并乐于过去的经验、项目迭代、沟通方式、软件发布理念时，敏捷这样的新概念就难以理解，认为改变的成本高，看不到明显的意义。并且当敏捷推进产生困难时，这样的角色就会发出尖锐的疑问。甚至拒绝再给敏捷尝试的机会。