在敏捷团队中，测试专家Lisa和Janet认为测试承担两种职责：支持团队（Supporting Team）和挑战产品（Critique Product）。从支持团队的角度，测试可以视作一种开发活动。一些敏捷团队使用用户故事（User Story）来组织开发。在编写产品代码之前，程序员或测试员会和用户协作，一起定义该故事的用户验收测试（User Acceptance Test）。他们通过编写测试来实现“用户协作”：挖掘需求，确定细节，建立共识。在故事开发过程中，持续集成会频繁的运行各种测试用例集，来检查最新的签入（check-in）没有破坏对产品的约定。对于任何故事，只有所有的单元测试、功能测试和用户验收测试全部通过，它的开发才算完结，才能被标记为完成（Done）。由此可见，测试至少在如下方面渗入到软件开发的全过程。

　　1、与用户协作编写用户验收测试。它们作为可执行的规格说明，精确地描述了对产品的期望。

　　2、开发者编写单元测试完以成单元设计，开发者编写功能测试以完成代码集成。

　　3、持续集成的测试通过率提供了开发状态的重要信息。

　　4、用户验收测试的通过率提供了开发进度的重要信息。

　　测试仍旧是“反馈信息”。但是对于一个有进取心的团队，它所提供的信息也是推动产品研发、监控开发流程、优化开发过程（优质的开发过程会缓慢但长远地提高产品质量）的动力之一。

　　对于大多数测试者，测试的主体仍旧是“挑战产品”并汇报在该过程中收集的信息。不过，测试专家们鼓励我们用全新的视角考察测试。Chris

　　McMahon在《测试之美》中提出了一个崭新的、极富启发性的隐喻：软件是依赖于人的艺术品，测试者是“审稿人”。

　　Good software testers supply critical information about value to people who care about that value, in a role similar to that of a book reviewer or a movie critic.

　　好的软件测试人员会向重视软件价值的人提供有关于价值的关键信息，他的职责类似于书籍审稿人或电影评论家。

　　Great software testers make aesthetic judgments about the suitability of entire approaches to software development itself.

　　伟大的软件测试人员对于全体软件开发方法的适当性做出美学的判断。

　　“审稿人”隐喻带给软件测试全新的视角：不仅发现错误，而且驱动软件向更好的方向发展。审稿人也是“反馈信息”，她不会代替作者去写作，但是她会对文章主题、篇章结构、论述逻辑、研究方法、实验结果、引用文献等提出深刻的、富有洞察力的问题。要回答或解决这些问题，作者必须通盘考虑整篇文章，从架构到细节都作出深思熟虑的改进或重组。一个好的审稿人能够推动作品向更高层面发展。