一个优秀的测试如何在敏捷开发中体现自己的价值？(2012.12.3)(获奖名已公布)
一个优秀的测试如何在敏捷开发中体现自己的价值？如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！
http://bbs.51testing.com/attachments/month_0811/20081125_650d7dccd46be6244f27oXDjE0HoDhyX.gif
获奖名单
奖项获奖名单奖励答案链接
一等奖wheetle50元移动充值卡22#
我们到是在做敏捷，<10人的团队，自己写case。
要说价值，应该还是迅速的发现P1级的bug吧。
当然，在测试驱动开发的团队，如果测试人员能够掌握项目进度，则是最能体现自身价值的，但说句实话，项目经理自己都未必能把进度掌握好，对吧。
所以，该干嘛的把自己手中的活干好才是最重要的。 这个问题已经困扰我一段时间了，业务复杂，需求变化快，测试人员精疲力竭仍然保证不了项目质量，老是被开发牵着鼻子走。真想早点想到适用于我们的方法，摆脱这种现状。 在项目比较成熟的团队做过两年的敏捷开发测试，当时的价值就是跟着流程走，哪个流程需要测试人员参与就参与，并且做好每一步，保值质量，这就是价值。但现在换了公司，是一个项目不成熟的团队，也是敏捷，但流程少了很多，就一个测试人员，实在是不知道怎么规范它，怎么实现自己的价值！！我很迷茫！ ’敏捷测试中如何体现自己的价值‘这个话题其实挺大的。任何一种模式中，体现自己的价值都有很多种不同的方向，主要看自己的意愿，价值取向以及，客户的关注点和开发团队的关注点在哪里。
我说一点自己的经验吧。我有过差不多3年敏捷团队的一点些许经验。不对的地方，敬请提点。
敏捷团队里面，其实测试和开发人员的角色界限很模糊。没有什么一定是开发的工作什么一定是测试的工作。
需要完全摒弃测试团队和开发团队这种概念，得而代之的一个团队。
if，新项目
我们的团队一般是项目立项的时候全部进入，其实一共也不外乎三个人，一个人负责前端开发，一个人负责后端开发，而我负责测试和需求确认。最开始需要积极和客户以及开发的mgrs确认需求的背景，是否又可以借鉴的案例。然后开发进行 ’one page‘设置，然后做demo，然后测试的人负责去核对design是否有补充的地方。然后是团队一起和开发的mgr，还有客户的产品经理进行评估demo的效果，是否这就是客户需要的。如果是，那么ok，客户approve，开发进行细致开发，测试在中间准备若干测试需要的测试数据，获取和更新各种客户文档。开发一旦完成某个功能，UT通过，Diff测试通过，那么马上就开始进行测试。测试的过程依赖开发人员的能力和对业务的熟练程度，需要进行sanity或者细致的变更点check。直到所有的问题被解决，发布release给客户。
If 既存功能的修正
既存功能的修正或者变更，我们一般是按照release走，每一个release都会含有几十到上百个前端，server端的bug 修复case或者enhancement。涉及到的功能也是系统里面不同的功能。
需要做到的是最快的速度去了解需要你测试什么，变更了什么，变更之后的功能是什么样子的，变更的时候改动了哪些地方。这些信息一般客户不会给你，只能去看以前的功能描述或者问有经验的一直在这块负责的开发人员。在他们告诉的信息的基础上，自己再进行拓展。
把要求的功能都测试完成之后，基本的其他必须的测试类型都过了一遍之后，再根据自己对系统的了解，把相关的，相互排斥的地方都查一遍。没有什么问题就可以sign off了。
对于测试里面出现的各种缺陷，要及时沟通，可以根据自己的经验和业务知识，给出自己的判断和定位分析。【前提是你确实知道，否则不要贸然指导】，对于测试过程中的风险，比如delay的风险要进行及时的提醒和告知，并且一起研究怎么样做会避免交付延迟。对于不能及时修复的case，如何评估，确定它们会在何时被修复。然后在测试结束以后，做好测试审核，看看自己测试的重点是否有所遗漏，对于客户的需求，是否把握完全，开发的配合过程中，是否有过什么不愉快，什么方案可以提前一步入手来避免被动。。。
其实任何一种模式下，测试人员的价值都是贯穿的，无论是否在独立的测试团队下，无论是瀑布下，还是敏捷下。做好测试工作最重要的是，理解客户，知道自己的定位在哪里，然后配合好自己团队的兄弟，包括开发，设计需求。了解对方，市场沟通然后信息反馈，慢慢的把质量和产品的概念渗透进去。
自己有能力，自己做出了有价值的事情，自己才有被肯定的意义。 以敏捷开发相对于的模式是探索性测试，充分发挥测试人员的主动性，积极地应对敏捷模式下的各种快速交流与变更，并且对各种变更做出及时的响应。
而目前大多数公司引用的模式往往是在保留了CMMI流程的基础上引入敏捷开发的模式，这种混搭的模式其实是一种过渡模式，完全正常，但问题在于测试环节如何更有效地适应这种混合的开发模式，使之充分发挥自身价值和在团队中的话语权。
个人认为同开发的结构一样，测试也应该采用混合的测试模式，在保留原有的测试基础上，适当弱化部分的环境，引入探索测试的理念。让测试人员更加主动地去理解需求、用例等，在更短的项目周期中发挥最大的价值。事实证明，在完全不变的模式下应对敏捷开发，测试人员往往疲于奔命，却无法达到保证产品质量的一定高度。 在工作中能够将各种测试工具运筹于帷幄之中，从各方面发现缺陷，能够自己编写一些测试工具，与公司的人都其乐融融。 理论上怎么说都好听，实际工作中总会遇到各种各样的意外情况。
至于体现自己的价值，我觉得还是做好自己的本职工作才是最重要的吧。。。
每个员工对公司的贡献是不一样的。 不同的公司在对测试工作的定义也是不一样的，真的很难一概而论。只有工作中积极主动，多思考，多探索，更要能融入所在的团队才是最重要的。 我们才开始做敏捷：
敏捷开发中测试最有价值的是测试驱动开发，自己写测试代码，尽快适应项目自动化框架，确保每次迭代顺利进行，但是做性能的在敏捷中地位感觉不明确，就只有在集成测试的时候完全投入，而且最后时间也不多了。有时候匆忙测试，老大们给压力？
但是我还是觉得不管什么模式：测试还是要精通业务和开发测试流程，在提升技术才是王道 敏捷开发中测试如何体现价值,就看测试能不能起到一个"车头灯"的作用,把握住项目的方向. 从参与需求讨论开始就要进入测试角色,提出需求中的问题. 开发完成代码模块后,完成单元测试,接口测试.然后做持续集成测试.敏捷开发对测试人员提出了更高的要求. 要做到敏捷,就必须做到自动化.解决"滚雪球"式的越来越大量的回归测试. 我认为，敏捷测试无法单独的执行，必须在敏捷的环境下，结合开发人员方面的敏捷实践以及组织结构齐头并进方可实现。而此时，质量的提升乃是源于软件开发工作整体的改善，很难说一定是测试的功劳。另一方面则在于，测试本来就无法“控制”质量，自然也无法改善质量，因为测试工作本身并不改变那些可以影响质量产生的因素。但敏捷测试的实践对于质量的提升是肯定有影响的。
敏捷中对于团队内外参与、交流的追求，能够更容易“do things right”
快速地交付和反馈，有助于做到更多地“do right things”
完整团队、跨职能团队等实践，团队负责自己的工作方式改进，更容易做到“do things rightly” 陆老师没有给我们班上敏捷测试课，有点小遗憾呀！现在对敏捷测试只是了解一丁点，还是当初做项目时他简单提了一下敏捷测试。不只知道当时为什么我们班没有开，比我们高一期和低一期都有敏捷测试。
支持陆老师的敏捷测试!!! 敏捷测试待学习中。。。 个人认为在测试中体现最大的价值就是在于你对版本质量的掌控有多少来决定。因为BUG是无穷的，这个时候把版本的问题控制在一个可掌控的范围内，就是测试体现价值的优势所在。 嗯 是个难题 很想知道敏捷测试和一般的测试有什么 本质的区别，没有做过敏捷测试，上网查了下，都介绍的很模糊，看了上面各位的解释，还是没有把握住本质，请知道的麻烦告知俺一下---------- 根据流程做好自己的每一步 回复 13# zxnah
看样子是89期的学生吧，如果想听敏捷的课，可以偷偷回来蹭课啊。:lol 我们的项目已经开展敏捷两年了，我觉得挺好的呀，价值就是能适应不断的变化，能以人为中心，挺好的，不强制，强调自主性
页:
[1]
2
