原文：Testing with Poor Documentation – T.J.Zelger

        获取正确的信息对于很多公司来说都是挑战，而且即使你获得了所需要的文档，但是缺乏你真正需要的信息。

        我曾经看到过大量的不同质量程度的文档（从优秀的到不可用的），但是我喜欢项目在两个不同的阶段有两种不同的方式组合。 

        一开始，项目使用XP的方式开展，系统从零开始构建，而我作为测试人员就整天与开发人员和项目主管呆在一起。在那段时间，我学到了关于系统的所有东西，包括内部的细节，即使没有什么文档。

        在软件提交给客户后，项目组到了第二阶段，我们从XP转移到更传统的方式，开发人员和BA（业务分析员）写一些粗略的说明书。在初始版本构建完成后，我获得了发布的记录，里面记录了由BA和开发人员写的背景信息。 

        虽然我在后期阶段才介入，但是接下来的阶段都只有很少的特性被加入，所以我仍然能够很好地工作，因为阅读这些发布记录就已经足以让我了解清楚扩展了什么东西，我应该寻找哪些方面的bug。 

        在另外一个项目，我是个开发人员，我们只有少得可怜的文档，但是我们会邀请目标用户每隔六周过来用一整周的时间测试我们的系统。在那段时间里，我们每天都修正bug并且讨论哪些功能特性需要在下个迭代周期加入。那个产品的质量出奇的好，而在那个时候RUP和XP对于我们来说还是个未知的名词。

        在另外一个项目，我一开始就得到很糟糕的文档，还有不可用的发布记录。开发人员工作在另外一个国家。BA和项目主管忙着在全世界推销正在开发的软件，测试人员则努力尝试弄清楚系统要做什么。 

        功能特性在几个分开的邮件中有解释，但是有时候内容是互相矛盾的。 

        在这种没有文档或文档很糟糕的情况下，我通常倾向于请开发人员演示功能特性，而不会强迫他们去写只会包含部分需求信息的糟糕的文档。

        这些项目经验告诉我，与其过分关注需求文档，倒不如让项目组的所有成员都紧密地工作在一起，确保你得到成为所测试系统的领域专家需要的信息。我也同意这种方法可能在航空领域和医疗行业不那么容易生效。