在与不少测试从业人员讨论到敏捷的时候,被问得最多的大约是两个问题:“到底什么是敏捷软件测试?”,“敏捷软件开发还需要测试工程师吗?”。前一个问题是对于敏捷测试本身定义的疑问,第二个问题则是对敏捷开发将测试工程师排除在外的担心。其实,在探寻这两个问题答案的过程中,我们可以更清晰的了解敏捷软件开发中测试的工作定义,测试价值观,以及敏捷开发中开发与测试工程师的配合。鉴于这两个问题的意义,在本敏捷测试专栏的第一篇文章中,本人尝试从自己的实践出发,尽可能清楚的回答这两个问题。
确实,相对于敏捷开发红遍大江南北的状况而言,对敏捷测试的讨论则低调得多。敏捷联盟定义了敏捷的4个价值声明,以及伴随的12条支持原则,这12条原则中没有一条单独提到测试。这是不是意味着测试在敏捷开发中并不重要呢?实际上,如果仔细研读敏捷的12个原则,以及各种不同的敏捷实践,就会发现,测试在敏捷开发中占有非常重要的地位。无论是原则中的“频繁交付”,还是对“可工作的软件”的度量,或是敏捷开发实践中的“测试驱动开发”,“行为驱动开发”,都离不开测试的支持。在本人看来,敏捷开发中不把测试单独拿出来描述的原因,恰恰是因为在敏捷开发中,测试不再是一个单独的、和开发独立的过程,而是变成了驱动开发、衡量产出的主要的手段,成为了敏捷开发中所有工程师在工作时必须时刻考虑和实践的一个部分。简而言之,敏捷软件测试更多的是一种理念,而非过程。
既然是这样,为什么我们还要在这个专栏中专门来讨论“敏捷软件测试”?本人接触过不少软件开发和测试工程师,他们所处的组织有的正在努力向敏捷开发转型,有的已经实践了一段实践的敏捷开发,但由于由来已久的工作习惯,他们中的绝大多数并不能自觉的认识到测试在敏捷开发中的关键作用,而是有意无意的将测试仍然看作是与开发截然分开的“下一个阶段”,导致在实践敏捷开发的过程中遇到种种问题:要么是忽略了代码质量,导致在频繁的迭代过程中,每一个迭代的问题层出不穷;或是沿用原有的方法安排对系统的系统测试,导致测试团队疲于奔命,却总也赶不上开发所要求的进度。在这种情况下,专门来讨论敏捷软件开发中的测试,也就是敏捷软件测试的话题,对这些工程师应该会有一些帮助。
那么,到底什么是敏捷软件测试?很难给敏捷测试下一个精确、完善的定义,在本人看来,接纳了敏捷的核心价值观(沟通,简单,反馈,勇气,尊重),在敏捷软件开发过程中开展的测试就可以被称作是敏捷软件测试。因此,敏捷软件测试并不是一个与敏捷软件开发同一层次的划分,而是敏捷软件开发中的一部分,与传统的测试不同,敏捷软件测试并不是一个独立的过程,相反,它与整个敏捷开发中的其他活动交织在一起,处处都能看到它的影子。由于敏捷软件测试并不倾向于一个单独的过程定义,本人拟从敏捷软件测试与传统测试观点的比较、敏捷软件测试中采用的方法、测试工程师在敏捷软件测试过程中的工作等方面来阐述之。在这篇文章中,我们主要从宏观的角度来描述敏捷软件测试,而在本专栏的后续文章中,我们将对敏捷软件测试中采用的方法、工程师在敏捷软件测试中的工作内容等进行进一步的描述。
敏捷软件测试是建立在敏捷核心价值观的基础上,为了更生动的描述其与传统软件测试的区别,本人从自己的实践经验出发,尝试给出包含了本人认为包含了敏捷测试关键要素的“敏捷测试检查表”:
项目 | 检查点 | 注释 |
团队 |
|
|
反馈 |
|
|
质量文化 |
|
|
开发测试 |
|
|