看到一篇梳理微软的QA变迁史的文章，之前只听说过微软曾经直接干掉了所以的qa角色，不过也只是道听途说而已，这篇文章见微知著的以内部qa的视角描述了整个演进的过程，并对最终的结果进行了描述，还是非常有参考价值的。原文在这里：https://blog.pragmaticengineer.com/how-microsoft-does-qa。 下面是中文翻译。

SDET角色

SDET（软件开发测试工程师）角色是微软在技术行业中首创的。他们是专注于编写自动化测试、构建和维护测试系统的软件工程师。SDET与软件开发工程师（SDE）唯一的区别在于，SDET通常不编写生产代码，而是编写测试代码，并与SDE在同一个团队中工作。

我无法追溯该角色的确切引入时间，但很可能是在1990年代。例如，这是微软Exchange团队的一位成员在2004年发表的一篇帖子，解释了在他们组织中成为SDET的含义：

“SDET是一位在测试团队而非开发团队工作的开发人员。SDET具备测试员的敏锐感，同时喜欢编写大量代码。

SDET通过提供必要的工具和流程，使测试人员能够充分发挥他们的优势...在产品上市之前，尽可能多地测试产品并发现尽可能多的错误。

SDET具备分析产品功能和架构的能力，从而设计和实现有助于测试的工具。

SDET喜欢短期项目生命周期，在一年内设计和实现许多工具和测试框架，使用最新技术，并有充分的创新空间。

尽管产品质量是首要关注的问题，但SDET在产品生命周期末期不会像开发人员那样感到压力。通俗地说... SDET很少会面临风险:)”

微软为SDET角色设定了正式的职业发展路径。同一篇帖子中写道：

“[SDET职位]有很大的发展空间。如果你喜欢作为SDET所做的工作，你可以发展成为测试架构师。如果你想参与管理工作，那么你可以逐步晋升为SDET主管，然后成为测试经理。

如果你只想编码而不参与测试工作，你可以选择成为开发人员的道路。许多人选择了这条道路。如果你意识到你的心属于测试，那么你可以成为一名测试员。”

直到2014年左右，SDE和SDET之间的比例在微软内部普遍为2:1。在2012年我所在的Skype for Xbox One团队也是如此。以下是我们团队的人员构成，根据员工人数计算：

12名SDE（软件开发工程师） 6名SDET（软件开发测试工程师） 2名PM（产品经理） 1名EM（工程经理） 1名SDET主管

在我们的项目中，SDET团队负责所有测试的方面：

• 手动验证开发人员构建的功能是否按预期工作，包括可能没有考虑到的边界情况。
• 构建集成和端到端测试以自动化检查。
• 创建手动测试计划，并在重要的里程碑之前执行。
• 在功能规划阶段参与其中，提出边界情况的想法以及如何验证工作的方式。
• 解决一些棘手的问题，例如如何在Xbox硬件上可靠地进行Skype产品的性能基准测试。

在早期，单元测试是一个引发争议的问题。谁应该编写它们？一些有经验的开发人员来自游戏行业，游戏开发人员通常不编写自动化测试，他们认为任何自动化测试，包括单元测试，都应该由SDET团队完成。我们在《游戏开发基础》中详细介绍了游戏的构建过程，并在《构建一个简单的游戏》中进行了实际操作。

那些之前构建过应用程序或进行过测试驱动开发（TDD）的人认为这种方法是错误的，开发人员应该编写自己的单元测试，因为单元测试与代码是紧密耦合的。我属于这个阵营。

有专门的SDETs使得开发人员“外包”单元测试的写作成为一个诱人的选择。 我现在就要说了：如果没有SDET团队，关于谁来编写单元测试的问题将不会成为争论的焦点：我们开发人员将不得不自己编写它们。这是我在每个有指定SDET的团队中都看到的一场反复争论。令人惊讶的是，即使在今年，我还听说过一个硅谷公司的开发团队让测试团队编写单元测试的情况！

在我们的情况下，我们决定由开发人员编写单元测试，而SDET团队负责其他所有工作。这种方法运行得还不错，但其中有一些令人难忘的特点：

• "我们和他们"的动态关系导致了分裂。当我们开发人员完成一个功能时，我们将其交给SDET，通常会发现问题，所以功能会回到开发人员手中进行修复。这让开发人员感到很烦恼，因为这会导致我们可能没有预料到的工作。随着时间的推移，开始感觉就像有两个团队，拥有不同的目标，不总是朝着同一个方向努力。
• 开发和测试之间的问题往返。我完成了我的功能工作，并将其发送给测试（ping）。测试人员在第二天找到一个错误，并将其发送回给我（pong）。我修复了错误，并在几天后再次发送（ping）。测试人员又找到了另一个错误并将其发送回给我...这种来回发生的次数比我愿意承认的要多！
• 开发人员擅长构建复杂系统，并且可以为SDET提供很多帮助。我们的SDET团队已经花了几个月时间构建一个集成测试系统，进展缓慢。我们的团队真的需要这个系统，因为手动测试太耗时了。最后，一位资深工程师建议开发人员加入其中，一起构建这个系统，作为一个团队。两周后，在经验丰富的开发人员的带领下，系统成功运行起来。这让我思考：如果没有开发/测试的分裂，团队是否会工作得更好？我们刚刚证明了这一点。
• 房间里的大象：一些开发人员看不起SDET角色。虽然并非所有人都这样认为，但很明显，许多开发人员认为SDET的工作不如他们自己的工作具有挑战性。SDETs也知道，通过转向开发角色，他们可以获得更好的职业发展机会。

事实证明，他们不需要等那么久才能晋升。

2014年初，我加入了Skype网络团队——这支“日更”团队完全颠覆了我对Skype的认知，他们每天都在发布新版本软件，而不是像其他团队那样按月发布。

团队架构乍一看是6名软件工程师和3名测试工程师，但实际上只有一个“假身份”测试工程师。团队领导悄咪咪地做了一个大胆的决定：既然每天都要发布新功能，单独设置测试岗位根本没必要。我在另一篇文章中讲述了这个未公开的变革，标题是“科技巨头如何管理技术项目以及Scrum的意外缺失”。

刚加入团队时，我们遵循两周的敏捷开发流程，采用标准的Scrum仪式，工程师和测试工程师也分得清清楚楚。但是，两周的发布周期还是太长了，我们希望能更快地迭代。

于是，我们做出了一个悄然改变：让所有测试工程师也参与构建生产软件，每个工程师都对自己的代码负责，测试和开发融为一体。这样一来，我们就不用再花几天时间等待测试反馈，新功能就能迅速上线。不过，两个星期一次的冲刺和冗杂的Scrum仪式又成了新的瓶颈。

干掉SDET角色

2014年初，我加入了Skype网络团队——这支“日更”团队完全颠覆了我对Skype的认知，他们每天都在发布新版本软件，而不是像其他团队那样按月发布。

团队架构乍一看是6名软件工程师和3名测试工程师，但实际上只有一个“假身份”测试工程师。团队领导悄咪咪地做了一个大胆的决定：既然每天都要发布新功能，单独设置测试岗位根本没必要。我在另一篇文章中讲述了这个未公开的变革，标题是“科技巨头如何管理技术项目以及Scrum的意外缺失”。

刚加入团队时，我们遵循两周的敏捷开发流程，采用标准的Scrum仪式，工程师和测试工程师也分得清清楚楚。但是，两周的发布周期还是太长了，我们希望能更快地迭代。

于是，我们做出了一个悄然改变：让所有测试工程师也参与构建生产软件，每个工程师都对自己的代码负责，测试和开发融为一体。这样一来，我们就不用再花几天时间等待测试反馈，新功能就能迅速上线。不过，两个星期一次的冲刺和冗杂的Scrum仪式又成了新的瓶颈。

我们通过从团队中移除SDET角色变得更加高效！SDETs仍然主要专注于与测试相关的工作，但也承担起了开发任务。同样重要的是，我们进行了很多配对工作！我记得和SDETs一起构建一个功能。我擅长思考如何使某个东西正常工作，而SDET非常擅长指出我没有考虑到的边界情况。在调试方面，SDETs的机智能力让我感到惊讶。

在微软的大多数团队中，SDETs花费很多时间手动测试和编写集成测试。但在我们的团队中，手动测试非常少，我们都建立了集成测试基础设施和监控基础设施。当开发人员或SDET接手一项工作时，他们编写所有的测试-单元测试和集成测试-这是有道理的。

这个变化的最好之处是不再有“我们对他们”的对立。关于是否修复SDET发现的错误的争论停止了，因为现在我们自己进行测试并修复我们发现的错误，然后再发布到生产环境中。

微软的Web团队开始悄悄地移除SDET角色。回到2014年，伦敦Skype办公室的我们的Web团队感到“特别”，因为唯一合并SDET职能的其他团队都是基于Web的团队，而这样的团队并不多。在其他团队中，SDETs继续按照他们过去的方式工作。

然而，合并这些角色以提高效率不仅仅发生在Skype部门的Web团队中。Web团队独立地意识到合并SDET和开发角色可以让他们更快地前进，所以这一变化在整个微软都发生了！

在2014年中期，微软正式废除了SDET角色，并引入了SE角色。灵感显然来自于微软的一个更大的Web团队，即Bing团队。根据Ars Technica在2014年的报道：

“在Bing团队中，创建程序化测试的任务转移到了开发人员身上，而不是专门的测试人员。质量保证仍然存在且仍然重要，但它执行的是“真实世界”样式的最终用户测试，而不是程序化自动化测试。这种测试对于Bing来说非常成功，提高了团队在不损害整体软件质量的情况下发布更改的能力。”

在2014年7月，微软宣布将进行迄今为止最大规模的裁员，裁掉公司员工中的18,000人，总共有127,000名员工。其中12,500人是诺基亚部门的裁员。作为这次裁员的一部分，大量的SDET职位也被取消。这发生在SDET角色被宣布退休的同时，现有的SDETs需要在接下来的几个月内转入软件开发工程师（SDE）职务。SDE角色也被更名为SE-软件工程师。

这个转变进展如何？据我所了解，情况还不错。对于每天发布产品的团队来说，这个变化非常合理。而在微软内部，每周或每月发布产品的团队越来越少，因为微软也倾向于采用软件即服务（SaaS）模式。当然，微软仍然是Windows操作系统系列和Surface平板电脑的供应商。在这两个领域，质量的要求与SaaS产品不同。

关于这个变化的一个很好的描述来自于2017年的Visual Studio Team Services团队，也就是这个变化发生三年后。回顾这个变化，目前担任微软技术专员的Brian Harry写道：

“两年前（2015年），我们有数万个测试。这些测试是由‘测试人员’编写来测试‘开发人员’编写的代码。虽然这种模式有一些优点，比如明确可衡量和可控制的测试投资、测试学科的专业知识和职业发展等，但也存在许多缺点，如开发人员缺乏责任感、反馈周期慢（引入错误，发现错误，修复错误）、开发人员对于使其代码“可测试”没有太大动力、代码架构与测试架构之间的分歧导致重构和转变非常困难和昂贵，等等。（...）

完整的测试需要花费大部分时间来运行，还需要更多小时来“分析结果”以识别错误的失败，并需要几天或几周来修复由于产品中的一些合理变更而导致的所有测试失败。（...）两年前，我们开始了完全重建测试的道路。

我们将开发和测试组织合并为一个统一的“工程”组织。在很大程度上，我们消除了编写代码和测试代码的区别。这并不是说每个人都要做相同数量的工作，但每个人都要做一些不同的工作，并对其所产出的质量负责。我们还决定完全放弃花费8年时间创建的数万个测试，并用完全不同的方式进行替换。”

这个团队评估了他们当前所使用的测试类型，并决定他们不喜欢现有的情况，即小型单元测试较少，而复杂且难以维护的端到端测试较多。因此，他们进行了改变：

以下是团队测试在两年时间内的变化的另一种可视化方式：

在两年时间内，几乎所有在测试与开发分离时的“旧”测试都消失了。新的测试也变得更加细分。数据来源：微软开发博客

那么，最终这一切的努力是否值得呢？根据Brian的说法，是的。他在当时写道：

“我们开始从提高质量、敏捷性和工程师满意度等方面受益。”