When Programmers and Testers Collaborate
当测试员和程序员开始合作后会有一些奇妙的事情发生。通过缺陷追踪系统来回发送bug所花费的时间更少。浪费在争论这是一个bug还是一个feature的时间会更少，而更多的时间则用于开发出消费者可期的良好软件。在开始写代码之前的合作将会产生很多机遇。
测试员可以通过使用他们领域的工具语言来帮助业主编写和自动验收测试，例如Fit（框架集成测试）。在开始编程之前这些测试给到程序员，团队就可以实战一把验收测试驱动开发（ATDD）。程序员编写用于测试的基础设施，然后编程让测试通过。这些测试就变成了回归套件的一部分。当这种合作发生后，功能测试可以尽早完成，就有时间在边缘条件或通过更大的工作流下进行探索测试。
我们可以更进一步。作为一个测试员，在程序员开始开发一个新功能前，我可以提供大量的测试想法。当我询问程序员他们是否有任何建议时，他们提供的信息也总能有助于我更好测试覆盖，或者帮助我避免花费大把时间在不必要的测试上。通常，由于测试可以让最初想法清晰化，我们就能阻止缺陷。例如，我曾经的一个项目，我给一个程序员展示Fit测试，预期的结果是一个通配符搜索的响应。而该程序员完全只打算开发关键字搜索。这样在开始编程之前我们就能和客户交流并正确地清楚。通过合作，我们阻止了缺陷，也挽回了大量被浪费掉的时间。
程序员和测试员合作也能成功创建出自动化。他们理解什么是优秀的编程实践，并帮助测试员搭建能够为整个团队工作的强大的自动化测试套件。我曾今看到过由于糟糕的测试设计而导致自动测试失败的项目。这些测试被用了太多次，要么测试员根本没有足够理解如何保持测试的独立性。测试员通常会遇到瓶颈，因此程序员在自动化任务方面与他们合作就很有意义了。和测试员工作以理解什么是清晰的测试，或许通过提供了一种简单的工具，将给予程序员另一种反馈循环，帮助他们获得长期运行的更优秀代码。
当测试员不再认为他们的工作就只是在软件中大断电然后在找出程序员代码里的bug，当程序员不再认为测试员就是“喜欢捕获他们”，合作空间就被打开了。当程序员开始意识到他们有责任构建高质量的代码，代码的可测试性自然而然就是副产品，团队就能更多地自动化回归测试。协同工作的魔法成功开启。
