“蒲池幸子”通过精心收集，向本站投稿了2篇将测试人员整合到敏捷团队中，下面是小编整理后的将测试人员整合到敏捷团队中，欢迎大家阅读借鉴，并有积极分享。
篇1：将测试人员整合到敏捷团队中
将测试人员整合到敏捷团队中，这是敏捷之道常常重复的一条箴言，可我们并没有认真想过这到底意味着什么或者应该怎么做，
团队中测试人员的角色具体负责什么呢？他们要：
协助团队抽取并定义验收条件（或需求）
提供相关质量信息，而不是通过自动化测试、探索性测试（exploratory test）［译注］来寻找bug
与客户一起工作，识别风险
在开发人员测试（单元测试与集成测试）的薄弱环节投入更多精力。比如，如果我们知道团队已经完成了对数据层的测试，但是GUI层难于进行单元测试，那测试人员就应该花费更多努力在这一层的测试上。
选编自（Cem Kaner, Johanna Rotheman(pdf)，以及Jonathan Kohl）。
与大多数人已经熟知的传统测试经验大不相同，敏捷团队中的测试有其自身特点。Jonathan Kohl，是Kohl Concepts的联合创始人。如他所说：“不同之处在于：在敏捷项目中，我们可以更快地找到重要的bug。我们更愿意将测试贯穿于开发过程始终。现在开发人员们使用可靠的自动化测试来让他们的工作更加严谨，我所测试的产品也就更加健壮了。”
Antony Marcano是一位敏捷测试独立咨询顾问，他提及了自己学习到的一些经验：
编写验收测试需要协作：尤其是在客户、测试人员和程序员之间。
测试人员与开发人员应该互相提升彼此的技能。
测试任务应该作为sprint backlog的一部分，而不能是单独的测试计划，
使用“探索性测试”来产生反馈。
在修复bug之前，要先写自动化测试以重现这些bug。
Simon Baker是Energized Work的联合创始人。在他的团队中，开发人员编写绝大部分的验收测试。测试人员从而可以专注于进行“探索性测试”，并与Product Owner一起与客户沟通，并帮助团队理解用户（而不仅仅是故事）。开发人员针对垂直的切片（故事的小部分）展开工作，以满足特定的验收条件。当切片完成后，开发人员与测试人员一起仔细检查切片，并理解验收测试。团队将缺陷视为工作线性进展的停止点。开发人员可以在下次切片处理过程中修复缺陷，或者选择创建一个缺陷修复任务，从而使其不再处于开发阶段。缺陷修复任务成为团队优先级最高的任务。测试人员发现，即使他们与开发人员都使用同样的技能，还是要花费很多时间彼此协作，而整理bug的时间反而少了。
译注：探索性测试（Exloratory Test），是一种通过假定来寻找软件缺陷的战术测试技能。利用它，可以同时进行学习、测试设计和测试执行。软件在接受测试的同时，测试人员学到新的东西，积累更多经验，从而能够产生更多优秀的、有新意的测试。
查看英文原文：Integrating Testers on to the Agile Team来自：www.infoq.com/cn/news/2008/05/testers_on_team
篇2：敏捷团队中测试人员和开发人员的合理比例？视情况而定
软件开发世界里有这样一个长期存在的问题是：测试人员和开发人员的比例多少才合理？Scrum开发列表中最近有一个帖子，询问敏捷对这个比例有什么影响，对第一个问题，答案应该“视情况而定”。对第二个问题，Elisabeth Hendrickson认为，敏捷团队能够用更少的测试人员，但是做更多的测试。
测试人员和开发人员的比例多少才合理？
许多年来，人们对研究测试人员和开发人员的“合理”比例充满了兴趣。《微软秘笈》书中指出，微软员工中测试人员和开发人员的比例是1比1。根据在某会议上非正式的调查，Randall Rice发现通常的比例是1个测试人员对3个开发人员。而Cem Kaner和Elisabeth Hendrickson发表的一篇论文认为，这样的比例毫无意义。不同的项目里这些角色被赋予的职责和任务相差甚远。举例来说，自动构建负责人应该算作开发人员还是测试人员？
除了计算问题，小组还发现，项目环境的差别使得不同项目的比较更缺乏意义。这些因素包括：
项目要求的可靠性
必须测试的可配置的范围
软件的易测试程度
工具的可用性
测试人员和开发人员的经验
必须坚持的质量标准
在这篇文章It Depends: Deciding on the Correct Ratio of Developers to Testers中，Johanna Rothman得到了类似的结论。Randall Rice在他的这篇文章The Elusive Tester to Developer Ratio中，对这个令人疑惑的比例给出了一些工业上使用的值：
需要清楚地认识到，我并不是完全怀疑在计划中使用这个比例，如果这个比例是你们自己的比例，并且基于你们的经验、技术和组织结构的话就没问题，管理资料
但是如果一个组织把别人的比例拿来，不考虑到技术、流程成熟度、熟练程度的差别，直接用于自己的项目，那我就认为是一个风险。敏捷对测试人员和开发人员的比例有什么影响呢？
在一个近期的网上直播中，Elisabeth Hendrickson和Lisa Crispin都 把敏捷环境描述成“测试的涅”。Elisabeth回忆了她在传统环境中的工作情况，开发小组给QA小组的软件经常是送到时就不能用（D.O.A.）， 不能安装，或者刚启动就崩溃了。而她在敏捷团队中工作时从未发生过这样的事儿。在敏捷团队里，测试人员能够创造更大的价值，他们做探索性测试、创建测试自 动化、与产品负责人紧密合作完善需求和验收条件。
Elisabeth曾见过这样的敏捷团队，运行效率很高，但测试人员对开发人员的 比例很低。这并不是说测试不重要。根据她的经验，敏捷团队需要的测试技能至少要和传统团队一样多。区别在于这些技能、以及保证质量的责任，并不仅仅取决于 称之为测试人员的少数人。整个敏捷团队都在努力提高产品的质量，与之形成对比的是，传统团队只依赖QA小组来给产品测试质量。
你的团队是怎样处理测试的职责的呢？欢迎留言分享你的经验。
查看英文原文The Correct Ratio of Agile Testers to Developers? It Depends.
本文出自：www.infoq.com/cn/news/2009/01/tester-to-developer-ratio
★ 测试人员年终总结
将测试人员整合到敏捷团队中（共2篇）
