测试需要思考者吗？(一)

我想所有的读者都会说：那肯定需要啊。无可否认，每个人都有自己的特点和特长，有的人很擅长细节的操作，有的人擅长系统地思考。一个团队需要大量擅长细节操作的人，如果没有擅长系统思考的人，也不会影响正常的工作。但是团队要想提高资源的利用率，提升工作的质量，那么一定是需要有少量擅长系统思考的人。其实我们仔细回味周边成功的企业都是有着擅长系统思考的人，例如：马云，史玉柱等。如果我们把测试团队看成是一个作战团队，那么擅长细节操作的人就是优秀的神枪手，单兵能力很强。测试经理应该是一个很好的组织者，组织好多个神枪手的分工配合，有好的战术来准备进行一场恶战。但是如果这个作战团队有一个擅长系统思考的人，那么他能从战略上帮助这个团队事半功倍，不用完全去苦战。甚至还能启发神枪手选择最佳的射击位置，更好的保护自己。

几年前，一位90年就在美国SUN开始做测试的测试总监，和我分享他的团队中成员的组合：80％的人是操作高手，20％是思考型。虽然细节没有和我说了，但是坚定了我在测试团队中一定要保留位置给那些思考型的员工，并给他机会锻炼系统性思考的能力，让他来做规划，更系统正确地指明下一步工作的内容，然后操作高手来实施。需求强调的是，操作高手的待遇可比思考型员工高，工作没有完全的高低贵贱之分，只是分工不同。有的人使用工具，搭建环境，编写代码效率很高，是非常好的神枪手，可是让他站在更高层面来规划系统性的工作，确实就没有那些思考型员工做得更好。我举一个简单的例子吧：我们有一个目标，要为公司找到能提前发现大量内存泄露的测试方法，降低研发成本。一位典型的操作型员工，他会去网上找一个内存泄露检查的工具，然后试用一段时间后，告诉我：找到方法了，使用这个工具就可以发现内存泄露问题。他很快地做出了：工作成果。为组织创造了价值，这是值得肯定的。但一个典型的思考型员工，他会怎么做呢？他会先思考：为什么内存泄露的问题之前很难被发现，然后去找相关同事调查，调查出原因：A，B，C。这时才开始上网寻找相关的解决方法，或许问题A可以通过编程规范的来解决大部分现象，问题B可以通过静态检视工具来解决，问题C需要使用内存泄露工具来解决。Ok，这时他与操作型员工一样找到同样的工具。思考型员工除了试用摸索工具的使用方式外，还研究该工具查找内存泄露问题的原理，输出原理文档，分析了工具工作原理对于后续分析工具的测试结果是非常有用，对规避工具的缺陷有非常强的指导意义。

最后，系统思考型员工给了我一份这样的材料《内存泄露早期发现解决方案》，其方案架构包含：需解决的问题列表；每个问题的子解决方案；每个子解决方案的解决思路和工具列表；工具原理分析（正确选取该工具合理科学依据）；工具测试结果分析的高效方法；测试工具常见故障规避方法；后续研究工作计划；

另一位操作型员工给我的材料却是《XX内存泄露工具使用手册》，里面只包含他从互联网上找到的该测试工具的配置方法和运行命令。

 如果你是我，如果你站在研发总裁的角度来选择，你会选择哪种员工来做技术研究？51Testing软件测试网J-i ? eP|]Nj.G%U

 上面是微观层面需求系统思考型测试员工的缘由。我再强调一遍：我没有看不起操作型员工的观点，当《内存泄露早期发现解决方案》发布后，我们需求大量的操作型员工来把该方案的效果发挥出来，在一线快速高效地找到大量的内存泄露的问题。选择系统思考型员工来做该项技术研究，是因为他输出的成果：解决方案选取的方向更高效，文档具有更高的可用性，能大量节省其他同事在解决问题时的时间，减少遇到问题时的分析时间。我想其他操作型员工也会更愿意使用这位思考型员工的输出成果。51Testing软件测试网$[V
Zoqx