第二部分 - 我的一些建议
在这部分的文章中，我将专注于提供建议，以此帮助你的职业生涯发展。的确改变可能需要一段时间，有一天，你将成为一个资深员工。不断学习，不断思考和壮大自己的兴趣是你的职业成功的关键。我希望本文可以帮助你思考和开始积累你的力量。以我自己为例，我曾只专注于我的项目，只用很少的时间来思考。有一天，我无意中访问了一个网站，和听到了“被夸大的测试(Testing is Overrated)” 的会谈。阅读后，我把我的想法分享给我的同事们，并认识到，在我工作之外还有这么多出色的信息。我开始阅读这些文章，并借阅测试??书籍。培养这样的学习和思考的习惯会花费时间，但一旦你有了这样的能力，你会发现，你可以成长得非常迅速。
激情和动力
有时，人们每天都做类似的事情就会觉得乏味。他们开始失去激情，感觉自己的职业生涯发展变得缓慢。我们应该如何处理这种情况？我可以给你一些建议。
● 考虑离开自己的舒适区域。
一旦你在一个地方里待了很长一段时间，你就有了一个舒适区域，它让你觉得你的工作失去挑战，你的技能不在提高。因此，是时候来改变了。你既可以换到其他公司也可以换到其他不熟悉项目。请大家认真考虑这个问题，因为这对你的职业生涯有重要影响。在未来的博文中，我将详细讨论改变或不改变。在一般情况下，我认为改变是应该的，你应该常常对此进行思考。我看到过很多例子，换到其他团队，并获取到更好的职业生涯。另外，还要考虑到换到其他团队，会给你提供机会，去学习新的、最终将有利于你的技能。
● 考虑做一些某些副项目(side project)。
我的第二个建议是，考虑做一些副项目。在过去的几年里，我发现，大家在他们的空闲时间里或主要任务责任外打造的项目往往比资助项目有更大的影响(the side projects which people build during their free time or out of main responsibility tend to have much larger impact that the funded project.)。作为一个专业的工程师，我们应该自我激励，自我组织。如果我所做的事情正是我的兴趣所在，我将会对它充满激情，并会为它做出持续努力。
● 拓展你的兴趣点。
我的第三个建议是，试试其他领域的兴趣。例如，当我觉得日常工作很枯燥时，我经常去公司内部微博，了解今天微软内部发生了些什么事。我喜欢阅读文章，了解公司外部又发生了些什么事。我喜欢阅读谷歌测试博客了解他们正在做些什么。你可以选择一个你特别有兴趣的领域，然后保持这个卓越的习惯，每天都学习些新东西。
最后，我有一些建议给我们的经理：宏观管理而不是微观管理；给大家一些做其他事情的自由；鼓励大家去尝试不同的机会。我知道我们的承诺，我们的任务必须要完成。然而，让大家愉快和受到激励比交付一个功能更为重要。一个快乐的团队能提供更好的产品，我们都不希望总是压力山大。
开放的思想和广泛的兴趣
一旦你在一个地方里待了很长一段时间，在你所在领域你获得了非常深厚的领域知识和测试方法。在这种情况下，我们往往是安于我们现在所做的，并有时还会避免改变。然而，作为一个专业的软件测试员，我们应该始终更宽更广地思考，思考有我们可以采用些什么新技术，思考你所在领域的未来测试技术。在一般情况下，一个优秀的软件测试员应该思考的比我们目前已有的东西更远，并有一些应对更改的计划。
为什么呢？究其原因是技术变化太快，如果我们不提前考虑，提前做好准备，有一天，当变化发生时，你会发现，你得仓促地面对这么多的挑战。例如，我总在浏览技术网站，以此提高我的技能。当我们的团队决定用列存储来实现数据仓库时，我已经知道我们为什么应该这样做的，这个领域中最热门的技术是什么。
为了培养这样的技能，我们需要的是开放和广泛。我们需要知道公司内部发生了什么事，社区里又发生了什么事。我们应该很开放地聆听和学习别人的想法。我强烈的主张，我们的资深测试员应与其他团队成员保持密切联系，尤其是微软里其他团队，并培养一种学习技术并能迅速吸收的能力。有一天，你会觉得学习的投入将为你的工作带来巨大的回报。
我可以给你一个例子，我如何做到这一点。就我而言，我订阅了微软内部和外部的大量非常活跃的博客，接收别人的更新。我也参加了会谈和培训，来提高自己。讲座范围可以非常广泛，如云计算中的系统工程方法(service engineering)，基于场景的工程方法(scenario focus engineer)，即以用户需求为导向的系统开发，等等。通过参加这样的培训，你将收获更广的技术知识。另外，你能知道公司内部发生了什么事。在过去的一年，我就参加了两个$99外训，然后我引入ATDD和个人看板(Personal Kanban)到我们的团队之中。SQL团队中许多成员所使用的技术和ATDD，其实早已被微软内部的很多团队使用过。你可以看到开放和广泛的价值，它能帮助你成长为一个资深测试员。
提升影响力(Making Big Impact)
今天，我想谈的另一个话题是作为一个资深测试员，需提升影响力。衡量一个人的成就的重要途径之一就是你对团队，对项目，对客户有多大的影响。我有三个方面提升影响力的建议。
● 帮助他人的成长
我们需要意识到，无论你是多么聪明，只靠你自己，你是不可能成功的。你帮助他人成长越多，你越可能会成功。作为一名资深测试员，我总是很喜欢看到初级测试员提高他们的技能，发展他们的职业，我也将提供建议和指导他们，帮助他们成长。就我的心里而言，我认为帮助别人是最重要的事情，我们应该每一天都帮助别人。有很多方法可以帮助他人成长，帮助他们做项目，回答论坛里问题，指导新成员，教他们如何编码和如何测试。对一个团队来说，建立这样的文化氛围是极其重要的，因为大家会感到其他人的温暖，并鼓励分享和学习。最后，我们一个团队一起都能成长起来
● 影响他人
一旦你变得越来越资深，你已经掌握了非常深厚的技术知识，大量的项目经验。你得到别人更多的尊重，成为某一领域内的大牛(GOTO person)。换句话说，你有能力影响他人。如果我们看看，架构师，技术潮人(Techiques Follows)，大牛的工程师(Distinct Engineers)，他们的观点和思想能影响了很多人，类似这样的能力是他们独一无二的资产。
你认为我们能够像大牛一样影响其他人吗？我想是可以的。每个人都有一个你擅长的领域。你应该用你的专业知识来帮助人们作出决定，并提供宝贵的建议。例如，对于每一个我参与过的或我学习到的项目，我都对它有些独特的看法，我试图理解为什么我们应该开发这样的项目，我会更多思考为什么我们不使用另一种方式来构建它，我常常把我的想法分享给项目里的所有人然后我们一起再作出决定。我写了大量的博客，分享我的想法，并希望影响更多的人。
● 更多的跨团队协作
以我自己为例，在最近几年，我引入ATDD(验收测试驱动开发 - Acceptance Test-Driven Development)到我们的团队，并把它介绍给很多微软内部的其他团队，如Bing，Lync团队。我也参加不同类型的会议和研讨会，了解其他团队是在如何做测试。每当我看到有人做我所熟悉的项目，我也问他们是否需要帮助。
总之，当你努力提升你的影响力时，你的经验同样也会积累越来越多，你不断成长为一个资深测试员。
编码，编码，编码
今天，我想讨论一个最重要的技能，我们的软件测试员应该在自己的职业生涯中所掌握，这就是编码。
● 为什么编码这么重要？
因为你是软件测试员(SDET)，软件测试开发工程师(Software Development Engineer in Test)，你是软件工程师。作为一个软件工程师，编码就是每一天你应该做的任务，这是你应该掌握的技能。你可能会问是否编写测试用例没有编码更重要。这里的原因是，编写测试用例可以帮助提高产品的质量，但有时它并没有促进你的职业生涯发展。我可以举我的一个例子。当我刚参加到SQL Server团队之中，我们编写以T-SQL脚本为基础的测试，我很少有机会写编码。因此，我的编码技巧并没有提高。幸运的是，SQL Server的测试团队转移到以编程的方式编写测试，今天，我们的软件测试员的编码时间增加了不少。这是相当不错。当然，有时我们花费太多的时间在编写代码和类库上，而花费较少的时间来写真正的测试用例。这是另一个很大的话题，在这里我就不打算讨论了。
由于今天我们当中大部分人在编写自动化测试，这意味着我们有很大的机会来提高我们的编码技能吗？答案是不一定。今天我们的测试员做了太多的任务：我们编写测试库，我们验证测试结果，验收产品，我们配置机器和安装新版本进行测试，我们修正我们脆弱的测试，我们创建和关闭缺陷。有时我们花费大量的时间在下载和编译源代码。我们也有其他的任务，如会议，项目跟踪 / 缺陷报告。上述所有任务将需要花费我们每天中的大量时间，而时间提醒着我们，做实实在在编码真得很少，我们的技能提高也非常小。我记得有一天，我曾对我们的测试经理提到过我的梦想——我可以花50％的时间在编码上，他很惊讶，他认为这个数字理应还要大很多。然而，现实是这个数字理应小得多。
所以，我们该怎么处理这种情况呢？我们应该尽力尝试，改善我们的工程系统，以减少不必要的时间开销，让系统能够安装配置环境，安装测试版本，运行测试，创建 / 关闭的缺陷和退出测试。所有这些应该是自动化的。我们应给自己承诺每天尽可能多得编码。由于你的工作性质，如果你不能做到这一点，你应该考虑换到其他工作。
小结，请记住编码是一个重要的技能，你应该去提高它。
花时间去思考
在最近几天，我试图去理解，我们应该如何去教导和学生如何去学习。我的Ph.D研究经验和最近戴尔·卡耐基培训，为我提供一些想法：
● 教给他人或分享经验给他人最佳的办法是让他们思考。在你的谈话中不管他们思考了什么，他们至少学到些东西。一个好的实践是鼓励他们说话，与你互动。
● 思考自身有时可能并不够，我们可能需要实践和应用我们的思考到我们的工作中。
就研究论文而言，我们的论文大部分沿用了经典的格式，它必须有简介，相关的研究，实验结果和结论。没有实验结果的论文几乎是不可能被发布的。另一方面，论文的本质观点，似乎是不知为何地被隐藏起来或不是那么容易得找出来。我认为这是做研究里一个的问题。
当我们想要向人们做演示展现点东西时，或者我们想要写点东西教给别人时，同样也有上面的问题。首先，你会花很多时间在研究我应该思考些什么。之后，你头脑中就有些想法了，你会渴望通过写些东西与他人分享，这是一个很棒的方式来概括你的想法。
最后，我相信资深测试员的价值，是他可以给团队带来的观点 / 技能，而不是他在过去的工作经验。对我们的软件测试员来说，能够努力思考问题，并找出解决方案是一个重要的技能，我希望我们的资深员工应有的最最重要的技能就是思考 ，一个优秀的领导必须首先是一个出色的思考者。
了解产品
我相信作为一个资深软件测试员，我们应该充分了解我们正在测试的产品。知道产品的方向 / 未来是创建更好的测试的第一步。换句话说，如果我们不理解为什么我们应该构建这个产品和我们将构建怎样的产品，那么我们将不能编写出优秀的测试。
我们应该更多地参与项目 / 产品的规划，并影响产品的的策略（不仅是测试策略）。请注意，这是我们可以提高产品质量的重要途径之一。如果我们可以发现设计时的缺陷，我们可以节省下很多的时间和金钱，而且甚至比发现大量功能上的缺陷要有价值得多。有趣的是，我相信一个优秀的产品设计和一个正确的方向，会带来更少功能缺陷。过去我参与了大量的改进，我发现，如果是精心设计的功能，我们在实现功能的过程中将看到更少的产品问题 / 缺陷 / 后顾之忧。无论如何，如果该功能没有得到很好的设计，我们不应该去实现这个功能，否则你在执行的功能时会看到很多问题。
参与产品的设计，也可以帮助我们提高管理 / 构建项目的技能。并提高我们的技术技能，对测试架构师和领域专家的职业道路都是至关重要的。
了解产品，可以帮助团队成员讲同一种语言，更顺畅地交流。假设有一天，你想加入另一家公司做云计算，当你和你的面试官谈论时，他们可能会问你很多关于云计算的问题。如果我们只知道在服务中如何测试单个组件，你会发现你是缺乏知识 / 思考的，这将影响你未来的职业生涯。然而，如果你知道并思考过IASS，PASS，亚马逊AWS等云计算技术，我敢打赌，你将有更大的机会得到这个职位。对于一家初创公司来说，有一个除测试以外的技能是至关重要的。这始终是一条金科玉律。
最后，我想分享下Erwin Engelsma的观点：
“测试能够提高顾客的满意度，前提是你真的知道客户认为什么是真正重要的，并测试了相关的内容。在你的客户几乎不感兴趣的领域，做出很大的改进，虽然是一个值得称道的努力，但是这不会改变他们对产品好坏的看法！”
- 改进测试时的关键问题 —— Erwin Engelsma。
用不同的方式做事
有一天，我的经理问我：“Qingsong，当你还在高级测试员级别时，为什么你可以得到出众的评价结果??”。在高级测试员的阶段，我还没有很丰富的测试知识，对团队的影响也不大。所以，我也想知道是什么让我有这么一个出色的评价结果，答案就是在用不同方式做事情。
这个问题的一种思考方式是，你如何把你与其他人区分开来。我发现当我被分配了一些任务时，我会额外地做一些我应该做的事情，这使我跟他人不一样，更主要的原因，我提升了影响力，也发展我的职业。这里有一些在过去我曾做过的事情的例子：
● 当我们计划在SQL Server中增加对日期和时间(Date and Time)的支持时，我花了很多时间来研究日期 / 时间和时区在Windows，Linux，.NET和Win32 API上的支持情况。我曾积极参与到项目的规划和设计中。这就让当我们测试功能时，我就有了一个更好的地位。另外，我在该功能的测试过程中承担了更多的责任，包括构建管理，测试运行管理，在线文档审查，并帮助他人编写测试用例。这些增加了我的知识，还帮我产生了更大的影响。
● 当我们在SQL Server 2008中实现了稀疏列(Sparse Column)功能之后，在功能提交后我并没有停止思考我们的功能。我曾积极地在内部寻找能够使用我们这个功能的地方。最后，我发现我们团队的VSTS系统可以使用这个功能，所以我和支持团队一起工作，把这个功能部署到系统中去。这样一来，我帮忙提高了团队的业务能力，同时也更好地了解到功能的用户场景。结果就是，我看到这个功能还缺少的一些更细功能。
最后，我希望你能体会用不同方式做事的意义。如果你有这样的能力，将会帮助你的职业生涯很多。
给测试经理的建议
今天，我希望写一篇关于招聘软件测试员的博文。主要读者是我们的招聘经理。这篇博文不是关于如何面试人或决定雇不雇用一个人，我认为这些是具体过程。而我的主要议题将关注为什么，即为什么我们需要聘请一个或多个测试员。
我不是一个测试经理，当需要更多的人时，我不知道我们的经理给人力资源那边说的原因是什么。也许先让我列一些可能的原因：
1）我们开始一个新的项目或功能，我们需要建立一个新的开发和测试团队。
2）我们有一个新的测试主管(test lead)，主管应至少管理5～8人。
3）我们在做项目时，测试资源短缺。
4）我们的副总裁给测试经理一些名额，如果我们不填上这些名额，就会被“浪费掉”。
我们真的缺乏测试资源吗？
我总是听人说他们的项目缺乏测试资源。但是，我们真的缺乏测试员？不一定，根本不是。微软内部没有测试资源缺乏的问题，而是资源分配问题。今天，我们的测试通常属于一个组件(component)团队，由一个测试主管带领。他深刻理解他的领域并且测试也做得相当不错，以便发展他的职业生涯。人们往往认为，每一个部门都需要一个单独的测试团队人们往往认为，测试是一个专业的工作，需要深入的了解测试。我们可以以另一个角度来看这个问题。今天，现代的测试框架，如NUnit，XUnit，MSTest和Selenium，编写自动化测试起来是非常容易，做测试并不是真的需要太多的测试知识，尤其是对于白盒测试来说（我相信由开发人员来写白盒测试并尽早地跑起来，那么白盒测试的效果将比黑盒测试大得多）。
我看到不少的情况是，我们的资深软件测试员对他们负责的组件有着丰富的领域知识，对于这样的组件，深刻理解是必要的。测试查询优化器(query optimizer)就是一个例子。不过，我认为最好的测试员应该把他的知识和测试理念应用到测试类库，让每个人都可以使用它，使得这样的组件测试变得更加容易。在SQL Server中，TestQP和QREL是很好的例子，这两个工具就内嵌了查询优化器和关系数据库的知识。你将你的知识转化为代码后，我觉得你能随意移植到其他团队，我们是没有必要去限制，因为他在这个领域中有着最丰富的知识。
扩大我们的团队并不意味着我们的业务扩大？
有时，一个团队从5人扩大到20人甚至更多时，人们感到自豪。然而，这并不意味着，我们的业务扩展了四倍。不应该用人数来衡量经理或团队成功与否。
你想增加新的测试员来提高团队的工作效率？
这可不一定。有时，它是成立的，我们的测试员在项目上非常繁忙，我们有一种感觉，添加一个或多个的测试员可以帮助我们，真的吗？如果原因是我们想招人，那完成这个项目之后又该怎么办？我们永久地保留他们。
下面是一些我给我们招聘经理的建议，如果他想雇用一个新的测试员时：
1）需要一个测试员时，尝试探索不同的方法来解决这个问题，并把雇用一个新的测试员作为最后的备选解决办法。
2）如果在项目上我们需要更多的测试员，我们可以从其他的团队调用些测试员吗？
3）如果我们有太多要做的事情，我们能标清优先级，并放弃部分低优先级的任务吗？
4）考虑培养一个技术主管，而不是培养一个人事管理主管。我们倾向于培养非常优秀的技术人员成为主管，让他管理更多的人。然而，今天我们的主管，在人事管理和其他的东西上花了太多的时间，他们只是没有时间思考，没有时间去提高他们的技术方面技能。所以，请考虑把我们的主管视为技术主管，这样一来，管理多少并不重要，重要的是能影响帮助到团队的人。
5）请务必花时间去改善我们的文化，我们的过程和方法。优秀工程是更高生产力的关键。减少我们的技术负债，投入时间去创新。
6）考虑采用一些指标来衡量测试员或测试的效率，因此，我们可以用更好的方式来作出决定。
测试新人的职业生涯怎么样？
这是一个很大的话题，这里我不会说得太多。一种看法是，我们都希望我们的员工能够快速成长，在未来有一个更好的职业。我们都希望我们的测试员可以很轻松地在其他公司找到测试工作，如果他们决定去追求公司以外的机会。然而，今天许多公司的开发人员与测试员比例相对偏低，并且他们相信他们的产品质量不算坏。我希望有人能在就业市场和测试员的水平上做一些研究，我们可以用更多的事实来分析这个问题。
结论
这是“成长为资深软件测试员”系列博文的结尾。我希望从我的博客中，你可以学到一些有用的信息，并帮助你决定你的职业道路。近年来，计算机技术的变化日新月异。云计算，社交网络，移动都是热点领域。技术的变更同样也需要不同类型的测试技术。我会开始写另一个系列博文——“对测试的未来和软件测试员的职业的未来”。在接下来的段落中，我将列出一些的最新文章，以此回答软件测试的未来是什么，服务领域测试(testing in the service area)的未来是什么，以及对软件测试员的职业生涯有何影响。
“测试的未来”的相关参考文章：
● 在谷歌2011年的测试自动化会议上，谷歌工程和创新倡导者的主管(Director of Engineering and Innovation Agitator at Google)——Alberto Savoia负责开幕式主题演讲。他认为，我们曾熟知的软件测试已死 - 或至少是垂死的。我与几位同事看了这个视频两遍，大家都觉得这是很警醒的谈话，让我们更严肃地深思测试和事业。我强烈推荐每个测试相关的人去看看这个视频。主题中提到，初创公司对“我们正在做正确的事情吗？”比“我们正在正确地做事吗？”更感兴趣。也就是说，这里的质量真的不是我的软件或者服务是否有缺陷，而是我的想法是不是吸引顾客的最佳想法。这对我们的软件测试员有一定的影响，因为我们太专注于
“我们正在正确地做事吗？”，并可能导致我们很难在初创公司找到工作。
● “众包”是最近非常热门的话题。你能想象一家拥有数以十万计的软件测试员的公司吗，它可以帮助其他公司在极短的时间内完成测试。这些兼职软件测试员的薪水和他们找到的缺陷挂钩。他们在不同的地方用不同的语言在不同的设备上运行测试。不同于我们的内部测试，他们像真正的客户般的运行测试。 uTes??t.com就是这么一个公司，该公司在这个领域相当抢眼，它将会对测试服务和测试移动应用的方式上有着极大影响。在内部，我们有几个团队，包括Bing，Lync，都在积极利用众包来测试他们的功能。对我们的测试员意味着是什么？仍是未知数。
● 由James Whittaker ， Jason Arbon和Jeff Carollo编写的“ 谷歌怎样进行软件测试 ”，很详细地回答封面的上问题。能在迷雾下看到像谷歌这么一个大型技术公司如何处理软件测试的复杂性，是很具知识性和趣味性。一个有趣的现象是，在此书的出版之前，三位作者都离开谷歌，一位回到微软担任开发主管，和另外两个则加入了uTest.com。下面是 一次访谈 的片断：
提问：在本书中，你提出了，“不要雇用太多的测试员”，并且在未来里测试工程师的作用在下降。你对此有何回应，公司认为需要更多的角色，以此划分开发人员和质量保证之间的界线？
为什么你要这样的界线吗？谷歌已经证明编写代码和保证代码优秀的界线是模糊的，其结果就是代码被开发更快，并且潜在缺陷更少。雇用太多的测试员是为开发人员创建了一个依靠，对产品来说这就是有害的。当人们过于纠结自己的角色，会使我懊恼。“我是一个测试员”是一种不健康的心态。“我是一名开发人员”同样也是不健康的心态。当人们停止过多关注自己的角色，开始专注于他们的产品，这才是奇迹发生之时。这时候，每个人都专注于尽一切力量来打造他们能打造的最好的产品。
提问：对当前那些考虑加入测试相关角色的测试分析师(test analysts)或新毕业生，你能提供最好的建议是什么？可以满足这个角色不断变化的技能。
对待测试如同开发一般。获取一个CS学位，并擅长CS。证书和行业培训只会教你简单的东西。学习难的东西，并掌握它。软件测试员只做简单的事情，在很长的时间里仍然会被视为二等公民。不想被这样对待吧？那就获取一等的技能。
● Bing团队的融合工程(Combined Engineering)设想，对服务测试和软件测试员的职业生涯都是非常有趣的。在融合工程，软件开发工程师（SDE）们和软件测试开发工程师（SDET）们合并为一个“工程师”的角色，我们为交付服务而优化，而不是为软件而优化。换句话说，许多测试成为开发者，真正的开发人员只写代码，而不是测试。我认为这可能是服务团队的未来发展方向，今天的测试员可以更专注于监测，基础设施和工具，他们和开发人员是一样的。
● 我们的生产环境测试(Testing in Production)专家——Seth Eliot，认为TestOps是我们的测试的未来发展道路之一。你可以到这个链接看看相关信息。我认为生产环境测试能真正改变我们如何做测试以及测试员的职业的未来。这是TestOps访谈的一个小段：
我认为测试领域的一个重要的变化将是我已经谈到过围绕测试服务和生产环境测试。我把它称为TestOps。
测试员需要摆脱定式思维观念，编写测试 - 运行测试 - 评估结果。我们要使用大量数据（一般是指服务）作为产品的质量信号，而不是用日常运行的测试结果作为质量信号。这包括系统数据，如CPU，API请求，系统响应时间，以及（妥善匿名处理的）用户数据。此外，还包括在生产环境中持续运行时交易发出的数据。这些依然是测试用例，你可以得到持续的可用性和性能状况，而不是只获得每天的失败 / 通过的状态。这是一种技术，但它也必定会改变我们的软件工程。角色的分类与归类(role and specialization versus generalization)的问题，答案是应满足每个团队的具体需要。数据科学家做为工程团队的一部分，就是TestOps方法的一个令人兴奋的结果。
版权声明：本文出自 omg 的51Testing软件测试博客：http://www.51testing.com/?166582
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
相关链接：
软件测试员，敢问路在何方？（第一部分）