提起敏捷项目,大家都非常耳熟。在国内,2012年到2015年敏捷开发可谓热火朝天。即使是现在,很多软件公司的培训主题也仍然少不了它。即便如此,调查结果却显示超过一半的人并不记得敏捷宣言。如果正在或将要做敏捷项目,建议先了解下敏捷宣言,有助于产生敏捷意识,对敏捷项目有更深层的理解。
一、敏捷测试人员的焦虑与困惑。
参加过多次敏捷项目培训,发现培训老师对测试人员的角色定位和敏捷测试意识鲜有提起,大家也更多关注于流程、功能分解、迭代周期和时间进度安排等。常常看见敏捷项目组里的测试人员对一些问题感到焦虑、困惑,比如:
需求文档太少,无法理解需求或对需求理解不深刻,难以设计测试。 |
需求变化过于频繁,测试用例维护工作量大。 |
时常发现自己所做的工作超出自己的职责。 |
测试人员不足,迭代周期短、测试时间紧,回归测试不全导致遗漏缺陷。 |
测试人员存在感不强,难以融入开发团队。 |
测试人员代码能力不足,无法编写单元测试代码或自动化测试脚本。 |
开发自测不足,太依赖测试人员的系统测试。 |
提交的缺陷不被重视。 |
与开发人员沟通存在问题。 |
等待版本、等待环境。 |
如果对敏捷项目、敏捷开发流程多做些了解,会发现其中的一部分困惑其实主要来源于对敏捷测试的认识、思考和实践不足。下面就谈谈一个优秀敏捷项目测试人员应具备的敏捷意识,以及如何通过这些意识去解决面临的“问题”。
二、一个优秀的敏捷项目测试人员应具备的意识
相对传统项目而言,敏捷项目对测试人员有更高的要求,对测试人员是一种挑战,也是一个全方位锻炼、成长的机会。一个优秀的敏捷项目测试人员应具备如下意识:
(一)心态
以积极的心态拥抱变化:敏捷,即快速变化。敏捷项目原本充满变化
和不确定性,因而需求变化比较快,产品开发周期短,给软件测试带来很大的挑战。但每一次的需求调整都是为了使产品开发朝着更正确的方向开展,测试人员应给予理解,减少无用的抱怨,积极主动去接受变化、理解变化,采取探索性测试尽早发现可能存在的问题,给予及时反馈。
(二)文档
接受精简的文档:如果要求需求频繁变化的敏捷项目像传统项目一样有
详尽的文档,那么,每次变化将需要花费大量的时间来更新需求。特别是变化后不进行同步更新,将比精简的文档还糟糕。在敏捷项目中,直接沟通交流的效率远大于文档,而且直接沟通更能在理解上达成一致。测试人员可以通过主动沟通了解需求,自己整理出一份详细的需求,并不一定要像需求规格一样标准,易于理解即可。通过整理,可以更深入理解需求、发现问题、暴露问题。当然,也不能走极端,认为敏捷可以不要文档,核心业务逻辑应有文档或会议纪要体现。
测试简单化:测试应关注于产生价值,不断尝试最简单的方法满足测试
需要。比如,迭代初期,测试用例可以简单到只是包括所有测试点的清单,不仅可以节省评审时间,也可以避免需求的频繁变动加大测试用例维护的工作量。当然,每个迭代仍然需要明确且易于修改的测试计划、测试目标、测试范围、测试类型,选择合适的测试策略。在版本稳定后,再进行标准的用例库建设。
(三)主动意识
尽可能多的参与需求讨论:测试人员可以利用自己在用户体验、业务逻
辑方面的经验,和项目组成员充分交流和讨论,提出有建设性的建议。也可以通过需求讨论,更加深入理解需求。
作为勇敢的发言者:敏捷团队是民主的,团队成员能够平等参与讨论。
思想的碰撞,更易突发灵感产生创造性的思维,有想法和建设性的建议应该勇敢提出来。测试人员和开发人员所站角度不同,测试人员的视角更接近客户,不要害怕所提的问题过于简单。要敢于提出问题、发表自己的意见、提出建议,尽早揭示风险、暴露问题,以免在后期造成更大的影响。
主动沟通和协作意识:进入敏捷的协作环境,测试人员不应该局限在
自己的职责领域,应关注于项目组共同的目标,尽可能产生更大的价值。优秀的测试人员应该知道如何与他人更好的沟通、合作,且随时准备协作。良好的团队沟通和协作意识也是项目成功的关键因素之一。
乐于分享与反馈信息:一个测试人员所负责的功能一般不仅限于一个模
块,因而比一个开发人员能掌握更多的需求信息。测试人员可以向项目组成员积极分享需求、反馈各功能模块的测试进展,让所有人更了解整体需求和项目动态。及时提供全面的质量反馈,每个周期对缺陷分类汇总,分析相似缺陷的发生频率和易发缺陷的功能模块,用清晰的图形化展示,提醒开发人员避免再次产生同样的缺陷。
主动参与代码复审:测试人员不写代码,但可以主动参与代码复审,有
助于提升代码阅读能力,也可能以测试人员的视角发现隐蔽的缺陷。
不断改进工作和学习新技能:创新无论在哪里都非常重要。敏捷开发鼓
励团队采纳新技术,使产品和团队自身都有很强的适应力和生命力。测试人员应该不断的学习和自我提升才能更好的适应和应对变化,努力培养自己的工作技术,关注、读好的文章以获得新想法和技能,试验新的工具和技术,改进测试工作。
(四)测试方法
测试驱动开发:敏捷项目测试人员参与了整个软件生命周期,测试人员
应该在不同阶段确认和验证、预防缺陷,而不是等到软件开发完成后才去发现缺陷。单元测试驱动开发(UTDD)和验收测试驱动开发(ATDD),前者大多由开发负责,后者由测试操作。测试人员可以关注和推动单元测试,并利用专业测试、需求理解能力,以测试需求驱动、指导开发。当编码由测试指导,开发的产品可能更符合客户的期望,也有助于确保版本发布后重要功能正确、迭代功能无缺失。
测试自动化:众所周知,由于敏捷项目快速迭代的特点,用自动化做回
归测试是敏捷项目成功的要素之一。敏捷测试中回归测试是必须的,没时间实现测试自动化是一个不断积累债务的过程。测试自动化开始时会比较艰难,应尽早克服困难,选定或准备合适的工具。一旦某些核心功能稳定,每个迭代开始小规模的自动化工作,逐步把稳定的功能用自动化测试实现,减少回归时间和成本,将原本可发挥更大价值的人力从重复的手工测试中解放出来,将更多的时间用于重要的探索性测试。经验统计显示,80%的缺陷是在探索测试过程中发现的。
(五)敏捷观
树立正确的敏捷测试观念:敏捷项目是以结果为导向的,因此敏捷测试
同样是结果导向。要有全局观,不只是关注于发现缺陷,也不以发现缺陷多少为目标,应关注于是否实现当前的功能。测试人员和开发人员都有相同的质量目标,应尽量协助开发人员不断提高软件的质量。不要“等待”,尽可能的早工作,做能够做的工作。
三、总结
通过上面对敏捷意识的描述,可以看到前面提到的文档问题、职责问题、融合问题、技能问题等等其实大多都不是问题,可以通过提高敏捷意识来解决,而这种敏捷意识对一个敏捷项目的成功起着极大的推动作用。敏捷测试人员在提高自身意识的同时,也应努力推动项目组的整体意识,制定出测试标准、流程,让体系约束大家,共同提高软件开发和测试的质量。