敏捷开发模式下如何更好的进行测试

最近CTO组建了一个敏捷开发团队，团队人员包括  PM、设计、开发、测试角色，主要由PM来主导团队走向，因为以前并没有参加过敏捷开发的经验，对敏捷开发做了简单理解后，参考了前人的一些意见，总结出在

敏捷开发模式下如何更好的进行测试

 

首先：意识的转变：

意识需要从发现Bug转变为预防Bug出现，

从越多发现Bug转变为越早发现Bug

测试人员应该及时跟上开发和需求人员的脚步，及时地更新测试用例，并提醒大家需求的变更是不是超过了限度，该控制控制了

 

测试前期：1.全程参与需求讨论，最早在需求讨论阶段，帮助需求和开发对需求有正确和共同的认识，例如主导更多的用户场景、异常等讨论

　　　　　2.测试的用例同样有优先级,针对性编写用例（重点）

　　　　　3.对每个迭代所要达到的目标烂熟于心， 说测试是贯彻开发始终的

 

　

 

测试中: 1.与开发沟通上又直接交流、灵活应对变化，质量控制，什么bug是重要的，什么是可以后期去做，分清bug优先级

             2.引入能帮助测试更简便的测试工具和方法，如自动化测试，可以帮助测试人员有更多的时间去探索性测试

 

测试产出：测试用例、测试报告

 

scrum

测试团队的主要职责是尽早给出质量反馈，做到风险前移：
1) 最早在需求讨论阶段，帮助需求和开发对需求有正确和共同的认识，例如主导更多的用户场景、异常等讨论
2) 用于测试的用例同样有优先级，最高的优先级是“用户使用最多”以及“最容易发生bug”的场景交集
3) 缩短测试时间，更多使用自动化，例如Cucumber、Fitness、Selenium等的使用
4) 测试工作的过程和结果可视化(最后有产出结果)，方便团队内的沟通
另外，测试团队需要有一线工作的意识：测试人员需要参加计划、估算、执行、回顾等与产品交付相关的任何环节

 

 

 

下面是百度、知乎下的各前辈的知识，十分感谢各位大神的经验。

敏捷开发、测试相关链接（全英文。。。。）：http://www.methodsandtools.com/archive/archive.php?id=88、http://www.ambysoft.com/essays/agileTesting.html

知乎相关链接：https://www.zhihu.com/question/19624692

目的一定要清晰：

测试人员也需要对每个迭代所要达到的目标烂熟于心， 说测试是贯彻开发始终的

 

 

敏捷测试关键成功要素

1.使用团队整体参与的方法

2.采用敏捷测试思维（直接交流、灵活应对变化、鼓励尝试新技术方法尝试最简单的方法来满足测试需要。）

3.自动化回归测试（自动化冒烟测试、自动化单元测试）

4.提供并获取反馈。

5.构建核心实践的基础（持续集成、测试环境、管理技术债务、增量工作、编码和测试同一过程）

6.与客户合作

7.保持大局观

敏捷过程中，测试的主要职责应该是对每次迭代的产出物做验证，确保产出物满足产品设计需求，质量合格。

 

1. .需求的把握。测试要对不断变化的需求都能把握住，以PO（product ower）的标准来要求自己，敏捷的要旨是小步快跑，保证每一步都是对的，这样在团队中就需要有人来保证我们做出来的东西是没有偏离需求的，这个角色只有测试胜任；

 

2.团队节奏的控制。不知道大家有没有做过敏捷项目，迭代不断的出现延迟，问题单越来越多，大家疲于根据计划加班。这个时候我们可不可以把下个迭代要做的事情暂时先停下来，留一个迭代或者半个迭代来解决问题，重新读下代码，找出那些异味的代码（smelly code）重写一下。找找我们流程中的问题并改进。这个事情也是由测试人员来提出比较合适；

3.质量控制。

这当然是测试的传统的工作，找出问题，让开发人员来解决。对于一个tester来说，质量控制Quality Control比质量保证Quality Assurence更重要。在敏捷阶段，不是说发现的所有问题都需要马上让开发人员去改，因为或许这个bug对应的需求还不明确，或许下轮的重构就能自动解决问题，或许当前这个迭代使用的技术解决这个问题代价太大... 总之，这里是比较灵活的，也是比较考验测试人员的经验的，什么问题应该马上解决，什么问题可以讨论。

 

 

4.测试尽可能去参与集成测试的，只是这个过程对测试来说比较痛苦，需要了解代码，有一定的编码能力。

 

5.测试产出

文档，测试分析，问题单，测试需求分析等等。。。 这个也是和产品的形态有关，如果是轻量级的产品完全不需要做很多事情，或者很多事情可以合并来做，产出一份文档或者结果就可以。

 

6.关于自动化测试

第一，在敏捷里面测试有一个很重要的产出就是自动化测试，有了自动化测试之后测试人员有更多的时间去做探索性的测试，并且自动化测试能够给予团队一个很好的反馈，你改动了代码之后是否对系统有影响都能及时的反馈出来。第二，测试团队对需求的影响。测试人员在设计测试用例时就会对用户的场景和预期的行为有一个描述，就会出现一些产品人员考虑不到的情况，这样便可以更加完善需求，提升产品的体验和质量。

 

 

用例：用例一定要全

 

1，文档要全，而且要保证质量，不过测试用例例外，看情况而来。

测试人员应该着眼于关键点，一个全面的测试用例也常常被证明40%以上的用例是徒劳的。根据经验能够判断出哪里是潜在bug、缺陷和主要数据流关键点，针对这些地方写测试用例，方便管理也能够判断数据流阶段性的正确。还有就是TDD在开发过程中的保证，前期的需求讨论，测试人员参与程度应比开发人员更高，而系统架构确定、软件架构确定，都是由开发和测试共同决定，并在开发过程中出现需求变动，也保持软件架构的相对稳定，因为软件架构的改动对于测试人员来讲不单单是改动，很可能是重新来过。

 

2，这个不管是不是敏捷的，前期都尽量挖掘客户的需求，不留下任何潜在的需求。开发过程中的需求变动，根据经验来说，还没有遇上过需求不变的。这个其实是很无奈的，这是由客户方不够专业引起的，这也确实没有办法，只能是期望变动不是翻天覆地的。

 

3，开发过程差不多，或者说一样也可以，但敏捷方法对人员上的控制有一些建议，来使人员工作效率更高，交流成本更低。在这方面来讲，敏捷对于人的性格也有要求，不是每个人都适合参加敏捷开发，在搞人这方面上，敏捷只是提出了一些建议，最佳实践还是得根据公司人员和公司内部结构的实际情况来定了。