一些SCRUM的帖子

我和敏捷团队的五个约定

我——作为一名测试人员——有一个与众不同的习惯：每当要加入一个新项目的时候，我总会找到项目中的同伴，真诚而亲切地说：
“为了更好地合作，我有5个约定，希望大家能尽量遵守”。

约定1. 业务分析师们，我们其实是同一个角色的两种面孔，请叫上我们参加客户需求会议

约定2. 开发人员们，虽然你们是编写自动化测试的专家，但请听听我们意见

约定3. 项目经理们，请不要要求我们测试软件的所有路径

约定4. 迭代经理们，如果对于交付风险有任何疑问，请来询问我

约定5. 测试人员们，那些敏捷实践对于我们也是有用的。

敏捷团队测试人员和开发人员的比例

软件开发世界里有这样一个长期存在的问题是：测试人员和开发人员的比例多少才合理？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小组来给产品测试质量。

你的团队是怎样处理测试的职责的呢？欢迎留言分享你的经验啊。


将测试人员整合到敏捷团队中

将测试人员整合到敏捷团队中，这是敏捷之道常常重复的一条箴言，可我们并没有认真想过这到底意味着什么或者应该怎么做。

团队中测试人员的角色具体负责什么呢？他们要：

• 协助团队抽取并定义验收条件（或需求）
• 提供相关质量信息，而不是通过自动化测试、探索性测试（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的时间反而少了。

热衷敏捷测试的十大理由

最近，Kay Johansen 提出问题“为什么你会热衷于敏捷测试？”收到的答案从严肃到诙谐，不一而足。

1. 不再需要手工测试脚本！ － 相反，自动运行的脚本让测试人员有更多的时间来挖掘测试。

2. 开发人员喜欢我了！ － 迭代结束之前发现问题，而且因为开发人员对代码还有一个比较清晰的印象，所以比较易于找到问题。

3. 现在我可以在撰写特性之前就分解特性！（Kay 与 Philip） － 在撰写特性之前开始测试，测试人员可以预防问题。

4. 自动化测试在一天之内运行很多次 － 任何修改都能得到快速反馈。

5. 营造团队导向的氛围 －（John Overbaugh）－ 每位团队成员不仅关心编码，也会关心测试是否完成（Lisa Crispin）

6. 测试人员可以解决偶发性bug（Lisa Crispin）－ 自动化的测试让每个人都舒服。

7. 经常复审测试实践的机会（Adam Knight）－ 不再是对过去行为的简单重复，实践经常会被复审。在 Adam 的例子里面，过去要5天完成的手工测试减少到只需要30分钟。

8. 我只花很少、很少的时间来调试（Adrian Howard）－ 当我犯了错，我能很快得到反馈 － 所以轻而易举就找到问题，然后解决。

9. 真正改进质量，而不是仅仅记录在文档上（John Overbaugh）－ bug很快就被解决，而不是只放在bug表里面。

10. 因为测试先行，测试的时间总是有的 － Josue Barbosa dos Santos 讲述了在巴西的一个政府办公室工作的故事，那里测试被安排在项目的最后阶段。开发工作总是落后于项目时间表，面临截止期限的项目不测试就发布给用户。引入 TDD和ATDD之后，最少有一部分测试会随着软件开发同步进行。

Kay热衷敏捷测试的首要原因是：我想听到人们说“这是我迄今为止工作过的最好项目！”

敏捷测试之我见

前两天听了公司一个关于敏捷开发的培训，就在想是不是也有敏捷测试。尽管一个同事说根本没有敏捷测试这个概念，但我仍不死心。Google了一下，这方面的文章确实有限，不过有就是对自己想法的一个最好肯定。

　　在我的理解对应敏捷开发的管理就是敏捷管理，同样对应敏捷开发的测试即是敏捷测试。只是敏 捷管理和敏捷测试同样可以应用到非敏捷开发的项目中去。同样敏捷管理和敏捷测试在敏捷开发中将会得到最大的体现，但能不能管理好和测试好就看你做的是不是 真正的敏捷管理和敏捷测试，看你是不是真正的将敏捷的思想融入到管理与测试中去了。

　　敏捷开发强调的是敏捷设计，设计的灵活性、可扩展性和易维护性是敏捷设计的目标。而之所以要有这样的目标就是为了适应多变化的需求，而敏捷开发中高度的迭代正是及早发现问题，及时修正并完善需求的有效方法。

　　那么敏捷测试的核心是什么呢，就是在设计阶段之前充分学习该项目的行业知识，从最终用户角 度和实际出发充分的挖掘需求。在设计阶段要完成对敏捷设计的灵活性、可扩展性和易维护性的检查，这个工作最好由公司内部的其他结构师来完成，开发人员和测 试人员列席并给出意见。在敏捷开发的高度迭代过程中，测试人员首先要从整个项目全局考虑，及早发现需要更改设计的问题，但时间上不能花太久，其实这个测试 更多的是去看、去思考，而能不能发现问题就要看你对现有需求吃的是不是透彻，对整个项目是否有一个全局的把握，是否从最终用户角度去考虑问题，是否以实现 客户的商业价值为目标;然后在最短时间内完成所有功能和业务逻辑的测试，最好是每人分配不同的功能和业务逻辑进行测试，这样就可以在最短时间内及时将优先级较高的bug及时反馈给开发人员;最后在开发人员忙于修改那些优先级较高，难度较大比较耗时的bug时测试人员可以有充分的时间来对这一迭代进行较细致的测试，发现功能和业务逻辑中不易察觉的问题，次要功能问题、验证、界面等等问题。

　　关于敏捷测试的测试用例问题。很多人觉得测试用例没有用，其实那是因为测试用例只是又书写 了一遍需求，这样的用例当然没有用。对于敏捷测试，在写测试用例时我们必须要花很短的时间写出高质量的测试用例。在我认为敏捷的测试用例就是以简洁的语言 写出所有测试点，甚至可以不要期望结果，因为很多期望结果要么能在需求中找到，要么对于一个有一年以上测试经验的测试人员来说已成竹在胸。如果为了严谨， 可简单写明结果，如果没时间可在后期敏捷测试过程中工作量不饱满时补上也未尝不可。同时敏捷测试用例必须在敏捷测试过程中不断得到更新，在我们测试过程 中、思考过程中完成测试用例的更新，因为敏捷测试用例简洁的特点不会花太多时间。

　　当然对于测试人员与开发人员的沟通问题也非常重要，如果测试人员觉得自己提出的bug别人可能会有疑义或者别人不仔细研读并不能直观地理解其意，那么最好在这个bug后面写明自己的想法，开发人员在处理测试人员提交的bug时同样如此，对于有不同看法的bug一 定要加上注释说明原委。在此基础上再进行沟通，我想剩下的问题不会太多，不会耽误双方太多时间，这样得沟通更易于让人接受、效率更高。测试人员之间的沟通 与交流同样重要，每个测试人员对需求可能都有不同的理解，沟通可以使他们对需求的理解更趋于一直，更高效的发现问题。测试人员间相互查看对方提交的bug，同样是一种更有效的沟通和交流方式，可以发现别人看问题的不同角度，从而取长补短共同进步。总之在不影响别人工作的情况下尽可能与其他人做充分的沟通也是敏捷测试中的重要部分。

　　敏捷测试的管理同样是一个非常重要的部分，有时间整理一下再做补充。

　　对于敏捷测试必须有一个非常良好的环境，这个环境能够让测试人员有非常活跃的头脑，良好的心态，能够非常自由的去思考，愿意去思考。其实很简单就是如果能让每个测试人员下班的时候都是开开心心的回家，那么这个环境就是最好的环境。

　　关于敏捷测试的一个不成熟的定义：一种面临迅速变化的需求和频繁迭代，迅速制定出与当前迭代高度适应的测试策略，快速做好测试准备并执行测试，尽早的发现优先级较高的bug、在有限的时间内完成覆盖率较高、测试较充分的测试。