测试人员常常抱怨软件需求说明书太过模糊无法测试。你如何确定需求是否开发完善？

其中有一个最大的需求问题是“缺乏测试性”，这很大程度是由于需求不明确、模糊不清。当软件需求说明书不明确时，满足这一需求说明所设计、开发出的软件很可能是不正确的；确认满足不明确需求的代码的测试也很可能是错误的。

即便如此，我认为测试人员对于软件需求说明书的模糊性的抗议还是过多。由于需求不明确而生气的测试人员常常会疏远他们的合作伙伴。他们可能要求分析师重写需求，在他们开始测试反对他们之前。然而，分析师或者没有时间，或者不想重做他或她的工作。这样的结果是项目已经延迟了，所以测试不能再等了。其他人认为测试人员微不足道，但却吹毛求疵；他们浪费了宝贵的时间，却不断重复着一件事。因为测试人员不断抱怨“没有人在意质量”而致使情况更加恶劣。

这种策略不仅是不明智的，而且缺乏可测试性的假设更是错误的。例如，写了数百万的文字试图从国内税收法规中减少模糊性，但实际却使税法变得更难以理解。

更重要的是，清晰性只是形式问题，并不具实质意义。软件需求说明书可以完全清楚，也可以完全错误；对于被忽视的需求来说，清晰性和可测试性都是无关紧要的。只关注可测试性实际上会阻碍发现更重要的是错误，同时忽略需求的实质问题。

不要再浪费时间和精力来抱怨可测试性。相反，试一试这个方法：写下正面与负面的测试，展示你的代码是否按照你所想那样工作，如你说明的那样满足需求。如果你的说明正确，你的测试就已经准备就绪。如果你的说明与开发者的不同，失败测试的具体性质能使大家更容易理解需求问题，从而确定代码或测试应该如何。

与其重写需求，这通常也不会发生，不如使用测试作为一种补充的要求。这非常简单，在敏捷人员以为他们发明了简洁方法之前，简洁方法已经存在很久了。无论如何，它是有效的。你可以通过任何一种方法但非专业术语来使用它。