熊志男:敏捷测试头脑风暴

零基础学产品,BAT产品总监带,2天线下集训+1年在线课程,全面掌握优秀产品经理必备技能。了解详情

2012年11月3日下午,外面滂沱大雨使得气温骤然下降,在中国科技会展中心的一间会议室里,却被热烈的气氛包围着。嘉宾们和参会者的大脑高速运转产生的热量,在室内空调热力配合下,使得屋内显得很热。

我也在积极思考“敏捷”这两个字的含义,努力着在以往的测试实践和学习经验中寻找相关的体会。我希望通过向嘉宾提问更多的问题,来获取更多的知识。

  我想起我头脑中也产生过一下几种对于敏捷测试的态度:

 一、敏捷崇拜者,因为敏捷是新技术思想,所以和其他的新技术崇拜一样,当时年轻的心总想学习先进的新的知识来超越自我。

  二、旁观者,经过对于敏捷的初浅认识和测试实践,发现敏捷并没有真正出现在我的实际工作中。而且,敏捷是一种应用在整个开发流程中的思想模式,那么只有在敏捷开发流程中的测试才可称之为“敏捷测试”。那么单独的“敏捷测试”应该是个伪命题了。而且我又适应了现在的工作,无法改变开发的流程,那么敏捷与我无关了?

 三、敏捷反感者,当然这不是我自己的想法,但是我可以清楚得感觉到一些合作过的同事、同行是持这种态度。他们已经适应了现有的流程,对于敏捷的第一印象“敏捷就是没有详细的文档”,那怎么行,我们需求从哪里获取?测试用例描述不细致,我们测试执行参考什么?流程如何控制?其实我不清楚他们是害怕还是不愿去接受新鲜事物。

敏捷体验设计师应该具备的12项技能
  在参加这种技术交流时,常常感觉很耻于说出自己没有什么敏捷的经历。好像这就证明我能力有限,所经历的公司水平有限一样。我想无论是否是我低估了自己和自己所处的环境。还是要面对自己,才能够成长进步。

 那么记忆中与敏捷沾边的工作,就是2009年在广联达公司的测试工作。印象最深的几点:

  一、测试用例简化,以往的花了很长时间编写的测试用例,除了在第一轮测试时候会参考执行以外,作用非常有限,而且维护困难,每次例会讨论用例维护的方案总是不了了之。用例简化后,针对每个功能点列出简要的测试点在QC中,而不去写详细的用例。在每一轮的测试过程中都会去维护增加新的测试点。

 二、测试提前,区别以往等待开发人员给出正式版本后再进行测试。而是,在得到需求的第一时刻,列出相应的测试点并发给开发人员确认,在与开发的沟通过程中得到对于需求的统一认识。然后在开发做完每一个新功能时,一个测试和一个开发坐在开发的工位上按照测试点,逐一在本机上验证。这样就不用从服务器上等到正式版本再测试了。

 三、组织结构,拆散原来独立的测试部和开发部,根据产品、功能、地区版本划分,开发和测试以大概2:1的比例组成一个团队,当然由于需求人手紧张,所以一个需求人员会同时参与几个团队的工作。这样转变了原来开发与测试的对立局面。

 四、每日站会,其实当时对于每天早上开会有些反感,也许是因为还没有真正体会到他的意义。

如果说敏捷中的测试必然都是需要自动化的,那么我们当时的自动化测试只是应用于冒烟测试和基本功能验证。无论是不是完全意义上的敏捷,还是有所收获的。记得后来曾经参加其他公司的面试,说起敏捷经历,我还会拿出此段经历来充数,汗!

那么回到现在的测试项目中,是否可以按照敏捷的思想来施行呢?会起到什么作用?解决什么问题?

 从贺炘老师的PPT中看出,分析现在项目是否适合敏捷可以从以下几点来看:

  1.项目特点

那么我们的项目是离岸的测试项目,作为开发的客户是在美国,在项目特征上我们无法实现开发和测试结合的团队结构。而且由于时差问题,我们发出的问题只能在第二天得到答复,就无法实现敏捷所要求的及时反馈和沟通。

 2.支持环境

正因为我们是独立的项目,在自主性上比较强,采取何种形式的测试流程和方式,不会太受制于人。另外我们的自动化回归测试一直在比较稳定得运行。以此来说,是属于比较适合的。

 3.人员素质

我们的项目一直以来秉承着建立一个小而强的团队的原则,仅有的5个测试人员,从业务水平、代码能力、测试能力方面来说,都是能够独当一面的。

那么是无法做到敏捷了?敏捷的真谛是什么?是一定要符合几个关键字吗?还是一种解决问题的思路呢?

今天的会议中嘉宾们对于敏捷的意义探讨有几点:快速的价值交付、更加透明和有效的沟通、减少项目中的不必要的时间浪费。

回过头来,这不正是我们项目中存在的问题吗?

不得不说我们有很多人已经非常习惯于这个功利社会的游戏规则,也许一个人推动敏捷测试、推动探索测试、推动自动测试,真正目的是为了绩效、薪资和升迁。我们不能否认这是错的,但是如果解决了不了实际问题,反而由此产生的很多问题会给这些优秀的思想和技术脸上抹黑。还是在以后的项目中,踏踏实实学习,小心翼翼实践吧,共勉!

祝给予赞赏的伙伴,2017年发大财!

评论( 0

写下你的想法

推荐阅读