敏捷开发中，测试人员的工作成绩如何体现？（2010-3-16）（获奖名单已公布）

小鱼oO

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

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

lsp335

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

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

selow

管理是邪恶力量的粉丝啊。。中意CASS的气质。

qtfy

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

菜也快乐着

你说的我们都知道，只是公司是要硬性可度量的数据，如何得来？

懵懂的女孩

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

chenyujoe

目前正准备在敏捷迭代开发流程下建立相应的测试流程。
关注此贴。

lvweijue2006

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

veroniquelu

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

mengpeng

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

liulinzhu

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

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

liulinzhu

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

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

liulinzhu

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

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

daisucai520

学习了

heporen

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