敏捷测试人员的十条法则

发表于:2011-9-08 14:58

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:未知    来源:51Testing软件测试网采编

  (3)进行面对面的沟通

  一个团队如果沟通不好则难以协作。如今,许多团队分布于多个地理位置,沟通变得更加重要和富有挑战性。敏捷测试人员应该尽力促进沟通。这是把工作做好的关键因素。

----------------------------------------------------------------------------------------------------------------------------------------------------

  Janet的故事

  我曾经在一个团队工作,当时开发人员只与产品负责人交流,而把测试人员排除在外。他们随后才寻求了一些改变。开发人员不与测试人员坐在一起讨论的部分原因在于制度问题。另一个原因是历史问题。测试团队是一个新队伍,产品负责人已经习惯了直接联系开发人员。

  我在团队里提出了这个问题,大家建立了一个规则。我们发现“三方协作的力量”获得了巨大成功。这意味着所有关于一项功能的讨论都需要开发人员、测试人员和产品负责人的参与。每一个人都有责任确保“三方协作”。如果有人发现另外两个人在交谈,他有权利加入。很快这变成了惯例,再也没有人想把测试人员置于讨论之外。这种做法使团队找到了解决所有问题的办法。

  —— Janet

----------------------------------------------------------------------------------------------------------------------------------------------------

  每当讨论一项功能如何运转或者一个接口应该如何定义时,测试人员都可以与开发人员和业务专家讨论。测试人员绝不应该阻碍一切客户和开发人员之间的沟通,他们要确保沟通是有效的。

  敏捷测试人员从客户的角度思考每一个故事,但是也理解实现功能相关的技术和局限性。他们可以帮助客户和开发人员达成共识。业务人员和软件人员经常使用不同的语言。他们不得不找到一些共同点来展开协作。测试人员可以帮助他们拥有一种共通语言。

  Brian Marick(2004)提倡我们应该使用实例来定义这种语言。当Lisa的团队在sprint规划会议中偏离主题成为哲学讨论时,Lisa要求产品负责人提供一个示例或者使用场景。测试人员能够通过更多的示例活跃讨论。这有助于客户更清晰地设想他们的需求。测试人员也会帮助开发人员编写精心设计的代码以满足需求。?

  面对面的沟通是不可替代的。敏捷开发依赖于持续的合作。就像其他敏捷团队成员一样,从事测试工作的人会不断寻找客户和技术团队成员来讨论和合作。当敏捷测试人员对某个隐藏的假设或者误解的需求产生怀疑时,她会与客户和开发人员讨论。如果处于不同地点的人需要交谈,他们会试图寻找创造性的方式替代面对面、实时的交流。

  (4)勇气

  勇气是极限编程的核心价值,类似测试自动化和持续集成的方式允许团队实践这种价值。开发人员有勇气修改和重构代码,因为他们拥有自动化回归测试集的安全保护。在本节,我们将讨论敏捷团队转型中所需的勇气。

  你是否曾经在这样的团队中工作:测试人员固守于自己的领域,不与其他业务相关者和技术团队进行任何讨论。虽然你找机会进入了协作的敏捷环境,可能会对找客户索要实例或者找开发人员帮忙自动化测试或者在每日例会时提出一个难题等感到不习惯。

  当最初加入敏捷团队或者当前的团队开始过渡到敏捷开发模式时,通常你会产生恐惧感,并且存在大量的问题需要答案。我们到底如何才能在如此短的时间内完成对每一个用户故事的测试任务?测试如何跟上开发的节奏?如何确定需要多少测试?又或者你是功能测试经理或者质量过程经理,但不清楚在敏捷团队中如何定位自己的角色,也没人知道答案。敏捷测试人员需要勇气找到这些问题的答案,但需要勇气的原因不仅限于此。

  我们需要勇气允许自己失败,至少我们会有短暂性失败,我们要从失败中学习教训。在由于构建版本不稳定导致一次迭代失败之后,我们要开始寻找方法以确保这种事情不再发生。

  我们需要勇气允许其他人犯错误,因为这是汲取教训的唯一途径。

----------------------------------------------------------------------------------------------------------------------------------------------------

  Lisa的故事

  我曾经参与过一个项目,当时的敏捷指导员坚持我应该呆在独立的测试团队里(通常只有一个人),其中的工作不包含在开发人员的跟踪和进度中。我不得不尝试一下。在项目由于测试没有完成遭遇麻烦之后,我询问敏捷指导员是否可以按照我希望的测试方式尝试一个或两个迭代。团队整体运作的方式是非常令人满意。在迭代结束之前每一个用户故事都被做了测试(并实现),客户对此结果更加满意。

  —— Lisa

----------------------------------------------------------------------------------------------------------------------------------------------------

  我们需要勇气寻求帮助,特别是当能够提供帮助的人看起来特别忙碌的时候。抛弃旧的制度,加入一个关乎项目成功与否的团队也需要勇气。提出问题或者指出你的想法存在缺陷需要勇气,即使是在遵循敏捷价值和原则的团队中。不要害怕,敏捷团队是开放的,通常都会接受新观念。

63/6<123456>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号