敏捷测试思考

敏捷测试应该具备的技能：（待补充）

 

一、敏捷测试人员的焦虑与困惑。（转载）

参加过多次敏捷项目培训，发现培训老师对测试人员的角色定位和敏捷测试意识鲜有提起，大家也更多关注于流程、功能分解、迭代周期和时间进度安排等。常常看见敏捷项目组里的测试人员对一些问题感到焦虑、困惑，比如：

需求文档太少，无法理解需求或对需求理解不深刻，难以设计测试。

需求变化过于频繁，测试用例维护工作量大。

时常发现自己所做的工作超出自己的职责。

测试人员不足，迭代周期短、测试时间紧，回归测试不全导致遗漏缺陷。

测试人员存在感不强，难以融入开发团队。

测试人员代码能力不足，无法编写单元测试代码或自动化测试脚本。

开发自测不足，太依赖测试人员的系统测试。

提交的缺陷不被重视。

与开发人员沟通存在问题。

等待版本、等待环境。

   

如果对敏捷项目、敏捷开发流程多做些了解，会发现其中的一部分困惑其实主要来源于对敏捷测试的认识、思考和实践不足。下面就谈谈一个优秀敏捷项目测试人员应具备的敏捷意识，以及如何通过这些意识去解决面临的“问题”。

二、一个优秀的敏捷项目测试人员应具备的意识

相对传统项目而言，敏捷项目对测试人员有更高的要求，对测试人员是一种挑战，也是一个全方位锻炼、成长的机会。一个优秀的敏捷项目测试人员应具备如下意识：

（一）心态

  以积极的心态拥抱变化:敏捷，即快速变化。敏捷项目原本充满变化

和不确定性，因而需求变化比较快，产品开发周期短，给软件测试带来很大的挑战。但每一次的需求调整都是为了使产品开发朝着更正确的方向开展，测试人员应给予理解，减少无用的抱怨，积极主动去接受变化、理解变化，采取探索性测试尽早发现可能存在的问题，给予及时反馈。

（二）文档

  接受精简的文档:如果要求需求频繁变化的敏捷项目像传统项目一样有

详尽的文档，那么，每次变化将需要花费大量的时间来更新需求。特别是变化后不进行同步更新，将比精简的文档还糟糕。在敏捷项目中，直接沟通交流的效率远大于文档，而且直接沟通更能在理解上达成一致。测试人员可以通过主动沟通了解需求，自己整理出一份详细的需求，并不一定要像需求规格一样标准，易于理解即可。通过整理，可以更深入理解需求、发现问题、暴露问题。当然，也不能走极端，认为敏捷可以不要文档，核心业务逻辑应有文档或会议纪要体现。

  测试简单化：测试应关注于产生价值，不断尝试最简单的方法满足测试

需要。比如，迭代初期，测试用例可以简单到只是包括所有测试点的清单，不仅可以节省评审时间，也可以避免需求的频繁变动加大测试用例维护的工作量。当然，每个迭代仍然需要明确且易于修改的测试计划、测试目标、测试范围、测试类型，选择合适的测试策略。在版本稳定后，再进行标准的用例库建设。

（三）主动意识

  尽可能多的参与需求讨论：测试人员可以利用自己在用户体验、业务逻

辑方面的经验，和项目组成员充分交流和讨论，提出有建设性的建议。也可以通过需求讨论，更加深入理解需求。

  作为勇敢的发言者：敏捷团队是民主的，团队成员能够平等参与讨论。

思想的碰撞，更易突发灵感产生创造性的思维，有想法和建设性的建议应该勇敢提出来。测试人员和开发人员所站角度不同，测试人员的视角更接近客户，不要害怕所提的问题过于简单。要敢于提出问题、发表自己的意见、提出建议，尽早揭示风险、暴露问题，以免在后期造成更大的影响。

  主动沟通和协作意识：进入敏捷的协作环境，测试人员不应该局限在

自己的职责领域，应关注于项目组共同的目标，尽可能产生更大的价值。优秀的测试人员应该知道如何与他人更好的沟通、合作，且随时准备协作。良好的团队沟通和协作意识也是项目成功的关键因素之一。

  乐于分享与反馈信息：一个测试人员所负责的功能一般不仅限于一个模

块，因而比一个开发人员能掌握更多的需求信息。测试人员可以向项目组成员积极分享需求、反馈各功能模块的测试进展，让所有人更了解整体需求和项目动态。及时提供全面的质量反馈，每个周期对缺陷分类汇总，分析相似缺陷的发生频率和易发缺陷的功能模块，用清晰的图形化展示，提醒开发人员避免再次产生同样的缺陷。

  主动参与代码复审：测试人员不写代码，但可以主动参与代码复审，有

助于提升代码阅读能力，也可能以测试人员的视角发现隐蔽的缺陷。

  不断改进工作和学习新技能：创新无论在哪里都非常重要。敏捷开发鼓

励团队采纳新技术，使产品和团队自身都有很强的适应力和生命力。测试人员应该不断的学习和自我提升才能更好的适应和应对变化，努力培养自己的工作技术，关注、读好的文章以获得新想法和技能，试验新的工具和技术，改进测试工作。

（四）测试方法

  测试驱动开发：敏捷项目测试人员参与了整个软件生命周期，测试人员

应该在不同阶段确认和验证、预防缺陷，而不是等到软件开发完成后才去发现缺陷。单元测试驱动开发(UTDD)和验收测试驱动开发(ATDD)，前者大多由开发负责，后者由测试操作。测试人员可以关注和推动单元测试，并利用专业测试、需求理解能力，以测试需求驱动、指导开发。当编码由测试指导，开发的产品可能更符合客户的期望，也有助于确保版本发布后重要功能正确、迭代功能无缺失。

  测试自动化：众所周知，由于敏捷项目快速迭代的特点，用自动化做回

归测试是敏捷项目成功的要素之一。敏捷测试中回归测试是必须的，没时间实现测试自动化是一个不断积累债务的过程。测试自动化开始时会比较艰难，应尽早克服困难，选定或准备合适的工具。一旦某些核心功能稳定，每个迭代开始小规模的自动化工作，逐步把稳定的功能用自动化测试实现，减少回归时间和成本，将原本可发挥更大价值的人力从重复的手工测试中解放出来，将更多的时间用于重要的探索性测试。经验统计显示，80%的缺陷是在探索测试过程中发现的。

（五）敏捷观

  树立正确的敏捷测试观念：敏捷项目是以结果为导向的，因此敏捷测试

同样是结果导向。要有全局观，不只是关注于发现缺陷，也不以发现缺陷多少为目标，应关注于是否实现当前的功能。测试人员和开发人员都有相同的质量目标，应尽量协助开发人员不断提高软件的质量。不要“等待”，尽可能的早工作，做能够做的工作。

三、总结

    通过上面对敏捷意识的描述，可以看到前面提到的文档问题、职责问题、融合问题、技能问题等等其实大多都不是问题，可以通过提高敏捷意识来解决，而这种敏捷意识对一个敏捷项目的成功起着极大的推动作用。敏捷测试人员在提高自身意识的同时，也应努力推动项目组的整体意识，制定出测试标准、流程，让体系约束大家，共同提高软件开发和测试的质量。