当最初加入敏捷团队或者当前的团队开始过渡到敏捷开发模式时,通常你会产
生恐惧感,并且存在大量的问题需要答案。我们到底如何才能在如此短的时间内完 成对每一个用户故事的测试任务?测试如何跟上开发的节奏?如何确定需要多少测 试?又或者你是功能测试经理或者质量过程经理,但不清楚在敏捷团队中如何定位 自己的角色,也没人知道答案。敏捷测试人员需要勇气找到这些问题的答案,但需 要勇气的原因不仅限于此。
简单化
敏捷测试人员和他们的团队面临的挑战不仅是生产最简单的有效软件而且还 需要采取简单的方法以确保软件符合客户需求。这并不意味着团队不应该花时间 分析主题和故事、思考合适的架构和设计。而是说,当业务部门的需求比较复杂 的时候,团队可能需要将方案退回给他们,更简单的解决方案也会产生同样的价值。
简单并不意味着容易。对于测试人员来说,这意味着采用能够找到的最轻量 级的工具和技术恰到好处地测试。工具可以简单到只是一张电子表格或者清单。 需要自动化回归测试,但是应该把它们分解到最底层以获取快速反馈。甚至简单 的冒烟测试也可能满足面向业务的测试自动化。
持续改进
想办法把工作做得更出色是敏捷测试人员应牢记的。
敏捷测试人员和他们的团队总是在寻找工具、技能或者实践以帮助他们增加更 多价值或者得到更好的客户投资回报。敏捷开发的短期迭代更易于尝试新事物,以 验证是否值得长期采用。
学习新技能和提高专业技能水平对敏捷测试人员非常重要。可利用各种免费的资源 提高专业技能。
响应变化
响应变化是敏捷实践的重要价值,但是我们发现这对测试人员来说却是最困 难的概念之一。测试人员渴望的是稳定,所以他们会说:“我已经测试过了, 任务完成了”。持续的需求变化是测试人员的噩梦。但是,作为一名敏捷测试人员, 我们不得不拥抱变化。周三,我们可能期望启动故事A和B,下周五做故事C。但是 到了周五,客户重新设定了优先级,现在需要故事A、X和Y。只要我们持续与客户 交流,我们就能处理这些变化,因为我们与团队的其他成员保持同步。
自我组织
敏捷测试人员是自组织敏捷团队的组成部分。团队文化贯彻于敏捷测试理念。 当开发人员、系统管理员、分析员、数据库专家和客户团队持续关注测试和测试 自动化,测试人员就会获得全新的视角。自动化测试很困难,但是当整个团队都 在为此努力时就会简单得多。当大家具有多重技能和多层次视角时,任何测试问 题都会更容易解决。
当敏捷团队面对一个严重问题时,比如进度障碍或者构建失败,该问题将是 所有人的问题。最高优先级的问题需要整个团队解决。团队应该立刻讨论并决定 解决的办法和相关参与人员。
关注人
只有优秀的员工出色地工作,项目才会成功。敏捷价值和准则的宗旨是确 保个人和团队成功。敏捷团队成员应该有安全感。不必担心因犯错受指责或者 失去工作。敏捷团队成员互相尊重并认可个人成就。敏捷团队的所有人应该有机 会提高和发展他们的技能。敏捷团队以可持续的步伐前进,使他们能够遵循严格 的实践和保持崭新的视角。正如敏捷宣言所说,我们重视个人和合作超过过程 和工具。
享受乐趣
在我们看来,测试人员的理想团队是:所有成员协作,从项目的开始一直 到结束,利益相关者与开发团队共同工作,整个团队负责质量和测试。相信很 多人都认为每个人都应该在工作中找到乐趣。敏捷开发珍视敏捷测试人员对工作的 激情。
敏捷测试人员的工作特别令人满意,因为我们的角度和技能对团队产生了真 正的价值。
敏捷测试人员应该做什么?
看了这么多,你一定问:
测试人员在敏捷团队中应该具备什么技能?
测试人员在敏捷团队中从事哪些具体的工作?
在敏捷软件开发过程中开展的测试就可以被称作是敏捷软件测试。因此,敏捷 软件测试并不是一个与敏捷软件开发同一层次的划分,而是敏捷软件开发中的一部 分,与传统的测试不同,敏捷软件测试并不是一个独立的过程,相反,它与整个敏 捷开发中的其他活动交织在一起,处处都能看到它的影子。由于敏捷软件测试并不 倾向于一个单独的过程定义,本人认为从敏捷软件测试与传统测试观点的比较、 敏捷软件测试中采用的方法、测试工程师在敏捷软件测试过程中的工作等方面来阐述。
回答的很含糊,个人认为敏捷测试人员应该具备的两个主面。
首先,接纳并理解敏捷的核心价值观(沟通,简单,反馈,勇气,尊重、学习、 分享)。
其次,测试人员应该具备测试基本技能,当然,可以擅长某个领域,如,探索 性测试、单元测试。善于学习与分享,以学习的方式不断的提高自身去适应团队的 需求。
我想说的是,不管是从传统开发模式转到敏捷测试,还是重新组建一个敏捷的 测试团队。并不是一蹴而就的事儿,需要长期的学习、摸索与改进。当然,前提是 以敏捷的价值观为指导思想。
|