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

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

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

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

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

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

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

 

　　让用户来测试你的代码

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

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

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

　　但是你不会问你的客户他们是否测试完毕了，代码是否有效，系统是否稳定安全，负载大的情况下是否正常工作。