经营成功的测试职业生涯

经营成功的测试职业生涯

                                                                                                                 --James A. Whittaker

你是如何开始作测试工做的？ 

       1989年，我在田纳西大学读研究生的时候，完成了从软件开发人员到软件测试人员的转型。而这一转型并不是出于我本身的选择。我命运的改变发生在一个早晨，个人教授质问我为何缺席那么多开发会议。我解释说由于会议被安排在星期六早上，很不方便。

       而怍为一个平生第一次离开家的新入校的研究生，这个时间段有些麻烦。十分有意思的是，等待个人惩罚并非一纸解聘通知书，而是被判罚为该小组的惟一一个测试人员，且不能与开发团队有任何交流。

       对于个人职业生涯来讲，这是一个意义多么重大的决定啊！正是这个决定最终成就了几十篇关于测试的论文，构建了多得连我本身也记不清的各类工具，出版了五本书，带来了无尽的快乐工做时间。测试一直就是我拥有的那份具备创造性和技术挑战性的快乐职业。不过，并非全部人都喜欢这样。能够说我最先接触测试是在攻读研究生期问，不能否认，那时的高强度学习和工做确实让我受益不浅。另外，我认为从初学者阶段到专家阶段之间存在着一个“测试的山峰”，人们须要经过一系列我的辅导、获取信息和接受常规指导来翻越山峰。成为一个测试初学者是很容易的，成为职业的测试人员也并不艰难。本章的重点正是讨论如何翻越那座位于职业测试人员和测试专家之间的山峰。

回到将来

     在软件测试领域，时间彷佛已经停滞了。咱们在21世纪作事的方法与上个世纪几乎彻底相同。Bill Hetzel在1972年出版的测试知识丛书至今仍然至关有价值。而我本身所写，于2002年首次出版的How to Break Software系列，到今天仍被做为实用软件测试技术主要资源的代名词。

      确实，若是咱们能够把20世纪70年代的测试人员转换时空用在今日，我猜测他们的的技巧足够应付现代软件的测试。固然，他们须要学习网络和各类网络协议，可是他们拥有的实际测试技术将能获得很好的应用。若是从20世纪90年代找一个测试人员，则不几乎不须要任何训练。

       对于开发人员来讲，却不是这样，他们所掌握的那些上世纪的技巧几乎已经彻底过期。让一个有一段时间不写代码的人从新开始编程，看看会有什么样的反应。让我感到很不安的是，咱们能够从马路上直接雇用人手，而雇来的这些人从第一天起就可以测试，就可以有收获。事情真的有那么简单吗？或者是咱们的指望值只有那么低？让我更加不安的是，咱们没有任何可预测的方式将合适的测试人才从胜任工做状态训练为测试专家。测试真的就那么困难吗？

     这又是那个山峰了。门槛很低，但通往精通的道路却很艰难。

      在通往测试山峰的入口，咱们倚仗的是这样一个事实：测试的不少方面都很容易掌握。大多数人均可以学得有模有样。甚至只要将一点点常识应用于输入的选择,就能够找出缺陷。这个层次的测试就如同在桶里钓鱼，简单到足以让任何人都认为本身很聪明。然而过了入口之后，道路迅速陡峭起来，而测试知识变得愈来愈晦涩难懂。咱们发现有人擅长于此，咱们称这些人为“有天赋的人”，并欣赏他们的本能。

       难道必定要依靠本能么？对于那些看起来不具有特长的人们，是否存在着一条翻越山峰的途径？是否能够用某种方法传授测试技能以培养出更多的专家呢？为认为这座山峰是能够通行的，而这一章正是我关于应该如何走这条路的笔记，你能够在本身的职业生涯中加以应用。这并非一份食谱配方，一份职业生涯烹调书。不过你能够作一些事情来加速你的职业成长。可是，正如你可能已经猜到的，真正是说来容易，作起来难。

上山

       测试职业的早期阶段主要是为征服测试山峰的漫长攀登作准备。我所能给出的最好的建议是从两个方面来思考问题。对于你参与的每个项目，都有两部分（不必定相等）的任务。第一部分的任务是保证当前的测试项目得到成功。而第二部分的任务是学习你应该作些什么以便使下一个测试项目更加容易。我把它称为“测试今天的项目，准备明天的项目”。若是你作每个项目把它都分割成为上述的两半，那么几乎能够保证你能持续得到进步。这样，你就能够随着每个参与的项目逐渐成长为更优秀的测试人员。

       如今就让咱们来关注第二部分的任务------为下一个项目作准备。咱们须要注意三个概念：重复、技术和漏洞。

 

重复

         作任何一件事，毫不要重复两次而不意识到或质疑这实际上是个问题。我但愿全部年轻的测试人员都牢记这一点。我见过不少初学者，他们在单调的任务上浪费了太多的时间，好比，设置测试机器，配置测试环境，在实验室里安装待测试的应用程序，选择一个产品版原本测试-这些任务列表能够变得很长，最后你会发现真正花在 测试软件上的时间少得可怜。

       这是许多新手常犯的错误。他们没能看到他们日复一日所作的工做的重复本质，而当他们意识到这种重复时，几个小时已通过去了，而在这几个小时内他们没有作任何实际的测试工做。关注这些重复劳动，而且留意由此形成的真正的软件测试工做时间的流逝。为了能翻过测试的山峰，必须作一个测试人员应该作的工做，而不是实验室管理员或者测试机管理员的工做。

       测试自动化是解决重复劳动的方案，也是本章稍后的主题。

技术

       测试人员经常会对软件失效进行分析。分析缺陷时，咱们从开发人员的失败中学习如何编写可靠的代码。咱们也分析那些被咱们忽略的缺陷。在应用程序上市之后，客户就会开始报告缺陷，咱们将要面对处理一大堆失效的情形并寻找其中的重要缺陷。用户报告的每个缺陷都说明咱们的流程有问题，咱们的测试知识还不够完善。

       可是分析咱们的成功也一样重要，而许多新入职的测试人员却没能利用这个唾手可得的资源。咱们在测试中找到的每个缺陷都说明咱们的的测试流程正在有效工做，都是一次成功。咱们须要牢牢抓住这种绝好的机会，只有这样才能使成功不断的重复下去。

       运动队经常这样作，他们会观看比赛录像，并分析每个动做为何奏效或者为何不奏效。我清楚地记得一个小故事，个人一个朋友拍下了我儿子踢足球的一些照片。其中一张照片记录了他踢球的瞬间，那个球超过对方守门员成功进球了。当我把它给我儿子看时，我指出他站立的那条腿的姿式很是完美，他踢球时脚尖紧绷且击球点在鞋带间恰到好处的位置。他盯着那张照片很长时间，从那之后他不多用不正确的姿式踢球。他那次得分可能只是碰巧作对了，但今后之后他有意识的运用这些技术使之接近完美。

      如今回到新手测试人员的课程上来。咱们每个人都会有得意的时刻。咱们找到重要的漏洞或发现优先级很高的缺陷，并为此雀跃不已。不过先花点时间考虑一下总体情况。咱们使用什么技术找到了那个缺陷？咱们是否能够建立一种方法来找到更多这类缺陷？咱们是否能够记住这些实际的测试经验并不断地加以应用来帮助提升咱们的工做效率？软件的哪些症状能够提示咱们它具备缺陷？咱们未来可否从那些症状中获得更多的警示？换句话说，这不只仅是一个缺陷或是一次成功，这个缺陷教会了咱们什么，是否使得咱们未来成为更好的测试人员正如我儿子的进球同样，尽管第一个缺陷是偶然间发现的，但它不表明其他的成功都是偶然。理解咱们成功的缘由很重要，只有这样作，成功才能被复制。对于测试人员来讲，这种保证成功的缘由就是一系列的测试技术、建议和工具，它们能够提升咱们在将来项目中的工做效率。

漏洞

         测试人员最终都会变得很擅长寻找缺陷，可是要翻过测试的高峰，咱们必须更快而且更有效率：高速低阻。换句话说，咱们必须拥有一种自己不含缺陷的缺陷查找技术！

     我喜欢这样来考虑问题：测试人员检视本身的工做时也须要发挥那种寻找缺陷的能力。咱们必须使用跟寻找产品缺陷同样的流程来寻找咱们本身的测试流程，测试过程当中的缺陷。个人测试流程是否是有问题？这里面是否有缺陷？这里是否存在着妨碍我提升效率的障碍？

     你必须一直寻找更好的方法。有意识地去肯定那些限制能力、阻碍前进、减缓速度的东西。就像缺陷限制了软件知足用户需求的能力同样，是什么限制了测试的能力？使用你拥有的测试能力来最优化本身的测试流程，这会帮助你在测试的山峰上快速攀登并增长你翻越山峰后成为专家的机会。

    测试山峰的巅峰处是一个美好的地方。若是你成功地到了那里，恭喜你．但这并非最终日标。这表示你已经成为一个杰出的测试人员。而此时的下坡路就是用你的洞察力和专家知识来帮助周围的人也成为优秀的测试人员。本身一我的登顶是一回事，帮助其余人（那些能力不如你的人）登顶却彻底是另一回事。

     通常来讲，那些成功登上测试巅峰的人会成为使用工具的大师。那些商业工具、开源免费工具,和本身写的工具（我我的最喜欢的工具）是极好地提升工做产出、 增长工做成效的方法。不过，工具只是实现该目标的一种方法，但在许多方面它反而是一种限制，由于太多的人看不到工具的功能以外的东西。他们被限制在工具能为他们所作的事情中，没能看到或理解对工具还有更多的需求。登顶须要真正掌握的是“信息”。由于不少工具能处理信息，并使得信息的获取更加容易，因此测试人员变得过于依赖于他们的工具。可是信息自己以及如何利用这些信息才是真正的成功关键。

       熟练掌握信息，指理解有哪些信息，这些信息将如何影响测试，保证最大限度地利用这些影响。有几类信息是测试登顶者必须关注的。这里我要谈的是其中两种：来自应用程序的信息和来自以前测试的信息。

 

     来自应用程序的信息包括需求、体系结构、代码结构、源代码……甚至是关于应用程序在执行时作了哪些事情的运行信息。在编写和执行测试用例时，须要考虑这类信息，但信息的多寡在很大程度上取决于测试人员的能力，这是一种可以使测试更高效的能力。在测试中使用这类信息越多，测试就越偏向于工程而不是猜想。

     在微软，咱们有一个游戏测试组织（Games Test Organization, GTO），负责Xbox和PC游戏的测试。谈到利用应用程序的信息，他们是最优秀的。游戏是不可思议的丰富，测试起来很是复杂。游戏中不少可测试的内容都是隐藏的（由于让那些玩家找寻能够交换的物品正是游戏的乐趣之一）。若是GTO的测试人员所作的仅仅是玩游戏，那么他们找到的问题不会比最终用户更多。为了能作得更好，他们与游戏的开发人员合做建立了一些信息控制板，这些控制板暴露了一些基本上能够算得上做弊的信息给测试人员。这样，测试人员就能提早知道怪物会被投放在何处、物品被隐藏在哪里，他们能够看到墙的另外一边，能够控制敌方的某些行为。他们的做弊工具（即测试工具）基本上使他们成为游戏里的神，让他们能够控制看到的信息以便更快更巧妙地测试。这个例子给有测试人员都上了一课。

       来自测试的信息意味着你必须关注在测试时所作的一切，并使用得到的信息来影响从此的测试。你是否知道你的测试是如何与需求结合的，知道什么时候某一特定需求已经获得足够的测试？你是否使用代码覆盖率来影响将来的测试？你知道当代码更新或缺陷修复时那些测试会受到影响，仍是知识从新运行全部的测试？理解测试进行到什么程度并随着测试调整测试策略，这是测试成熟的标志。

       我之前曾在微软的Visual Studio的一个小组工做过，咱们大量使用代码改动量（因为添加新特性或修复缺陷而改变的代码）和代码覆盖来影响咱们的测试。咱们花了很大的力气将代码覆盖和代码改动量通知测试人员，帮助他们理解哪些测试用例对覆盖率有贡献，帮助他们测试改动过的或修改过的组件。最终的结果是在代码确实被改动时，咱们清楚地知道哪些测试会被影响而只从新运行那些测试。咱们还知道每一个新的测试用例是如何对整体的接口，特性和代码覆盖率产生做用的，从而指导咱们的测试人员，让团队中的每一个人在他们所建立的全部测试用例基础上，写出更有意义的测试。

       你用哪些信息来指导你的测试？你如何保证信息是可获取的，以便在测试中随时能够获得？你如何使得信息变得有用，以便它能以良好的方式影响你的测试？这些问题的答案将决定你在走向专家测试山峰时的前进速度。

 

下山

    到达测试山峰的顶峰的时候，你已经成为一个十分能干的测试人员了，能力也许至关于你组里全部同事能力的总和。不管你在作什么，请不要试图作得比你的整个团队都好，无论你对此感受有多好，或是你的老板对你遏得有多紧。一旦你走在下坡的路上，就不要再去争取“找到最多缺陷的人”或是“找到最有意义缺陷的人”这样的荣誉头衔。反而我推荐你减小花在测试上的时间，而把创新做为你的首要任务。

       在测试上创新指不急于向前，而是仔细观察、洞察先机、找到瓶颈并改进团队中全部其余人的工做方式。你的工做变为帮助其余人进步。在微软，咱们有一个专门为此而设的正式职位——测试架构师。不过，不要由于缺乏一个很酷的头衔而让你沮丧。不管别人怎么称呼你，当你在“下坡“的路上，你能作的最好的事就是尽可能保证更多的人能成功地爬上山峰的另外一侧。