开发人员与测试人员的那些事

关于开发人员和测试人员的关系,人们阐述了很多,讨论了很多,争论了很多。而貌似一旦这两者坐在一起,对峙便开始了,两者间的争论多于相互认同。显然,这不利于实现两者合作的目标——向用户提供价值。(推荐学习零基础学习软件测试基础篇

下面我们来分析一下其中的原因:

史前时期

在最开始,不存在测试人员, 只有开发人员。软件开发人员和软件项目的其他人员比起来并没有特别大的不同。从经济角度考虑,专门成立测试人员是行不通的:开发软件的时间如此昂贵,为测试人员分配时间显得很浪费。

没有专门人员检查工作,软件开发人员只好自己做测试。他们通过检查日志、打印信息以及离线“调试”来确保软件正常运行。 那时还没有可用于调试的IDE,可不能在查看成百上千页的打印数据上花费太多的时间。因此检查数据的人都是开发人员,这样大家使用彼此熟悉 的术语,对问题心知肚明。这样,尽管速度还不够快,但整个团队能够和谐地前进,。

开始分裂

随着软件行业的高速发展以及计算机成本的降低,软件公司在考虑成本的同时也开始关注软件质量。软件使用者开始变得挑剔,他们经常在初次使用时就不满意,要求软件公司修复或改善他们所购买的软件。

保证软件质量的方案之一就是验收测试:客户在软件系统上执行应用场景。这些场景就像是软件公司和客户之间的契约:软件系统只有通过这些场景测试才能够被客户接受。



最初,开发人员会自己执行验收测试,或者由客户执行验收测试,然后将问题反馈给开发人员。但软件公司很快就意识到开发人员不擅长于处理和客户的关系,于是隔离客户和开发团队的想法开始萌芽。

存 在的问题不仅仅是客户和开发人员之间的沟通。因为验收测试有时无法达到预期效果,人们越来越意识到应该对开发团队进行更加严格的质量监控。若由其他团队 的开发人员进行质量监控,则会导致软件成本增加;而进行质量监控不需要理解错综复杂的软件是如何工作的,因此软件测试人员这个职业便产生了。

当然,这种组织结构的变化并不是自然而然产生的,组织结构变化需要管理上的支撑和协调。所以经过几年的发展,软件项目中开发人员和测试人员两种角色的界限还是不清晰,

随 着软件测试领域的发展,越来越多的测试人员需要提升自身的技能,于是开始产生了相关的方法论和培训需求。培训和认证机构看到了这个市场机会,开始提供测 试人员以及开发人员培训服务。随着方法论的逐渐成熟,测试专家开始涌现。之后开发和测试领域都有各自的专家,开发人员和测试人员的界限清晰起来了。

双城记

开发人员和测试人员在思维和工作方式上截然不同。开发人员认为自己是创新家,他们从无到有创建出软件,却常常招测试人员指手画脚。另一方面,测试人员 苦苦 忍耐开发进度,而当终于从开发人员手里接过软件时却发现软件是个废物。质量始终难以过关,测试人员重复测试出主要应用场景的错误,花费了不少时间。由于时 间有限,很多应用程序没能完全通过测试。

开发人员认为测试人员就是敌人,因此可能会把软件发布抛在脑后,使出浑身解术避开测试人员。测试人员认为开发人员不够专业,产生了很多本可以避免的bug。软件团队中弥漫者诸多不信任。

软件公司中的这两个党派之间还存在另一个问题:软件需求以及测试场景的沟通问题。因为思维方式的差异和语言的歧义性,软件需求经过再次表述,接着再次被理解,结果和实际会有很大出入。而这些理解上的出入直到测试阶段才被发现,相互指责随之爆发。

开发人员说可以测了,测试人员便开始测试,开发人员接着进行新功能的开发以保持生产率。然而,当测试人员报告bug时开发人员的开发工作被扰乱了,开发人员开始抱怨测试人员见缝插针,指手画脚。

开发派和测试派之间的紧张局势显然不利于减少浪费和产生有价值的产品。两派之间的冲突导致了重复工作,相互指责,而软件产品难以有见光的一天。



敏捷之桥

敏捷实践一开始就以开发出能良好运转的软件作为目标。这是很重要的一步:敏捷宣言的倡导者来自软件行业的各个领域(开发人员、测试人员和管理人员),他们把业务价值放在第一位,任何事情都应以它为依托。

“完整团队”是其解决方案,这是试图将客户和开发团队捆绑在一起的极限编程实践。敏捷组织也有测试人员的概念。

因为开发人员与测试人员有了共同点并需要紧密协作,他们恢复了之前抗拒的行为:交流。

他们开始使用相同的术语交流需求是什么。语言障碍消除了,双方在应该怎样做和哪些事情还未解决上达成一致。

当开发人员和测试人员在同一迭代周期中协作时,他们发现了更好的情况:测试人员在流程早期捕获错误和决定怎么处理,这样对开发工作产生正面的推动,开 发人 员也从迭代中受益:在sprint中捕获和修正的bug都不算是真正的“bug”,只有逃脱出迭代周期的bug才会被当作真正的bug记录下来——开发人 员可不愿意成天被别人说自己开发的软件是有bug的。

改造

美好结局?

大多数公司还没有涉及真正的协同敏捷软件开发。开发人员和测试人员仍然被相互隔离,他们认为从业务角度考量这两种角色就应该被分开。

敏捷实践已经证实,通过流程以及协作可以打破开发人员和测试人员之间的隔阂。成功的敏捷实践必然包括开发团队和测试团队的融合。没有重新组织以使两者融合,是不可能获得成功的,或者用敏捷的术语:不可能获得良好运转的软件。可以登录e良师益友网学习编程语言教程集合

时间: 2024-12-14 17:57:56

开发人员与测试人员的那些事的相关文章

对于软件开发中开发人员与测试人员关系的理解

在软件开发中都会有开发人员(以下简称开发)和测试人员(以下简称测试),在一些小型公司可能并没有测试,仅仅是开发兼任测试.在这里我仅针对于有专业的测试和专业的开发的项目. 每个公司应该都有考核机制,对于开发和测试的考核实际上很难量化,通常来讲大的方向就是开发所负责模块的bug数,对于测试来讲就是测出来的bug数,但这真的有效吗?这也许对开发有约束力,理论上开发是能够自己控制bug数的,如果从产生的bug数来评判开发的绩效还算有效,这样开发自然就会把代码写得更加认真.但如果根据测试测出来的bug数来

SWTBOK测试实践系列(2) --你会把开发人员提交测试的版本打回去吗?

开发人员奋斗了很多个夜晚,终于把版本提交测试了.他们可以松一口气了.但是噩耗很快传来,软件没有通过测试团队的预测试(为了保证测试进程,对开发人员提交的代码进行基本功能或业务流程的验证).开发经理老王,迅速找到负责预测试的测试经理老张. 老王说:老张啊,怎么回事?出什么问题了?我们好不容易开发完成了,你们怎么不测试还把版本打回来了? 老张说:你们提交的版本质量太差,没有我们的预测试,需要重新修改后,符合我们的要求,我们才能测试.你看看我们发现的这两个问题. 老王并没有看这两个问题,而是直接质疑老张

测试人员和开发人员如何更高效的配合工作

一.对开发人员的建议: 控制版本/补丁发布频率(重要) a) 版本交付间隔保证在2个工作日以上,尽量避免出现版本/补丁频繁交付导致的测试不充分. b) 控制版本补丁数量,原则上除紧急补丁外,多个补丁合并发送.这样可以让测试人员对交付版本提供一个更准确的质量状况. 版本能按计划交付(重要) a) 根据青铜器上填写的版本交付计划或者约定的交付日期进行版本交付. 明确每个版本的送测内容(重要) a) 含故障单.缺陷编号.具体功能修改等,避免出现模糊描述:如修改了用户管理模块--应描述修改的具体内容.

“测试人员”与“开发人员”的视角差异

测试人员和开发人员的目标是相同的,即向利益相关者提供高质量的产品.但他们的思维方式不同. 正确的说法是,"测试人员和开发人员没有什么不同,但他们遵循不同的途径来实现相同的目标". 开发人员认为:"我怎样才能提出申请呢?" 测试人员认为:"我怎样才能破解这个申请呢?" 测试人员和开发人员的行为就像猫和和老鼠.但最终的结果只有当他们一起工作时才是积极的. 说"如何破坏应用程序"并不意味着测试人员的座右铭是破坏开发人员所做的工作.这

测试人员遇到不断变化的项目需求该如何应对?

需求频繁变更这个产生的主要原因是: 1.前期需求调研工作没有做到位,在需求调研时没有真正深入了解用户需要什么东西?用户做这个东西的目的是什么?为什么要这么做? 2.项目经理对项目掌控力度够,在项目的需求一定情况下,没有采用集中变更或者分阶段变更: 3.客户在最开始时自己也没搞清楚要做出什么样子?随着系统的成型上线,提出一些新想法等导致需求变更. 4.客户就是上帝,所以有些变更是必须的. 测试人员如何面对变更? 1. 协调制定变更规范,比如说每次需求人员都会发出变更邮件,这样可以作为开发人员和测试

转:什么样的测试人员是好的测试人员

1 工作积极主动 工作态度如何,是评价一个测试人员最主要的方面,一个高水平的测试人员(指纯技术能力)如果没有一个好的工作态度,在测试团队中有时候不但不能对测试工作起到推动作用,有时候还起到阻碍作用,而一个愿意工作的测试人员,哪怕他的技术水平不高,人也不聪明,但对自己的工作认真负责,你告诉他的事情,他都可以认真去做,这个测试人员也会对测试工作起到很大的促进作用.这也是为什么很多企业愿意让刚参加工作的人员做测试工作的一个主要原因.另外,测试人员对工作是否主动也会很影响一个测试人员的发展,举一个例子,

你问我答,及测试人员方向发展

大家好,我是TT,互联网测试行业多年,没有牛逼的背景,也没有什么可炫耀的,唯独比他人更努力,在职场打拼.遇到过的坑,走过的弯路,愿意与大家分享,分享自己的经验,少走弯路.首发于个人公众号[测试架构师] 原文如下: 做开发好还是测试好?如果做测试怎么入门? 既然还有人问这样的问题,我想应该还有部分人可能会有这样的疑问,我并不觉得这问题问的多么可笑,可能对于刚进入职场之前的我们也会有这样的疑问.我个人觉得,首先,应该去了解开发和测试需要做的事情,使用到的技能,在问这些问题之前有没有去主动的了解和学习

好的测试人员应该是什么样的?

1.工作积极主动 工作态度如何,是评价一个测试人员最主要的方面,一个高水平的测试人员(指纯技术能力)如果没有一个好的工作态度,在测试团队中有时候不但不能对测试工作起到推动作用,有时候还起到阻碍作用,而一个愿意工作的测试人员,哪怕他的技术水平不高,人也不聪明,但对自己的工作认真负责,你告诉他的事情,他都可以认真去做,这个测试人员也会对测试工作起到很大的促进作用.这也是为什么很多企业愿意让刚参加工作的人员做测试工作的一个主要原因.另外,测试人员对工作是否主动也会很影响一个测试人员的发展,举一个例子,

测试人员的核心能力与素质

声明:该文不是我的原创作品,是我的同事魏增艺的大作,独家授权我来进行发表. 在<测试人员的角色>一文的最后,我们相信优秀的测试人员是项目的前灯,是整个研发系统的反馈回路.那么什么是优秀的测试人员呢?具体说来,具备哪些核心能力与素质的测试人员才能胜任这样的角色呢? 对于能力模型,例如常见的"冰山"模型."洋葱圈"模型等,都将一个人行事的内在动机或价值观等置于核心位置.同样,对于一个测试人员,我们并非看他在进行什么活动,而是要关注他为什么要进行这些活动.本文