“测试敏捷化”是什么

发布时间:2017-12-15

几年前如果我听到“测试敏捷化”这个词,估计给的反应是“一脸懵逼”,什么鬼?

而这个“几年前”大约可以追溯到五、六年以前,当时的自己对敏捷是什么几乎是完全不知道是什么状态;对于测试这件事情也仅仅是停留在黑盒的认知层面,一只脚刚刚从报刊行业踏进互联网软件领域,对这个行业中发生的一切事情都充满了好奇和无知,以及随之而来的无畏。

当时身处中国三大手机业务运营商中的一家,因为一个非常偶然的契机从新闻文字类工作中转向成为一个软件的项目经理岗位,从那以后才了解到有测试这么岗位;

而说起敏捷这件事情,则是离现在更近的过去。作为另一种和以往接触的项目管理模式完全不同的模式,颠覆的不仅仅是团队中各个成员的工作和管理模式,更多的是全体团队的工作模式的变更。

今年夏天在美丽的大连,有幸参与了双态IT联盟-测试敏捷化白皮书的编写,并且通过这次的编写工作,修改了较小部分(并没有很多)以前对于测试的认识,当然了,这些认识只是被修改,并不能决断地说哪些是对的,哪些是错的。

1.jpg

如上图为白皮书的最后成书。也许还会再有这样的机会,不过这辈子如果就只有这一次,也够了,体会过就好。

在大连的短短三天(应该来说是两天半)内,给我这样一个长期在研究敏捷,而对测试没有什么概念的人来说,颠覆最大的,毫无疑问是大家对于我们的主题究竟是应该叫敏捷测试化还是测试敏捷化的问题。

在今年夏天之前的我的价值观中,一提到敏捷,再提到测试,第一反应就是一个实现了敏捷的团队,在整个过程中包含了测试的部分。

甚至有些情况下,在某些组织里,是弱化了测试的概念的。

通常我们也说,虽然希望团队里有各种各样不同的岗位的成员,但也是因为这样的“希望”“各种各样不同”,导致我们往往会弱化一些岗位和岗位之间的壁垒。

而自从化测试做法的引入,更加使得我们在某种程度上弱化了“纯测试”这个岗位。似乎这不再是一个职位,而是一个角色。

敏捷的世界里,岗位常常不会被当做岗位来看,而是一个角色,比如“敏捷教练“是一个角色,“产品负责人”也是一个角色。甚至我们在团队中,对程序员的要求也打破了前后端的壁垒,前端、后端往往变成仅仅是一个“角色”。

敏捷之于团队,推崇的做法往往是“cross functional”针对这个词,各人有各人的不同看法,在我看来,这个词对于一个把敏捷做到极端的团队来说,是指每个人都可以做别人的岗位的工作。而把这个团队中的任何一个人放到我们所谓的C位来看,都可以独自完成工作。

2.jpg

如上图美剧《犯罪心理》,就描述了这样一个跨职能的团队。团队中的任何中的一个人拿出来都可以独立承担工作,这样的一些人就组成了一个跨职能的团队。

再回到上面讨论的关于敏捷和测试的问题中去,再来看看什么状态下会变成“测试敏捷化”吧。也是我们最终定下来的白皮书的书名。

放到今天再回过头来想一下,我还是对这个名字保留意见的,在我个人看来,一个团队,不可能因为某个角色或者某个岗位,就可以直接驱动使得整个团队变得“敏捷”起来的。

我们先来看看敏捷领域中的其他的一些驱动敏捷的方法论吧。TDD这个最广为人知的实践:测试驱动开发,要知道,这里的测试指的是“测试这个动作”或者“测试用例”,而绝非是测试这个“角色”。

那么其他的呢,BDD,ATDD,DDD这些更大程度上都是指从业务角度驱动来描述敏捷的驱动力。

而上面的这些,都不是一个岗位或者一个角色来推动的敏捷的,原因是,大家都很清楚的,对于敏捷这件事情来说,推进大半情况下是组织领导下达命令-试点团队先行(注意,是“团队”)-试点团队推到更多试点团队-形成组织内部造血机制—飞轮效应飞起来,组织整个跑起来,这样的道路。

这次的测试敏捷化白皮书,是我的认知范围内,第一次从测试这个角色或者岗位为出发点,推进后续的工作,最终把敏捷的力量推进到整个团队乃至组织中去,其实后续的发展方向与目标还是整个团队的组织,甚至在白皮书中,定下了“测试敏捷化成熟度模型”。该模型分成N层次来描述怎么样的敏捷团队才是好的,推荐的敏捷团队做法。

这次的测试敏捷化白皮书,是我的认知范围内,第一次从测试这个角色或者岗位为出发点,推进后续的工作,最终把敏捷的力量推进到整个团队乃至组织中去,其实后续的发展方向与目标还是整个团队的组织,我们通常所说的殊途同归就是这个意思罢。

这条路在我看来并不容易,其实不管是什么角色促使整个团队敏捷这件事情,都很不容易,自下而上的推本来就是一件非常困难的事情。

但是,我们既然已经做了这件事情,那就相信,这也许是个可以行走下去的方向,努力前行,未来可期!

Copyright © 2020 All Rights Reseverd Designed by 5thspace.net      备案号:沪ICP备15017019号-1