扩大我们的团队并不意味着我们的业务扩大?

　　有时，一个团队从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。下面是 一次访谈 的片断：

　　InfoQ：在本书中，你提出了，“不要雇用太多的测试员”，并且在未来里测试工程师的作用在下降。你对此有何回应，公司认为需要更多的角色，以此划分开发人员和质量保证之间的界线?

　　为什么你要这样的界线吗?谷歌已经证明编写代码和保证代码的界线是模糊的，其结果是代码被开发更快，并且潜在缺陷更少。雇用太多的测试员是为开发人员创建了一个依靠，对产品来说这是有害的。当人们过于纠结自己的角色，会使我懊恼。“我是一个测试员”是一种不健康的心态。“我是一名开发人员”同样也是不健康的心态。当人们停止过多关注自己的角色，开始专注于他们的产品，这才是奇迹发生之时。这时候，每个人都专注于尽一切力量来打造他们能打造的好的产品。

　　InfoQ：对当前那些考虑加入测试相关角色的测试分析师(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方法的一个令人兴奋的结果。