那么这样的测试的价值就体现出来了，至少包含了三个方面的要求：
第一他不需要执行测试的人有太深厚的经验，当然还是要一部分的，比如做B超的，那么多人都能胜任。
第二流程比较标准，结果比较稳定。
第三，测试报告对于看的人也不高深，能清楚的反映事实。
说了这么多，我想我的point不在于否认测试人员的技能和经验的重要性，或者要把一些东西僵化。但是我感觉到我们软件测试行业这种被广泛认可的专业性的东西还是太少，不能每次说到我们对比开发或其他软件研发的工种的独特价值就是我们对测试的理解、测试的策略和方法论等等，而应该是一些明确拿得出来的被普遍认可价值的有明确结果的东西。
现实一点软件测试因为被测对象的原因还不太可能做到医学检查那么标准，所以我们花了很多的时间和精力熟悉“人”（我们的被测产品），学习或者发明检测技术，开发仪器设备（测试工具，自动化系统等），一起执行测试，分析报告。
这些都很有价值，没有错，但是有些是对外而言的，对外看的是拿出来的结果，包括别人也可以用到的东西。就好比我们说一个国家航天技术的发达程度和水平，不是看他们有多少有经验的人和知识的积累，而是发射了什么东西出去，有没有人在太空行走。这是倒过来看的，没有人脑子里的那些东西也不会出这样的成果，但是我们对于外界的贡献直接的而言是这些外化的东西，我想软件测试也是一样。
从这一点上，我比较倾向于把知识经验技能外化或者固化到可见可用的工具或者系统上。
我还没有想得太清楚，也许一套稳定高效的自动化测试集对于一个产品就是一个这样的东西，因为它同样满足于上面提到的三个要求。
在曾经做过的一个项目中，这一点让我印象很深。
当时我们将大概一半，约几千个测试用例自动化了，但是由于各种原因，daily build来用的时候总是有部分用例失败，要去确定是用例的问题还是产品的问题需要不少时间，每天这样做也耗不起。后来我们抽取了其中涉及主要功能点的重点用例，约200个左右，花力气弄得比较稳定了。能达到的结果就是，只要有用例fail了，基本都是产品的bug或者一些未知的改动导致的（如果我们不能做到如此凭什么要求产品也稳定?）。这样运行了一段时候后，比较有信心了。我们把这一套自动化的用例集帮助开发人员在他们的环境里面部署起来，作为daily build的验收测试，每天的结果邮件通知大家，不全pass的build不接受做进一步测试。
开始我们想这样会增加开发人员的工作量，估计会比较反感。但是后来我们发现其实并非如此，因为这套测试集比较稳定，能及时的发现问题，开发人员很积极的第一时间去看，而且觉得帮到了他们，因为他们有时也不确定改动有没有问题，反倒很认可这套东西的价值。
对比我这里举的例子，也不难理解，我们大概也很少听到医生讨厌医学检测，因为这些东西确实是在帮助他们发现问题，定位问题，或者至少提供有用的信息。
我想从这个意义上，才能实现开发和测试良好合作，因为双方都为同一个目标贡献有价值的东西。而另一个方面，测试人员要赢得别人发自内心的尊重，一定是因为专业，而不是口头呼吁重视测试。
我想一定还有更多的，更能普遍一点的东西，来自于测试人员能提供出来的，性能测试的一套可以实施的东西算一个吗？安全测试的工具和报告？
都是些不成熟的思考，欢迎大家拍砖。
相关链接：
