下一个问题是“那我们还需要测试人员吗？”恕我直言，--需要！！！为什么？因为测试实践人员所想的与团队里的任何人都不一样。测试人员是“专业的悲观主义者”（ISTQB基础教学大纲）。好的测试人员会花费时间关注潜在的问题，而非潜在的解决方案。从一开始我们就考虑坏的消息——到底哪里会发生严重的问题，如何快速定位问题，甚至如何去阻止问题发生。这和敏捷概念中的“快速失败”和尽早理解风险这两点完美切合。我们需要这样的思想观念尽早地参与到项目和解决方案设计中，从而让我们能够尽快并尽可能多地发现潜在障碍。 真正拥有足够多的测试知识，能够准确计划测试工作的人并不多，而敏捷团队中需要关注的哪里和何时需要测试的东西又太多。在用户故事等级测试，迭代等级测试和特性等级测试之间应该有个明确的界限；还记得之前讨论过的“完成”的等级吗？由谁，在哪里，何时完成哪一部分测试都需要明确地确定出来，以保证所有的环境、工具、技术、数据和人员在执行时的有效性。测试（就像大部分事情一样）在好的团队中并不是偶然发生的……好的测试会做优秀的计划。优秀的测试需要杰出的计划。在该计划中，需要紧密地考虑测试人员和测试以保证所有相应的安排都建立到位。 你是否会问：“那测试人员如何做到这些呢？”大部分人认为测试只是测试执行，但是在现实世界中，你所看到的那小部分测试是测试中最简单的。执行测试用例花费了总体测试工作大约25%的时间。大部分测试是在思想和文档中完成的。“天哪！”……你被震惊了……敏捷不是说了吗：“可工作的软件胜过面面俱到的文档”！没错！但是测试可以在任何或全部文档中发生（故事实例、白板设计、验收标准等）。第一个也是最大的一个障碍是，人们或整个团队不愿意定义什么是“很好地、价值、完成”，或者由于太难而不愿将它们细化。 多样的团队允许我们掌握每个方面最好的那一部分。特意排除某组技能或某组知识是幼稚的，非常不成熟的行为，且不能提高解决方案或方法的长期性。一个完整的并且拥有能够在最好的可能时间以最优惠的可能价格交付最好的可能解决方案所需要的所有技能的团队，才是完全聪明的、优秀的业务团队。认识到团队中其他人的技能，并将它们最大化发挥出来也是聪明的举动。 那测试人员需要有自己特有的团队吗？不需要……敏捷项目中的任何人都可以成为测试人员，事实上，敏捷项目中的所有人都是测试执行者。主要问题是，团队中的所有人都需要遵守纪律，为了完成必须的所有测试活动（不单单是测试执行）他们需要在日常工作中时刻做到“测试先行”。如果团队没有在他们的工作产品、方法和解决方案中花费时间或精力计划、设计并应用测试，那团队将无法知晓他们的进程以及他们所面临的问题。 因此我能留下的建议是： 确保整个团队对每个层次“完成”的定义有个明确且一致的理解——自己的任务、用户故事、迭代、发布、项目和产品 确保整个团队对这个产品的“质量”概念有个明确且一致的理解——是什么构成了“可工作的软件” 测试并不只是敲击键盘以期找到缺陷，也不仅仅是执行单元测试 测试是整个团队的责任，应该从第一个概念的讨论开始，并涵盖敏捷项目中的所有方面 尽早测试，并且经常测试——等到所有工作完成之后才开始想到测试是错误的 静态测试（检查每一块工作以确保其达到质量要求）比执行测试用例更有价值 设计好的测试是个专业活动，敏捷团队中任何人都可以做到，但是需要一个正确的理念 测试在敏捷中是否灭绝了呢？是的，但那是传统的，过时的，生命周期测试末期的测试。新的，完整的，预先的，积极参与的，挑战思想模式的，挑战现状的，并允许团队交付…交付价值，交付 “可工作的软件”，交付客户真正想要的解决方案的测试将会永存。 本文转载自：http://www.infoq.com/cn/articles/why-testing-matters-agile |
