分类： 测试与质量

现在，我依然能碰到一些敏捷开发者和团队，他们在项目中还未采用自动化实践，比如微测试，自动化集成测试和集成测试。这种现象存在主要是因为三种原因：

1.开发者没有看到它的价值

一些开发者技术好经验足，他们很少出错，自动化测试对他们来说是个额外的负担。当一些初级开发者在忙着改bug时，他们往往在做更重要的事，比如把他们的技术应用到系统架构上。如果团队中有这样一批开发者的话是很难实施自动化测试的。 Read more →

敏捷测试人员的十条法则：

提供持续反馈
为客户创造价值
进行面对面的沟通
勇气
简单化
持续改进
响应变化
自我组织
关注人
享受乐趣

提供持续反馈

既然是测试驱动敏捷项目，那么很显然反馈在敏捷团队中占据重要的地位 。

为客户创造价值

敏捷开发就是在较低的版本发布中提供客户目前最迫切需要的功能。这通常意味着限定范围。我们经常在客户团队中遇到较酷功能的需求。任何人都可以质疑这些内容，但是测试人员会判断其对故事的影响，因为他们需要考虑测试后果。

进行面对面的沟通

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

勇气

勇气是极限编程的核心价值，类似测试自动化和持续集成的方式允许团队实践这种价值。 测试人员固守于自己的领域，不与其他业务相关者和技术团队进行任何讨论。虽然你找机会进入了协作的敏捷环境，可能会对找客户索要实例或者找开发人员帮忙自动化测试或者在每日例会时提出一个难题等感到不习惯。

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

简单化

敏捷测试人员和他们的团队面临的挑战不仅是生产最简单的有效软件而且还需要采取简单的方法以确保软件符合客户需求。这并不意味着团队不应该花时间分析主题和故事、思考合适的架构和设计。而是说，当业务部门的需求比较复杂的时候，团队可能需要将方案退回给他们，更简单的解决方案也会产生同样的价值。

简单并不意味着容易。对于测试人员来说，这意味着采用能够找到的最轻量级的工具和技术恰到好处地测试。工具可以简单到只是一张电子表格或者清单。需要自动化回归测试，但是应该把它们分解到最底层以获取快速反馈。甚至简单的冒烟测试也可能满足面向业务的测试自动化。

持续改进

想办法把工作做得更出色是敏捷测试人员应牢记的。

敏捷测试人员和他们的团队总是在寻找工具、技能或者实践以帮助他们增加更多价值或者得到更好的客户投资回报。敏捷开发的短期迭代更易于尝试新事物，以验证是否值得长期采用。

学习新技能和提高专业技能水平对敏捷测试人员非常重要。可利用各种免费的资源提高专业技能。

响应变化

响应变化是敏捷实践的重要价值，但是我们发现这对测试人员来说却是最困难的概念之一。测试人员渴望的是稳定，所以他们会说：“我已经测试过了，任务完成了”。持续的需求变化是测试人员的噩梦。但是，作为一名敏捷测试人员，我们不得不拥抱变化。周三，我们可能期望启动故事A和B，下周五做故事C。但是到了周五，客户重新设定了优先级，现在需要故事A、X和Y。只要我们持续与客户交流，我们就能处理这些变化，因为我们与团队的其他成员保持同步。

自我组织

敏捷测试人员是自组织敏捷团队的组成部分。团队文化贯彻于敏捷测试理念。当开发人员、系统管理员、分析员、数据库专家和客户团队持续关注测试和测试自动化，测试人员就会获得全新的视角。自动化测试很困难，但是当整个团队都在为此努力时就会简单得多。当大家具有多重技能和多层次视角时，任何测试问题都会更容易解决。

当敏捷团队面对一个严重问题时，比如进度障碍或者构建失败，该问题将是所有人的问题。最高优先级的问题需要整个团队解决。团队应该立刻讨论并决定解决的办法和相关参与人员。

关注人

只有优秀的员工出色地工作，项目才会成功。敏捷价值和准则的宗旨是确保个人和团队成功。敏捷团队成员应该有安全感。不必担心因犯错受指责或者失去工作。敏捷团队成员互相尊重并认可个人成就。敏捷团队的所有人应该有机会提高和发展他们的技能。敏捷团队以可持续的步伐前进，使他们能够遵循严格的实践和保持崭新的视角。正如敏捷宣言所说，我们重视个人和合作超过过程和工具。

享受乐趣

在我们看来，测试人员的理想团队是：所有成员协作，从项目的开始一直到结束，利益相关者与开发团队共同工作，整个团队负责质量和测试。相信很多人都认为每个人都应该在工作中找到乐趣。敏捷开发珍视敏捷测试人员对工作的激情。

敏捷测试人员的工作特别令人满意，因为我们的角度和技能对团队产生了真正的价值。

我曾经和来自不同开发机构的人探讨过关于他们如何管理软件开发，如何组织，他们遵循什么样的开发实践，以及什么样的开发实践真正有效。工作在小团队的大部分人都没有人手帮他们测试程序，因为测试人员们不是真正开发软件的人，所以通常觉得他们是多余的。这就意味着程序员许要自己测试他们的软件 – 或者用户来测试。

敏捷团队中的测试人员能做什么？

很少敏捷团队会觉得需要测试人员。测试人员被看作是瀑布时代的产物（需求、设计、编码、测试）。在XP团队，每个人都是程序员，每个程序员都要负责测试自己的代码，写自动的单元测试，使得用户需要的验收测试自动化。Scrum根本没有定义测试要做什么 – 团队会最终找到解决方案，因为他们会检阅自己并调整自己，以获得最佳的实践。

如果程序员已经测试了他们的代码（也通过结队的方式进行了代码审查），那么他们需要测试人员做什么呢？

Janet Gregory和 Lisa Crispin写了一本书来说明敏捷团队中测试人员的作用，它向程序员和测试人员说明测试人员是如何配合敏捷开发的，但这仍然没有改变大多数团队的看法，尤其在“工程驱动的文化”（程序员创立的创业团队）中更是如此。

他们的论点是敏捷团队的步伐相对于测试人员来说太快了，黑盒测试人员们仅仅通过写测试计划，通过手动的测试代码来测试，或许要不断的更新他们的质量中心或Selenium UI回归测试，这些都不可能追得上在短时间内就要发布新功能的团队的进度。如果测试人员不会用Fitness或Cucumber写验收测试，或者没有足够的业务知识帮助填补客户/产品拥有者的空当，不能回答程序员的问题的话，那么他们又有什么优势呢？

这个问题在持续开发中更为显著，一些公司如IMVU和Facebook，使得某种编程实践变得流行起来，他们查看自己的工作，写自动测试用例，查看代码看看测试是否通过了，更新都是很快的，然后自动发布到在线系统中去。

让用户来测试你的代码

一些公司把持续开发看作是“众包”（crowdsource）他们测试的机会 – 让他们的客户来为他们测试。这实际上很有竞争力。然而也很难用这种方法写出可靠安全的软件 – 可能也是不可能的。针对持续发布给用户的系统的质量问题，James Bach有一篇批评的文章，是关于他们花了20分钟时间去测试一个持续部署的程序，就发现在很短的时间内就发现了问题。

有一些持续部署的公司更小心些，他们按照Etsy/Flickr的做法，在晚上上线：持续的发布更新，但是在用户量很大之前就进行了测试，他们还会密切关注结果。

然而，很重要的一点是用户只能测试某些功能，事实上，也只有用户可以测试它们：一个功能是不是有用，一个功能是不是可用的，他们需要什么信息才能正确的完成一个任务，工作流程应该如何优化。这才是对比测试所应该达到的效果 – 通过实验不同的想法，功能和工作流程，收集数据，然后找到用户最喜欢什么，以及他们不喜欢什么。去尝试不同的方法，并获得反馈。

但是你不会问你的客户他们是否测试完毕了，代码是否有效，系统是否稳定安全，负载大的情况下是否正常工作。
你需要从测试团队中获得什么？

就算是最好的，最负责的，最有经验的程序员都会犯错。在我们公司，每个人经验都很丰富，其中有些人工作了10-15年以上了。他们很仔细的测试代码，每次check-in之后都会更新自动测试用例。在持续集成过程中这些测试都会运行 – 我们非常依赖于这些测试（现在已经有成千上万的测试用例了，并有较高的覆盖率），静态分析的缺陷核查，以及安全核查工具来对付基本的代码错误。所有的更改都会让另外一个高级的程序员来核查，从来没有过例外。

但就算有好的方法和工具，优秀的程序员还是会犯错：一些细微的问题（不一致，界面问题，数据转换和建立问题，没有编辑等问题）以及一些基础的问题 （负载下的运行失败，同步问题，缺少需求，规则错误，异常处理中的错误）。我想确保在用户发现错误之前发现大部分（尽管不是全部）的错误。程序员也是。

这也就是测试团队起作用的地方了。我们拥有一个小的，但是经验丰富的，有特别专长的测试团队。一个测试人员专注于验收测试，验证功能需求，可用性，以及业务工作流程。另一个测试人员专注于功能的回归测试以及业务规则的正确性和覆盖率，找到程序员测试用例中的规则漏洞，并在API层让集成测试自动化。还有个测试人员主要做操作测试，压力测试，以及soak test来找到峰值和垃圾回收的问题，破坏测试 – 尽可能的破坏系统。当其中一个人不在的时候，他们也知道如何担负他人的职责，但他们有自己独特的专长和技能，以及自己的解决问题的方法。

当我们初次建立系统的时候，我们有一个更大的测试团队，主要通过写测试计划，详尽的手工测试核查表，在UI层编写自动的回归测试，来测试覆盖率和可靠性。但用这种方法浪费了许多时间。

现在我们更依赖于程序员针对功能覆盖率和回归保护自己编写的自动测试用例。我们的测试团队将精力更多的放在探索性的功能以及操作，基于风险和以用户为中心的测试中去了，以找到最重要的缺陷，发掘系统的弱点。我们都喜欢这种方法，因为我们在测试中找到了真正的重要的缺陷，那些躲得过代码审查和单元测试的缺陷。

当程序员作了更改后，测试人员马上测试更改。他们和程序员一起结队去测试新功能，和程序员一起运行模拟来找出运行错误，竞态条件（race condition）以及现实世界中的时间相关的问题和工作流程问题。他们摧毁系统以确保错误探测和错误恢复机制是成功的。他们测试安全功能，和顾问一起搭建和管理测试。他们也和操作人员一起，和新用户以及新部门处理集成检查。他们和团队的其他人员一起以非常快的速度，每两周就发布到在线系统（有时更频繁）。

测试团队也会负责软件的发布。他们将每个发布都集中在一起，查看依赖，决定发布什么时候进行，什么将会发布，什么不会发布，他们会核对我们是否完成了整个团队同意去做的更改，他们会测试过去的测试用例还有数据转换测试，最后和操作人员一起发布到在线系统中去。

他们没有让整个团队的进度慢下来，他们也没有阻碍我们发布软件。他们确保了软件上线的时候正常工作。

　测试人员找到更多的缺陷

我为高可靠性，高集成性的业务工作了很久，没有测试人员是不可取的 – 犯错的代价太高了。我不认为你可以创建真正的软件，而不需要人来测试它。除非你是在创业的早期，还处于概念的迸发期，或者你只有一个小团队，仅仅为内部使用而写的软件（可能你也没堵到这篇文章），否则你需要人来为你测试系统以确保系统是正常运行的。

不管你如何工作，不管你用什么方法 – 敏捷开发还是瀑布开发方法，都改变不了需要测试人员的事实。如果你推进得太快了，测试人员需要加快步伐，以适应能够获取信息的方式。好的测试人员可以做到的。

我就算再蠢也不会认为测试团队能找到所有的缺陷——虽然这是他们的工作。当然，我希望测试人员会在客户发现之前找到明显的错误。

我需要为他们做的也正好帮自己回答了一些重要的问题：我是否可以发布了？有什么还是粗糙的或者不稳定的或者不完善的？什么需要迟些发布？什么需要更进一步审查或者重写？设计中什么地方很薄弱？什么地方没有自动测试用例？哪里需要更好的测试工具？什么功能难以理解或不一致或者很难搭建？什么消息漏掉了，或者容易误导人的？我们是否做太多了，做太快了？我们是否需要更改设计，代码，还是设计或编码的方式，以使得系统更好用，更可靠？

测试不能提供所有的信息，但能提供一部分。好的测试可以提供许多有用的信息。——James Bach （Satisfice）

没有测试人员，你不仅发布了一些你本来应该没有错误的代码，你也失去了一些重要的信息，譬如你的软件真的那么好吗，例如你可以做什么让它更好。如果你想构建好的软件，那么现在你的机会来了。