你需要从测试团队中获得什么？

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

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

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

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

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

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

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

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

　　测试人员找到更多的缺陷

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

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

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

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

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

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