敏捷测试的要领

做自己的女王ヽ

前两天公司组织了一次敏捷开发模式的分享会，对于测试人员来说，为了推动整个模式的高效运作，
测试也有敏捷，如下是个人觉得敏捷测试中涉及到的一些关键点与大家分享。

一、测试也有敏捷

1、全程参与

      测试人员从项目立项到发布结束全程参与整个研发过程，而不是开发完毕后很突然的提交到测
试部安排测试，测试人员必须从需求阶段就开始介入，从理解需求到帮助产品人员完善需求；在我
们很多项目中经常忽略了测试人员参与需求的评审及讨论，这个和W模型中谈到的测试和开发并行
稍有区别，以前的有V和W模型，而现在的是敏捷模型（具体区别在哪里有时间再和大家分享）。

2、从客户出发

      保持大局观，站在客户的立场，保证最终发布的是一个优秀的产品，而不仅仅是提交了多少个
Bug，这主要是价值取向不一样，在一个团队中，不管你处于什么角色，最终的目的是要让这个产
品是一个优秀的产品，是客户需要的有价值的产品，而不是各个角色在这个项目中付出了多少，提
交多少Bug等等各自的业绩数据。

3、测试驱动

      测试驱动产品整个开发过程，测试人员要做的不仅仅是测试，而是要做对这个项目一切有利的
事情，比如与客户沟通需求澄清、版本控制、流程机制等其他事务。

4、时刻敏捷

      根据不同迭代调整测试策略（测试进度、人力投入、测试方向）

5、不是一个人

      项目所有人员均参与测试，当然测试人员肯定是主要角色了，其他开发人员、产品人员等和项
目相关的人员也要抽一定的时间来测试，只是和测试人员测试的重点和方向不一样而已，比如产品
人员更多的关注用户体验、价值收益等，一但发现问题或者不妥之处立即反馈修正。



二、走出敏捷误区

1、敏捷开发是否需要文档？

      敏捷肯定也需要文档，只是没有CMMI要求的那个严格，那么细致。我们也不能完全依靠文档来
帮助我们提高效率，但一些框架性基础性的文档肯定是需要的，特别是基础需求，这样能够帮助项
目成员了解整个项目的大概意图。在敏捷的过程中我们要做好文档的变更管理（因为变化无处不在）。

     很多人认为敏捷重在沟通，这完全没错，但我们不能因为这个缺乏一些文档支撑，不能只靠口头
或者零粹的邮件代替文档，那就是乱上加乱，敏捷过头了！

2、敏捷开发模式与项目管理是否有冲突？

     完全没有冲突，只是价值观有些区别，其实在某种意义上来说，如果项目管理没做好就直接进入
敏捷模式跨越比较大，推行起来比较困难，比如项目管理中涉及到的变更管理、沟通管理等这些都
是敏捷模式所需要的，也是一些基础性的工作方式。因此可以认为项目管理是一个基础。

3、敏捷是善变的良药？

    显然敏捷不是善变的良药，一个产品的研发过程中肯定会涉及到很多变化，但是我们的方向不能
变，比如开始需求是要做一个花卷，最后改成要做包子，其实像这类变化是不能容忍的，如果要改
变花卷的颜色形状那还是可行的。

    敏捷中涉及到的变化是指在需求不清晰的情况下，通过迭代让客户快速确认反馈最终形成一个非
常清晰的需求并得以呈现，而不是随意的变化，那技术人员不累死还不讨好。

三、敏捷要求

1、产品的整体规划及需求说明（包括未来的产品走向）

      我们把产品比喻成一个孩子的话，那么产品经理就犹如这个孩子的父母，作为父母的必须要为
孩子的成长做一些规划，这样才有利于孩子的成长以及在成长过程中根据孩子的反馈不断的修正成
长路线，这样父母才是一个合格的父母。

2、迭代计划需要产品人员制定和重点把控

      和前一个观点差不多，只是说明产品人员是一个产品成功或者失败的关键，是产品的灵魂人物，
产品经理们责任重大啊。

3、迭代的划分要遵循可测试性原则（保证每次迭代是一个可执行完整操作流的测试）

      在做迭代计划中需要测试人员参与考量下每次迭代的可测试性是否最佳，不能出现迭代开发
完毕后完全是一个不能测试不能评估的半成品，都展现不出什么价值谈何评估反馈，不能为下一
个迭代提供有价值的东西那么就不要去迭代，直接与其他合并即可。

4、迭代中的需求变更需要落实在文字或图表上

5、测试将原有的W测试模式变为迭代测试

6、文档流程只是一个辅助工具，最主要依靠及时有效的沟通（文档、沟通之间如何权衡这是个度
的问题，千万不能走极端）。

海海豚

谢谢分享~

libingyu135

学习了