本篇文章来自《海盗派测试分析MFQ&PPDCS》作者邰晓梅，因原作者博客已经不再维护，现将文章转载记录于此。
Kevin Fjelsted是一个盲人，他曾写了一篇文章《A Brief History of the Accessibility of Computers by Blind People》，收录在《Amplifying Your Effectiveness》一书中。文中从一个盲人的视角描述了几十年来计算机的演进和变化。
我对Kevin所描述的一个小细节很感兴趣：由于看不见，Kevin经常听别人为他描述一些图画或者画面。他发现，绝大部分人描述一幅画的时候，实际上是在描述一些画的特征，比如“画里有三个人”、“这是一副关于房子的画”。人们很少会描述画的细节部分，这就为听者留下了广泛的思考和遐想空间。
当你用文字表述一件事情或一个事务的时候，不论你用多少文字、多么精雕细琢，当让接收者亲自去体验这件事情的时候，比如亲自用眼睛看这幅画、或者亲自动手去实验一下，接收者总是会有新的感受、会发现一些文字之外的东西。这就是一副图画可能胜过万语千言的道理了。
对照我们的测试，写作测试用例的时候，不就是试图用文字向测试执行人员传达测试设计人员的想法吗？从传递者的角度，也许你期望不同的执行人员拿到这个用例，其执行结果都是一样的，希望测试效果受测试执行人员经验的影响降到最低，因此你试图准确而详细地描述每一个步骤。然而你的测试用例是不可能写得事无巨细的，因为不会有那么多的时间允许你这么做（假如你真的有这么多的时间，我倒建议你多做做探索性测试、多想想更有价值的测试内容）；另外一方面，即使真的给你这么多时间写详尽的测试用例，你仍然无法保证囊括每一个与之相关的细节。从接收者的角度，优秀的测试执行人员阅读测试用例，就要像欣赏一幅画一 样，不仅仅靠听－－这样只能接到别人描述的表面特征，更重要的是靠看－－用你的眼睛去观察，去想一想设计人员是怎么想的？设计这个用例的目的是什么？为什么要这样设计用例？我怎样测试才能保证最优的测试效果？和用例相关的部分哪些也值得我关注？哪些是我所知道的重要信息但用例却没有提到？我应该以怎样的顺序执行这些用例为佳？我以大概怎样的进度执行这些用例比较合适？最重要的是靠动手－－用你的心去思考，当你拿到一份待执行的用例，如果上述问题，你通过审视用例，就基本了然于胸，那很好。如果不是这样，比如你对被测特性还不大了解，也没有关系，你可以在执行用例的过程中进一步思考这些问题，通过动手操作，你得到了被测对象的一些最真实的反馈，你对测试用例有了更深刻的认识，你也在随时调整着自己的测试策略。
所以，传统的脚本化测试（Scripted Testing）方法，即先花一段时间设计测试用例、再依据用例去执行的测试方法，不仅仅对测试设计人员有很高的要求（这里体现了大量的创造性的劳动），同时对测试执行人员也提出了相当高的要求：你得通过测试用例尽可能准确猜测出测试设计人员的心思，还得高于测试设计人员，找到测试用例文字以外的被忽略的但同时也是很重要的信息 －－除非你不想得到更好的测试效果。所以测试执行也是体现了大量的创造性思维的劳动。记得昨日在某一ISTQB-FL课程研讨会上，某位讲师讲到了一页胶片，胶片上赫然把测试执行等之后的环节归为“机械式的活动”，而把之前的一系列测试设计活动归为“创造性活动”，如果你的测试执行都是工具在自动化的做，也许这样分类是说得通的吧。
很多组织都过分地看重测试用例，认为测试用例是测试人员最核心的资产，让最优秀的人专职设计测试用例（他们从不或很少做测试执行了），花大量的时间去创建并维护这些用例，这些前端的活动投入非常大。而在最后一段路程，投入反而不那么大了：请一些缺乏经验的测试人员或者干脆雇佣一些对特性不熟的外包人员，依据用例做测试执行即可。当版本发布，用户反馈一些问题后，开始分析这些问题为什么会漏测，准确地说，应该是分析为什么会漏测试设计，因为鲜有人关注测试执行环节能力的提升。人们开始在测试设计阶段运用更多、更复杂的测试设计方法，开始添加更冗长的测试设计流程，开始采用更为详细要求的测试设计模板。。。
我时常听到来自测试设计人员的求助，希望我告诉他们“如何才能提升测试用例的有效性？”“如何确保我设计的用例漏测率最低？” 在他们心中，很有责任感地认为：测试漏测，首先是我没有设计好的缘故。我常常会告诉这些测试设计人员：单单依靠测试用例没有必要也不可能发现大部分的bug，很多bug要依赖执行人员在测试执行阶段发现，这是正常的测试现象－－你不可能要求盲人通过听得来的对一副画的理解和一个正常人通过看对一副画的理解一致；我不建议测试设计人员长期不做测试执行，不建议测试设计和测试执行的分离，如果你的组织还没有办法做到这一点，请你－－测试设计人员－－一定要时常和测试执行人员沟通，向他请教对你的用例的看法，实时收到反馈信息，调整你的设计；过分重视测试设计而忽视测试执行，就如同“行百里者半九十”一样，最终的测试效果很可能会输在“测试的最后一公里”上。
探索性测试也许就是看中了人在测试中发挥的作用要大于文档在测试中发挥的作用这一点吧。