小型团队的测试该何去何从

前言:很不幸,我不知道自己应该不应该谈论这件事,“小型团队的测试该何去何从”,我没有十足的经验,更没有十足的理论,然而回想起昨日大家一起的讨论结果,我到现在依然沉浸在失望和苦闷的滋味中,究竟是增强开发人员的自测能力以及自我驱动力还是增加测试人员来做问题的过滤?

首先,我们先抛开需求分析,为什么这么重要的环节要先抛开,因为国内的小型团队面临着无法避免的严重问题:

  1. 客户压根不懂需求,遇到一个稍微懂一些需求的客户,那都是上天对你的恩赐。
  2. 时间太过紧迫,经常在客户眼里,这个什么功能简单的很,实现起来不就是一会儿时间的问题,都不需要什么技术。
  3. 迫于市场压力和成本考虑,前期做大量的需求分析压根无从下手、也容不得你多做考虑。

当然,我们小型团队依然会做需求分析,只是占比太少,我们必须快速迭代,交出产品,让客户依据我们的做出的产品衡量他的需求。那么问题来了,在快速开发的过程中,如何保证软件质量呢,也就是所谓的测试,如何进展。

我在会上提出了自己这样的观点,从开发人员做起,而不是从需求分析处找问题,更不是留到测试人员找问题。怎么从开发人员做起,那就是增强开发人员的自测能力,使开发人员的效率最大化。在小型团队中,开发人员才是团队的核心竞争力,开发人员必须具有强大的自我驱动力,并且要海纳百川,需要做的不是照着可能已经存在问题的需求分析书敲代码,也不是自我感觉良好不进行代码的自我review,更不是极不情愿的不去做代码测试、集成测试。然而我这样的观点在会上受到了严重的歧视或者反对,有如下观点:

  1. 你所处的产品环境和我们组有着巨大的差别,你所处的环境中,你们组每个人对自己的模块很清楚,而我们组每个人对彼此的模块不清楚;你们组的代码量加起来不及我们组的十分之一,你所能看到的问题不能和我们组相提并论。
  2. 我们开发人员无法做太多的测试,因为在我测试的时候,可能数据库表结构都不存在了,其他人压根不会告诉我,你让我怎么测试,我只能留到测试人员发现。
  3. 由于需求经过多次传递,需求在开发人员处已经不再明确,开发人员必须按照自己的理解去做出结果,开发人员没有责任,需求分析也没有责任。
  4. 测试人员其他工作过多,导致不能把所有的时间用来做测试。

而所总结出来的解决方案是,开发人员自测虽然是个好观点,但是可实施性不大,减少测试人员的其他工作,专心做测试,如果一个人员不够增加人员。

对于以上观点和理由,我不做过多评价,我想是我自己鼠目寸光,见识短浅,没有去体会别组的难处。也许在他们眼里,我们组的情况是这样的“项目复杂度远远不够,人少问题就少,并且每个人都懂得其他人的模块”。

我很失望,我失望的不是自己的观点得不到认同,而是我们项目组的很多成员无法意识到自己的问题,这样久而久只会积劳成疾。我不是说自己有多优秀,我自己从前也厌恶做测试,测试不就是测试人员的专利嘛,我干嘛要自己测试,况且很多人开发的模块我也不清楚,我干嘛去了解其他人的开发内容,况且那么复杂,我根本了解不到,况且很多问题都是需求上出现了问题,又不是我自己的责任。

在现实中,是这样的。就我自己而言,我接到我目前的项目马上就有一年的时间了,在这期间,领导给予了我很大帮助,我的同仁们也给予了我很大帮助,时至今日,基本上能够把控整个期货交易平台的开发以及质量。我们组从一开始就没有需求分析师,更没有所谓测试人员,如何能做到问题越来越少呢,我想这多半和自己的些许努力是分不开的。我刚接手项目时,项目虽然已经上线运行,但是存在问题我都不敢回首。期间两个原来开发的核心成员都早早的离职了,我必须承担很多角色,以前别人说,我们小组人员少,所以在敏捷开发中的角色定位也就不存在任何问题,一人身兼多职理所当然。我要做需求分析,和客户讨论,自己琢磨方案,自己参与调查,参与架构,参与大量的开发工作,尤其是还有大量的测试工作,然后还有不停的修改bug,我曾经很痛苦为什么我要帮别人擦屁股,为什么我的成员对自己的代码如此不负责任,几乎都是一遍开发,能够自测是我不能太多奢求的。那么这就要求我,要做好自测,同时做好其他人的测试,当然我自己开发的也曾在上线后出现低级的问题,这也更加锻炼了我的自测能力。

我认为,小型团队,如何调度开发人员的效率最大化,才是公司发展的最强生命力。很多时候,很多成员抱怨自己时间多么紧迫,任务多么积压,但是我所看到的现象是,大多数时间成员无所事事,也许如果我们组一开始也有一个测试人员,那么我也会形成一种他人测试的依赖症。虽然我不能说我们小组的测试有多么好,成员的自测能力有多强,我只是想让团队推广“自测”、“自我驱动力”的意识,然而这种观点并没有多少人认可。

总结:说了上面这么多废话,有些话也不知道自己应该说不应该,把这些事情记录下来,不是抱怨团队,而是为自己立下警钟,无论以后身处何地,必须高举“自测”、“自我驱动力”的旗帜,而不是抱怨需求分析没做好,然后把问题留给测试人员,更不是归咎于项目的难度而去规避开发人员的责任。

时间: 2024-10-23 06:58:39

小型团队的测试该何去何从的相关文章

关于全功能团队及测试人员的发展

这两天部门内部在讨论全功能团队的相关东西,希望后续能慢慢的实施起来.这里全功能团队的概念,简单来说就是希望能够减少团队的规模,加快产品交付的节奏,类似于敏捷开发模式中的小步快跑,能够频繁的有版本上线运行.总体方向来说是好的,这套东西很多互联网公司也玩的很顺畅,但是在华为,最起码在我所在的部门内,还非常缺乏这方面的积累和氛围.整个研发的运作模式和管理层都是从传统的运营商转型过来的,团队庞大,低效,笨重...等等一系列的缺点. 关于这种团队模式的优缺点,如何根据自身的项目实际来运作,以及在这种模式下

敏捷团队中测试人员的角色

Karen Greaves和Sam Laing将会在Agile Testing Days 2015上发表主旨演讲,演讲题目为"测试人员正在消亡",Agile Testing Days 2015将于11月9日至12日德国Potsdam举行.小编将会覆盖本次会议报道. 小编对二人进行了采访,关于敏捷是如何影响测试人员角色的,为了缩短测试交付周期,测试人员可以采取哪些措施,敏捷团队中测试人员与其他团队成员之间的协作,敏捷团队中测试人员可以贡献的价值. 小编:我的经验是,敏捷更广泛的普及率正在

iOS团队开发者测试

那么你需要在你下载证书的那个电脑上从钥匙串-->选择证书-->右键到处证书,保存为.p12的证书,以后这个证书拷贝到任何电脑上去都是可以使用的! 本来只有一台电脑可以测试, 现在要团队开发测试 1.导出这台有证书的电脑上的 开发证书, 开发证书密钥, 发布证书为.p12证书, 通过U盘或者qq发送到另一个电脑, 双击安装即可 2.一次类推, 发送开发provisioning以及发布provisioning到另一个电脑, 双击安装即可 结束

Mock测试,何去何从

2016-10-24   出处:Qtest之道  作/译者:闫耀珍 上面的情景是不是似曾相识呢?现今的业务系统已经很少是孤立存在的了,尤其对于一个大公司而言,各个部门之间的配合非常密切,我们或多或少都需要使用兄弟团队或是其他公司提供的接口服务,当然,我们也会给其他兄弟部门提供接口.这样的话,就对我们的联调和测试造成了很大的麻烦.假如各个兄弟部门的步伐完全一致,那么问题就会少很多,但愿望是美好的,现实是残酷的,要做到步伐一致基本是不可能的.所以,对于这种情况,我们的解决方案通常是搭建一个临时的mo

人月神话札记之人月神话

前言:美食的烹饪需要时间,那么稍等片刻,你将享用更多的美味.缺乏合理的进度安排是造成项目滞后的重要原因,因素有以下内容: - 对估算技术缺乏有效的研究 - 进度和工作量混淆,就是说人员和时间可以转换 - 对自己的估算缺乏信心 - 缺乏信心 - 对进度缺少跟踪和监督,所以站立会和燃尽图至关重要 - 意识到进度偏移时,第一个反应是增加人力,而这时大多数情况如同火上浇油,火越来越大,需要的汽油却越来越多 乐观主义 书中说,编程人员都是乐观主义者,我想,在国内,需求者比编程人员更"乐观",他们

测试团队成功适应敏捷的障碍

测试团队在从传统开发模式向敏捷模式转变的过程中存在各种障碍,敏捷测试专家Lisa和Janet从自身经验出发探讨了其中的原因和解决方法. 任何变化都面临成功路上的障碍.组织文化可能是要克服的最大障碍.组织文化一旦建立就很难改变.组织文化的形成需要时间,一旦就绪,员工会忠于该文化,这使得对改变相当的抵制. 丧失身份 由于很多原因,测试人员坚持独立的质量保证团队,但是主要原因是害怕,特别是: 害怕丧失质量保证人员的身份    害怕如果向开发经理汇报,会丧失支持,程序员会获得优先权    害怕缺乏在敏捷

使用 RUP 管理小型项目和团队

David Kohrell 在2005年2月的 Rational Edge 期刊上指出,Rational Unified Process,? 或者称 RUP,?为项目的推进提供了一个灵活的过程 -- 从先启阶段,经过细化阶段.构建阶段,以及产品化阶段 -- 给予指导和说明.本文特别关注RUP如何同样能为小项目和团队提供指导.另外,在用于敏捷开发环境的能力方面,我们也观察了RUP和其它指导(比如,项目管理协会的项目管理知识体系,或PMBOK?). 小型项目和团队的背景 通常看来,如果被安排来管理一

测试人员在敏捷团队中扮演的角色

对于开发模式,现在大部分互联网公司都完成了从传统瀑布开发模式到敏捷开发模式的转型,这种转型相对传统的测试人员来说,不论是在角色定位还是在技能栈方面都提出了更大的挑战,那么测试人员应该如何应对呢?下面根据我平时工作的一些总结体会来说说测试人员应该发力的方向,供大家参考: 角色 1: 培训人员 在转型初期,测试人员应该针对开发人员的薄弱环节(即业务技能)进行培训和指导.由于工作任务的差别,开发人员对负责的模块业务和具体实现细节非常了解,但是对周边模块或者业务并不是非常清楚,主要体现在配置和使用方面.

测试人员在团队中的定位

前言 接触了许多非测试和新入行的测试从业者,听到最多的问题就是:“测试是否被需要?“ 团队职能介绍 <暗黑者1>中有句台词,“专案组有五个职能角色构成,侦探.网警.痕迹侦查专家.法医还有心理学专家”. 软件项目开发也是个分工明确的系统工程,不同的人员扮演了不同的角色,可以分为:项目.产品.开发.测试.美工等等. 项目经理负责分配资源,确定优先级,协调与客户和用户之间的交往. 产品经理负责市场调查并根据产品.市场及用户等的需求,确定产品功能的定义.规划和设计. 开发包括开发经理.前端开发.后端开