你对敏捷项目报告是怎样看的？我知道Janet Gregory有一个“轻量级”的测试计划，但我却没有发现轻量级的报告。你认为传统的报告是否应该在项目结束时写？其它的测试结果你要怎样报告？

在敏捷项目中，我们一直在与客户协作。在开发之前或开发当中，我们与他们一起讨论用户案例，当一个案例或迭代完成后，我们会向他们展示一个样例。我们的案例板上—物理也好，在线也好—显示了案例的进展如何，以及测试活动。

当我进行瀑布项目工作时，我会提供一个关于所有功能信息的“执行摘要”，帮助业务经理决定是否发布软件。在敏捷中，我只是讨论一下功能即可，然后决定是否能过演讲来发布。即使在大型的企业中，也必须有产品经理与开发团队一起工作。他们应该面对面地沟通，无论是私下，还是会上都可以。

我认为没有地必要在项目的结束后写测试报告。如果我有关于质量和流程方面的问题，我会在产品回顾时提出。整个团队—包括产品所有者、产品经理或代表业务的简单角色—讨论问题。作为一个团队，在试图解决这些总理府时，我们进行一些小型实验。

最重要的信息来自于案例板、kanban或其它大型的、可视化图表（在线的，物理的），那些团队用来保证开发对业务透明性的工具。这包括测试，它并不一项独立的活动，而是开发团队不可分割的一部分。

在长期内取得成功的项目，向用户交付他们时常需要的业务价值，但是却可持续的速度。他们开始测试每一个功能，通过从客户期望与不期望的行为中获得样例，然后把这些样例转变成测试，指导开发单元，以及功能性和非功能性的等级。

当测试通过，未来代码完成后，那些测试就变成了不需要回归的检查了，但即留下关于系统如何工作的文档。与其把精力投入在测试的陈述式报告上，不如把工作重点放在让每一个都理解的自动化测试上，这些人需要知道系统的工作方式，以及测试内容。