在我们团队中, 我常听到一种抱怨, 就是design spec写的很差, 或者是很晚才拿到它们. 这是因为在微软中, PM是负责撰写详细的spec, RD则是来实作它们, 而tester则是用它来开立测试个案. 因此你可以想象在这种模式下, 如果spec没有产生, tester会非常惨, 因为他扪根本无法知道feature在做些什么.
 
不要误会我的意思, 即使是一个agile的团队 它们也需要设计文件来告诉他们一些事情, 可以经由mail, 白板, 或是走廊上的谈话等方式来得到. 但是若是tester被锁定, 若是没有spec就无法做事, 这将会是一个非常不好的QA 文化.

在此我有两个问题:

The belief that a full blown specification is required to successfully test a product. 
The belief that a specification is something that happens externally from QA.

对于第一个问题, 我认为这是一个好的tester需要具备的技能. 如果你没有书面的spec你要怎么办呢? 其实你还有source code, 你还知道feature要解决的客户的问题是什么. 此外, 你可以找团队中其他成员(Dev, QA, PM, UE)来讨论. 因此, 你所需要的是把你自己变成客户, 从客户的角度来想问题, 来看看这个东西是否满足你的期望, 如果没有, 则提出问题来. 如果有太难使用的问题, 那也把它提出来.

所以关键是, 你必须和你的团队常常讨论. 看看是否有任何功能你不知道的, 还是说有任何地方是有一些known issue存在的, 你会觉得这些事情还好吗? 还是其实是很不满意的. 这就是我为什么喜欢exploratory testing的原因, 因为它需要随时不断调整, 来查看什么地方还有问题.

第二个问题我相信是跟文化有关. 当QA开始等待或是要求spec一定要写, 他们才能做事, 这时候表示他们内心想回到waterfall的工作模式. 这是非常微妙的, 他们会说: "看, 参与设计不是我的事情, 你应该告诉我妳打算把程序设计成怎样, 好让我跟你讲要怎么测试. 不要遗漏任何细节, 否则我会漏掉一些测试的scenarios". 可是一个好的QA, 他应该不是这样的. 他应该也要加入design, 提供他所遇到的问题和想法, 以及知道什么东西被实作.

所以当我听到有QA说没有spec就无法测试, 我会把它当成是一种警讯, 代表我们开发软件的方式, 某些地方需要做些修改.