作者认为这是最具争议的项目, 他认为这是一个神话: "测试人员只需要一点, 或是没有程序撰写的知识". 这是行不通的, 可是很不幸的, 这是目前一般常见的状况. 这里作者提出两个主要原因

(1) 测试人员是在测试软件程序, 没有程序设计的知识, 他们无法洞察bugs真正的原因, 找出最可能发生问题的地方. 测试通常没有足够的时间, 去达到真正测试的"完整", 所以软件测试是需要在现有资源和彻底性之间做出某种妥协. 测试人员要如何优化有限的资源, 针对最可能发生问题的地方做测试呢? 如果他没有程序设计的知识, 他不可能有正确的直觉, 去知道要去哪里找到这些地方

(2) 所有最简单的测试方法都是tool- and technology-intensive. 基本上, 这些工具都是需要程序撰写或设计的知识, 才知道怎样用的好. 同理, testing techniques也是一样. 若是你没这些知识, 你可能只能用一些ad hoc的testing techniques和最简单的工具

此外作者还认为找entry level的程序设计人员来当测试人员, 这并不是好的主意. 原因如下:
(1) 失败者的形象 (Loser Image)
Entry-level的人会期待得到一个开发人员的工作, 如果他们不能找到这样的职位, 他们会觉得是一种失败. 这种情况在测试团队会更明显

(2) 开发人员对你没有信任感 (Credibility With Programmers)
测试人员所面对的开发人员往往比他们资深很多, 除非他们之前所学的东西十分扎实, 否则他们所会的东西, 在开发人员面前会只是玩具而已. 因此他们没有什么公信力, 去提供开发人员什么有用的信息.

(3) 测试人员不懂诀窍(Just Plain Know-How)
基本上, 这些测试人员不懂程序实际上怎么撰写, 那是开发人员的本业. 如果你是开发人员, 资深的人还会去带刚入门的人怎么做. 若是你是测试人员, 你只会去学 doing a build, configuration control, procedures, process等等. 都是在学习怎么做, 而不是真正去做它. 所以无法真正懂得那些诀窍