51Testing软件测试论坛

标题: 敏捷开发中，测试人员的工作成绩如何体现？（2010-3-16）（获奖名单已公布） [打印本页]

作者: 默默巫 时间: 2010-3-16 09:10
标题: 敏捷开发中，测试人员的工作成绩如何体现？（2010-3-16）（获奖名单已公布）
敏捷开发中，测试人员的工作成绩如何体现？

来HW一段时间了，所在项目是其一个全新重点项目，由于采用敏捷模式开发，包括PM在内大家都是在摸索中进行的。撇开CMM改用敏捷，文档不再全面了，连缺陷库都改用轻量级的了，领导们说敏捷中测试做的好不好不是看找到多少BUG，而是看转测试时有没有BUG，要在开发交流中解决全部问题。三轮迭代下来，交流占据了大多数时间，感觉工作做好很多，但却不知道如何体现，这个真是问题，希望大家给点建议。

此话题由会员菜也快乐着提供，如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

获奖名单
奖项	获奖名单	奖励	答案链接
二等奖	changyi_lfx	300论坛积分	12#

作者: dsy851009 时间: 2010-3-16 15:18
敏捷思想特别重视测试和开发的结合，换一句话就是没有所谓的开发也没有所谓的测试，迭代的每个环节大家都一起完成的，所以对于工作成绩如何体现，那就是整个版本质量高了是测试和开发的共同胜利，不能把测试和开发的绩效分开。
只是个人感觉，欢迎大家继续发表自己的看法。
关注此贴。

作者: z554308576 时间: 2010-3-17 13:06
我现在负责的项目也都是敏捷开发，一二周就要项目升级。用例啊什么的都来不急写，只能靠沟通了。最快的了解项目的需求，不过这种测试真的很累，大家都不知道要作成什么样。测试一个环节就要和产品经理、开发讨论半天

作者: fuzengbin 时间: 2010-3-18 09:34
楼主多贴点敏捷开发的知识吧，我们也准备尝试敏捷开发，需要深入了解啊！

作者: 默默巫 时间: 2010-3-18 09:40

原帖由 fuzengbin 于 2010-3-18 09:34 发表
楼主多贴点敏捷开发的知识吧，我们也准备尝试敏捷开发，需要深入了解啊！

你好，已加上相关文章。

作者: 水滴石穿 时间: 2010-3-18 13:29
个人决定敏捷中的团队无论开发还是测试都应示为一个团体，不应分开绩效，最后产品的好坏以及客户的认可度才是整个团队的成绩体现，我所在的项目中是有监督人员(既不是开发员也不是测试员)来督查每个角色的工作情况，当然这名监督员也会做一些平台支持或参考其他团队的敏捷而给出建议，使整个项目有序和有规划的进行。其中每个角色的贡献度的最好证明就是每天得会议记录，每个人每天干什么了。

作者: archonwang 时间: 2010-3-18 13:51
好久没来了，先冒个泡~~

关于敏捷测试的一些论题，参考如下。

http://subject.csdn.net/agile-testing.htm

实际上，参考下敏捷测试的最佳实现也许可以得到些启示。
http://www.ibm.com/developerwork ... n-agiletestexplain/

[ 本帖最后由 archonwang 于 2010-3-18 13:55 编辑 ]

作者: nofish 时间: 2010-3-18 15:56
关键是开发、测试都是多个项目一起在做的。很多事情只是靠沟通，总会有遗忘，况且客户需求也是一直不停的变，如果没有文档规范下来，时间进度根本保证不下来，监控也缺乏依据，扯皮的事也会越来越多。

作者: wpyily 时间: 2010-3-19 13:35
敏捷开发中，测试与开发是相互迭代进行的，需求文档不断变化，这也要求测试与开发之间的交流非常频繁。我在工作中发现，开发有时候会和PM进行需求上面的变动的沟通，而此时测试却并不在场，这也导致了开发把功能做好以后，测试觉得这个是问题，和开发交流后才知道，是需求发生了改变。文档每时每刻都在变化，测试问的太多，开发会越来越不耐烦。而且由于需求的不断变化，测试包的版本也很频繁，导致测试工作负荷过重。这些都是现实的问题

作者: kingdom_seu 时间: 2010-3-19 13:38
项目过程中，是很难衡量一个人员的工作成绩的。如果必须衡量的话，那就需要记录该成员在项目开发中，提出了多少观点，最终多少观点得到项目组的认可，并反映的开发代码中。
此外，这个项目的最终成败，才是最终衡量整个项目组的标准。

作者: 8596991 时间: 2010-3-22 10:14
不知道这个工作成绩，你是向谁汇报？是向自己汇报还是向领导或者是整个项目组？
如果是向自己汇报，那这个问题就很容易解决了，在敏捷开发过程中，你发现了自己的价值，学到了更多的东西，充实了自己；并且利用自己的所学，专心的投入到了整个产品，最终的产品让大家都满意，我认为你已经向自己交了个最满意的答卷。
如果是向领导汇报或整个项目组汇报，这个也应该具体情况具体分析。
第一种情况：这个公司具有很好的管理流程，业绩考核制度成熟，那这个问题你不应该考虑太多，你的每一次贡献，都会历历在目的记载入库，你的工作成绩自然会有公论
第二种情况：公司的管理流程比较混乱，对测试没有实质的考核制度。这种情况可以在项目立项中，提出自己的疑问，大家可以一起想办法至少测试部门应该有考虑这种问题的解决方案。然后将方案提交整个项目组审核，达到体现工作成绩的目的
第三种情况：大家都在摸索阶段，这种情况下，制度当然也在摸索，你想比较实际的去体现自己的工作成绩，那不太可能，但请相信，技术骗不了人。东西好坏在大家心中有公论的
如果把问题确定在钱的多少上，试问一个普通的项目测试人员，到你手上的能有多少？又何必为了几百元去斤斤计较？我想你在整个项目过程中，你学到的经验以及知识，往往比这个更重要。如果你是项目经理，OK，项目奖的发放，公司肯定有标准的，就按照标准走吧。

作者: changyi_lfx 时间: 2010-3-23 08:46
下面引用朱少民老师的文章来回答这个问题：
敏捷方法在软件开发中受到青睐，特别是在互联网应用服务系统的开发中，越来越多的公司采用敏捷方法，包括XP、Scrum、Lean、Crystal、FDD等。具体的敏捷方法在操作时有一些区别，但基本思想是一致的，如客户至上、拥抱变化、缩短迭代周期、自我组织等。在敏捷方法中，流程相对灵活，强调沟通，通过充分的沟通来及时解决问题，由于沟通充分，文档不是很重要，而且有可能不采用Word等独立的文件格式，而是采用Wiki、空间等web内容方式。在敏捷方法中，需求变化比较快、产品开发周期很短（一、两周），给软件测试带来很大的挑战！例如，功能测试的自动化实现就比较困难，没有足够时间开发自动化测试脚本，要花大量时间讨论产品特性，及时进行产品的验收测试。自动化测试，更多的是在单元测试这个层次上实现。而单元测试自动化、持续集成等一些关键实践，开发人员能发挥更大的作用，而测试人员难以很好地发挥作用。在敏捷方法中，开发人员的主导作用更明显，讨论需求、实现需求，再修改需求、再实现、再重构，不断完善产品，测试人员容易边缘化。甚至在Crystal方法中，可以不需要测试人员，开发人员能承担所有技术性的工作。
在敏捷方法中，测试人员的价值又如何体现？

1、首先在需求讨论上，测试人员可以站在客户角度上来阐述自己的观点，和产品人员、开发人员等进行充分的交流和讨论，使自己在用户体验、业务逻辑等等方面的经验充分体现出来。

2、在开发过程中，测试人员不仅扮演“用户代表”角色，而且可以及时提供更全面的质量反馈，包括代码质量、接口一致性等。测试人员不写代码，可以参与代码复审（code review），将质量问题及时提交给项目组，保证在产品构造的整个过程中质量受到足够的关注，提高质量改进的持续性和可视性。

3、测试人员还是可以参与单元测试。即使单元测试由开发人员做，测试人员可以推进开发人员进行单元测，检查单元测试状态，如确保单元测试达到80%以上覆盖率，以及帮助开发人员开发出具有良好可测试性的代码。

4、即使在敏捷方法中，集成测试、端到端（end-to-end）测试、性能测试等是不可少的。因为在敏捷方法中，往往将一个大的系统开发分解成多个小的子系统（模块/组件），集成测试和端到端（end-to-end）测试显得更重要。测试人员在功能测试上工作量会降低，但在这些测试上发挥更大的作用。

5、随着迭代的不断深入，回归测试的工作量很大，这也是测试人员的用武之地。测试人员可以针对稳定的产品特性开发自动化测试脚本，这也是一种持续的努力，使回归测试自动化。测试人员对缺陷进行分析，总结出一些规律，帮助开发人员建立良好的习惯，改进代码的质量。

而且：
在敏捷方法中，我们也要采用敏捷测试，不要再写几十页的测试计划书，而是在每个迭代周期，写出一页纸的测试计划，将测试要点列出来。
在敏捷测试中，可能不需要测试用例，而是针对use case 或user story直接进行验证，并进行探索性测试。而节约出来的时间，用于开发原有功能的自动化测试脚本，为回归测试服务。自动化测试脚本将代替测试用例，成为软件组织的财富。
所以：
敏捷功能测试 = 新特性的手工测试 (use case验证和探索性测试) + 原有功能的自动化测试 (回归测试)
理想情况下，测试人员具有很好的编程能力，可以和开发人员进行角色互换。在当前版本开发（/迭代周期）中担任测试人员角色，在下一个版本开发（/迭代周期）中担任开发人员角色，而开发人员则担任测试人员角色，让开发人员深刻地理解用户的需求角度来考虑系统功能的设计，这样会更好地保证产品的质量，沟通的障碍也会消除，开发的效率会有很大的提高。这也是对测试人员的一个挑战。
敏捷测试也是一个持续测试的过程，而这持续测试的基础是具备一个灵活的、开放的自动化测试框架。项目采用敏捷方法，要获得成功，项目组中每个人都有很强的质量意识，具有质量的主人翁精神，特别是开发人员，每时每刻提醒自己——“质量是构建出来的”，与客户或产品设计人员进行充分沟通，遵守高度一致的质量标准。

[ 本帖最后由 changyi_lfx 于 2010-3-23 08:52 编辑 ]

作者: msnshow 时间: 2010-3-23 13:41
难题，关注中！

作者: caoyuanxuelang 时间: 2010-3-24 12:48
上次发帖失败，这次试一下。

作者: chengning 时间: 2010-3-24 13:08

作者: woodling 时间: 2010-3-24 17:13
恩，受益！我们公司现在就正在用敏捷模式开发，我这个测试人员还真有点压力

作者: angle-ying 时间: 2010-3-24 19:13
公司没有进行敏捷测试，看了楼上所有的帖子，对该贴比较关注。
本人理解：测试中的价值在与产品的各种性能，以及楼上所说的客户认可度，相信决定做敏捷测试的leader们都会考虑这个问题的，呵呵本人进入测试行业还未有一年所以观点比较薄弱
继续关注中

作者: hery614 时间: 2010-3-25 11:30
我觉得这个问题确实是很难分开的，我公司就是一个项目进行敏捷开发完，测试与开发是同等地位的，但是具体还是要看经理的裁决了。

作者: archonwang 时间: 2010-3-25 15:02
标题: 回复 8# 的帖子
回答这个问题，需要注意敏捷开发适用的范围，其次要注意敏捷开发的一些必要条件

敏捷开发对团队的能力要求要高于一般的开发模式，具体要参考12#的解答，优秀的团队可以将敏捷开发的优势发挥得淋漓尽致，但是如果存在能力断层，不推荐使用这种开发模式。

[ 本帖最后由 archonwang 于 2010-3-25 15:03 编辑 ]

作者: weifei1031 时间: 2010-3-25 16:10
测试的工作量和质量应该是可以度量的，不像产品,PD ，很多时候无法评估。其实我觉得不管你是用敏捷测试也好，不用也罢，你承担的模块或者说产品线，客户也会给我们反馈，我觉得客户的意见才是最重要的。非常赞成 12#的‘敏捷功能测试 = 新特性的手工测试 (use case验证和探索性测试) + 原有功能的自动化测试 (回归测试)’这句话！

作者: 小鱼oO 时间: 2010-3-27 20:41
我们部门就是敏捷开发，说说我们的做法吧，也不知道我们公司的做法是否正确，反正也是在尝试阶段。测试人员在项目中除了充当单纯的tester角色外，通常还有其他角色，例如business analysis,负责和客户沟通，了解需求，进行需求分析并把需求传达给开发人员。尽可能避免由需求理解错误造成的缺陷。在正式测试开始之前，测试人员和开发人员一起整理一份缺陷预防表，列出一些需求，技术等可能出现的问题，每天都学习一遍。开发的过程中，测试人员经常坐在开发人员旁边，给开发人员将需求，讲最后出来的效果应该是什么样的及可能有哪些中情形，算是结对编程吧。每个sprint结束前测试人员再对系统进行一轮测试，和一般的测试没什么区别。说到绩效，我感觉很难用什么客观指标来衡量。只要客户对最终产品满意，开发人员对测试人员的工作予以肯定就算有成绩。另外对于敏捷团队来说，预防大于测试，测试人员能帮助开发人员做好缺陷预防是很重要的。

[ 本帖最后由小鱼oO 于 2010-3-29 12:48 编辑 ]

作者: lsp335 时间: 2010-4-1 14:10
看到敏捷，忍不住说两句。现在这个词越来越热了，工作中用到的也是越来越多。
个人理解敏捷的精髓在于拥抱变化并快速响应，在这样的一个大前提下，测试人员在完成保证项目质量的使命时，无疑比在传统项目中会受到更大的挑战。
提出几点意见，供参考：
1. 在这样一个需求不断变化拥抱变化的团队中，及时获取到最新的需求无疑是一切工作有效开展的前提，作为测试人员，这点尤为重要；
2. 在变化中掌握中找出并把握住核心的功能，对有效的进行测试活动保证产品的整体质量至关重要；好钢要用在刀刃上。
3. 沟通是敏捷不变的主题，但敏捷不是为了沟通而沟通，是为了拥抱变化并快速响应，所以把握沟通的目的，掌握有效的沟通技巧，会使我们的工作事半功倍。
4. 沟通之后就是快速响应，take action的前提是做对的事情，如果系统需求已经变化为3.0版本，你还在根据2.0版本的需求做测试设计，这无疑做的是无效功。及时反馈自己任务的完成情况和遇到的问题，也是快速响应的一部分。
5. 前面几条是对如何有效展开测试工作的一点建议，测试人员的核心价值体现在其对项目质量的保证，除了在项目开发完成后测试系统提出缺陷，在项目前期的需求分析中，我们也可以从测试的角度提出需求中的缺陷；在设计阶段，提出容易出问题的场景供设计开发人员参考，将缺陷消灭在初始阶段；等等，这都是测试人员价值的体现。当然这些对测试人员的要求也就更高一些，但在这些阶段就发现并提出问题，的确是比在项目开发完成后再发现提交问题价值更高一些。

[ 本帖最后由 lsp335 于 2010-4-1 14:20 编辑 ]

作者: selow 时间: 2010-4-2 08:37
标题: 回复 1# 的帖子
管理是邪恶力量的粉丝啊。。中意CASS的气质。

作者: qtfy 时间: 2010-4-2 21:04
领导们说敏捷中测试做的好不好不是看找到多少BUG，而是看转测试时有没有BUG，
-------------------------------------
转测试后的用例和敏捷期间的用例肯定是不同的啊，只能看漏测问题。

作者: 菜也快乐着 时间: 2010-4-8 16:25
标题: 回复 12# 的帖子
你说的我们都知道，只是公司是要硬性可度量的数据，如何得来？

作者: 懵懂的女孩 时间: 2010-4-15 16:47
我们现在开发就是使用的敏捷迭代，现在的项目比较紧，工期短。
给我的感觉是，测试的压力比较大，尤其是在迭代快结束前的两三天。基本上迭代快结束的前一天，或在迭代结束的当天，开发才做完，很多时候测试都没有时间测试。
而在迭代开始第一周，主要都是在进行回归测试。没有具体的需求和设计。讨论需求和设计，也不让测试参加，很多问题在测试时发现了，最后又改需求和设计。

作者: chenyujoe 时间: 2011-1-30 12:25
目前正准备在敏捷迭代开发流程下建立相应的测试流程。
关注此贴。

作者: lvweijue2006 时间: 2011-2-15 14:42
参与敏捷开发的项目将近半年，工作开展不是很顺利，摸索着在测试中有些体会：
1.业务分析能力。良好的业务分析能力就能写出好的测试用例，好的测试用例是很有效保证质量的；针对时间太紧的项目来不及写测试用例，就要凭积累的业务经验去测试了，当PM问你怎样测试时就可以说出你的思路。
2.技术能力。个人各方面测试技术能力是否足够，这是你能否有敏捷开发中做好测试的保证。
3.缺陷流程。再敏捷开发的项目，缺陷流程也要有；这是别人看到测试成绩最直接的东西。
4.沟通有效性。面对需求变更频繁，测试、开发、需求，各方位人员沟通要及时，否则会导致多方都在做白用功。

作者: veroniquelu 时间: 2011-3-21 10:46
我们项目也正在敏捷的尝试阶段
一两个项目下来我个人觉得还有一些问题，也不知道如何解决，特来请教下各位大虾
1，测试标准不明确。由于是外包公司，很多测试，我们这边通过了，客户不通过，这点很难解决，因为本来需求就是模糊的。导致客户每一次验收的时候发现很多的“bug“，作为测试人员就比较遭殃。因为时间不多，要承受高强度的工作，工作几乎是要加班完成，测试人员容易疲劳，很难覆盖所有的测试，经常吃力不讨好。
2，测试介入时间太迟。目前这个项目就是典型的测试介入太迟，在发布前两天，突然宣布让我测试，于是我一上手又给他们提了好些问题，本来今天发布，但是我提的问题还没有解决。
3，测试范围不明确。这点可能跟客户的需求有关系，敏捷开发本来就是需求变更大，但是作为一个阶段应该要很明白很明确这个阶段结束后，这个项目要达到怎么样的效果。很多时候就是我们完成一个阶段，本来一个应该是可以结束，但是有很多enhancement的change又会发过来，于是，我们的发布日期一推再推。
4，时间利用率。敏感开发讲究的就是快，但是作为一个CMMI5的公司，有很多流程要follow。如果一个星期作为一个sprint的话，那光是写case至少两天吧？我目前的状况是，case能写就写，不能写以后就得补，严重出现拆东墙补西墙的现象，导致以后得项目也无法尽早地介入测试。
5，开发与测试的交流问题。这点我注意到了，由于客户不断变更的需求，开发会比较烦，特别是当测试提出一大堆问题的时候。

作者: mengpeng 时间: 2011-8-3 10:30
俺们现在也在做敏捷开发，业务说不清需求，开发不理解也不问需求，测试人员天天问业务人员的需求，开发问测试如何修改BUG。。。。领导去头脑风暴，开会的需求内容也不通知大家，开发天天在看新闻，拿到一张需求图片就开发，开发完了就让测试去测。。。。我参加这个项目几个月，没有开过一次沟通会。。。。

作者: liulinzhu 时间: 2011-9-13 17:54

个人决定敏捷中的团队无论开发还是测试都应示为一个团体，不应分开绩效，最后产品的好坏以及客户的认可度才 ...
水滴石穿发表于 2010-3-18 13:29

这个监督员我们可以称之为scrum master，即牧羊犬。

作者: liulinzhu 时间: 2011-9-13 17:58

关键是开发、测试都是多个项目一起在做的。很多事情只是靠沟通，总会有遗忘，况且客户需求也是一直不停的变 ...
nofish 发表于 2010-3-18 15:56

文档有没有和规范是两回事，有(拍照、纸质等都可以)可以解决扯皮，整理规范则可以放在项目后期来进行。

作者: liulinzhu 时间: 2011-9-13 18:02

敏捷开发中，测试与开发是相互迭代进行的，需求文档不断变化，这也要求测试与开发之间的交流非常频繁。我在 ...
wpyily 发表于 2010-3-19 13:35

原则上测试人员在需求阶段便要介入，因此讨论需求时必须有测试。由于种种原因(时间、地点等)无法做到，也要履行好事后告知的义务。这事情PM应该要牢记。

作者: daisucai520 时间: 2011-9-20 14:36
学习了

作者: heporen 时间: 2017-1-24 09:53
受教了，我们公司现在也搞敏捷开发。开发的地位越来越高，而测试由于水平未达到较高程度，且仍用传统功能测试+回归测试，造成测试时间耗太多，成果输出太少，在公司地位很低，自由工资也一直提不上，人员流失严重；

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)