谁都是自己问题的答案

敏捷开发中，测试人员的工作成绩如何体现？

上一篇 / 下一篇  2010-03-16 18:21:04 / 个人分类：论坛活动

查看( 929 ) / 评论( 33 )

敏捷开发中，测试人员的工作成绩如何体现？

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

参与讨论：http://bbs.51testing.com/thread-185419-1-1.html


论坛模式 推荐 收藏 分享给好友 管理

TAG:

Nothing dsy851009 发布于2010-03-16 15:18:23
敏捷思想特别重视测试和开发的结合，换一句话就是没有所谓的开发也没有所谓的测试，迭代的每个环节大家都一起完成的，所以对于工作成绩如何体现，那就是整个版本质量高了是测试和开发的共同胜利，不能把测试和开发的绩效分开。
只是个人感觉，欢迎大家继续发表自己的看法。
关注此贴。
z554308576的个人空间 z554308576 发布于2010-03-17 13:06:52
我现在负责的项目也都是敏捷开发，一二周就要项目升级。用例啊什么的都来不急写，只能靠沟通了。最快的了解项目的需求，不过这种测试真的很累，大家都不知道要作成什么样。测试一个环节就要和产品经理、开发讨论半天
fuzengbin的个人空间 fuzengbin 发布于2010-03-18 09:34:09
楼主多贴点敏捷开发的知识吧，我们也准备尝试敏捷开发，需要深入了解啊！
魔女宅 默默巫 发布于2010-03-18 09:40:01

QUOTE:

原帖由 fuzengbin 于 2010-3-18 09:34 发表
楼主多贴点敏捷开发的知识吧，我们也准备尝试敏捷开发，需要深入了解啊！
你好，已加上相关文章。
水滴石穿的个人空间 水滴石穿 发布于2010-03-18 13:29:16
个人决定敏捷中的团队无论开发还是测试都应示为一个团体，不应分开绩效，最后产品的好坏以及客户的认可度才是整个团队的成绩体现，我所在的项目中是有监督人员(既不是开发员也不是测试员)来督查每个角色的工作情况，当然这名监督员也会做一些平台支持或参考其他团队的敏捷而给出建议，使整个项目有序和有规划的进行。其中每个角色的贡献度的最好证明就是每天得会议记录，每个人每天干什么了。
老A archonwang 发布于2010-03-18 13:51:05
好久没来了，先冒个泡~~

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

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

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

[ 本帖最后由 archonwang 于 2010-3-18 13:55 编辑 ]
nofish的个人空间 nofish 发布于2010-03-18 15:56:18
关键是开发、测试都是多个项目一起在做的。很多事情只是靠沟通，总会有遗忘，况且客户需求也是一直不停的变，如果没有文档规范下来，时间进度根本保证不下来，监控也缺乏依据，扯皮的事也会越来越多。
wpyily发布于2010-03-19 13:35:34
敏捷开发中，测试与开发是相互迭代进行的，需求文档不断变化，这也要求测试与开发之间的交流非常频繁。我在工作中发现，开发有时候会和PM进行需求上面的变动的沟通，而此时测试却并不在场，这也导致了开发把功能做好以后，测试觉得这个是问题，和开发交流后才知道，是需求发生了改变。文档每时每刻都在变化，测试问的太多，开发会越来越不耐烦。而且由于需求的不断变化，测试包的版本也很频繁，导致测试工作负荷过重。这些都是现实的问题
kingdom_seu发布于2010-03-19 13:38:16
项目过程中，是很难衡量一个人员的工作成绩的。如果必须衡量的话，那就需要记录该成员在项目开发中，提出了多少观点，最终多少观点得到项目组的认可，并反映的开发代码中。
此外，这个项目的最终成败，才是最终衡量整个项目组的标准。
狼窝 8596991 发布于2010-03-22 10:14:52
不知道这个工作成绩，你是向谁汇报？是向自己汇报还是向领导或者是整个项目组？
如果是向自己汇报，那这个问题就很容易解决了，在敏捷开发过程中，你发现了自己的价值，学到了更多的东西，充实了自己；并且利用自己的所学，专心的投入到了整个产品，最终的产品让大家都满意，我认为你已经向自己交了个最满意的答卷。
如果是向领导汇报或整个项目组汇报，这个也应该具体情况具体分析。
第一种情况：这个公司具有很好的管理流程，业绩考核制度成熟，那这个问题你不应该考虑太多，你的每一次贡献，都会历历在目的记载入库，你的工作成绩自然会有公论
第二种情况：公司的管理流程比较混乱，对测试没有实质的考核制度。这种情况可以在项目立项中，提出自己的疑问，大家可以一起想办法至少测试部门应该有考虑这种问题的解决方案。然后将方案提交整个项目组审核，达到体现工作成绩的目的
第三种情况：大家都在摸索阶段，这种情况下，制度当然也在摸索，你想比较实际的去体现自己的工作成绩，那不太可能，但请相信，技术骗不了人。东西好坏在大家心中有公论的
如果把问题确定在钱的多少上，试问一个普通的项目测试人员，到你手上的能有多少？又何必为了几百元去斤斤计较？我想你在整个项目过程中，你学到的经验以及知识，往往比这个更重要。如果你是项目经理，OK，项目奖的发放，公司肯定有标准的，就按照标准走吧。
changyi_lfx发布于2010-03-23 08:46:08
下面引用朱少民老师的文章来回答这个问题：
敏捷方法在软件开发中受到青睐，特别是在互联网应用服务系统的开发中，越来越多的公司采用敏捷方法，包括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的个人空间 msnshow 发布于2010-03-23 13:41:33
难题，关注中！
敏捷精灵 caoyuanxuelang 发布于2010-03-24 12:48:18
上次发帖失败，这次试一下。
chengning的个人空间 chengning 发布于2010-03-24 13:08:46

woodling发布于2010-03-24 17:13:39
恩，受益！我们公司现在就正在用敏捷模式开发，我这个测试人员还真有点压力
开始走 angle-ying 发布于2010-03-24 19:13:20
公司没有进行敏捷测试 ，看了楼上所有的帖子，对该贴比较关注。
本人理解：测试中的价值在与产品的各种性能，以及楼上所说的客户认可度，相信决定做敏捷测试的leader们都会考虑这个问题的 ，呵呵本人进入测试行业还未有一年 所以观点比较薄弱  
继续关注中
hery614的个人空间 hery614 发布于2010-03-25 11:30:51
我觉得这个问题确实是很难分开的，我公司就是一个项目进行敏捷开发完，测试与开发是同等地位的，但是具体还是要看经理的裁决了。
老A archonwang 发布于2010-03-25 15:02:33
回复 8# 的帖子
回答这个问题，需要注意敏捷开发适用的范围，其次要注意敏捷开发的一些必要条件

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

[ 本帖最后由 archonwang 于 2010-3-25 15:03 编辑 ]
Facet个人空间 weifei1031 发布于2010-03-25 16:10:27
测试的工作量和质量应该是可以度量的，不像产品,PD ，很多时候无法评估。其实我觉得不管你是用敏捷测试也好，不用也罢，你承担的模块或者说产品线，客户也会给我们反馈，我觉得客户的意见才是最重要的。非常赞成 12#的‘敏捷功能测试 = 新特性的手工测试 (use case验证和探索性测试)  + 原有功能的自动化测试 (回归测试)’这句话！
小鱼oO的个人空间 小鱼oO 发布于2010-03-27 20:41:49
我们部门就是敏捷开发，说说我们的做法吧，也不知道我们公司的做法是否正确，反正也是在尝试阶段。测试人员在项目中除了充当单纯的tester角色外，通常还有其他角色，例如business analysis,负责和客户沟通，了解需求，进行需求分析并把需求传达给开发人员。尽可能避免由需求理解错误造成的缺陷。在正式测试开始之前，测试人员和开发人员一起整理一份缺陷预防表，列出一些需求，技术等可能出现的问题，每天都学习一遍。开发的过程中，测试人员经常坐在开发人员旁边，给开发人员将需求，讲最后出来的效果应该是什么样的及可能有哪些中情形，算是结对编程吧。每个sprint结束前测试人员再对系统进行一轮测试，和一般的测试没什么区别。说到绩效，我感觉很难用什么客观指标来衡量。只要客户对最终产品满意，开发人员对测试人员的工作予以肯定就算有成绩。另外对于敏捷团队来说，预防大于测试，测试人员能帮助开发人员做好缺陷预防是很重要的。

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

(可选)

Open Toolbar