微软在上个世纪90年代的测试实践
事实上，这种方式有效么？
哪些方面不奏效
第一次转型：合并SDET和STE，大约在年
第二次转型：进入云节奏
云时代下，质量保障要何去何从？
通过组织变革达到质量责任转移
小心地做出改变
解决专业分工问题
速度提升
正文如下：一、90年代的测试实践长期以来，Microsoft都为每个软件产品都设定了一个基本的工程人员配置。每个产品团队都有三个不同的职能人员。产品经理（PM）负责了解客户需求并编写特性规范，开发人员负责设计和编码。测试人员负责测试。此时，人员比例基本上是产品：开发：测试=0.5:1:1，团队之间只会存在稍许差异。测试团队包括两个不同的角色：一是软件设计工程师测试人员（SDET），负责建设测试基础设施，和编写自动化用例等。二是软件测试工程师（STE），他们负责运行自动化测试用例或执行手动测试。我们找SDE候选人与SDET的候选人其实是相同能力模型的人。他们被录用时具有非常相似的资格和技能。如果是社招的话，我们通常会招聘开发人员，然后将其转为SDET。二、事实上，这种方式有效么？
过去，这种做法运作情况还不错。我们的Windows和Office等大型产品取得了商业成功。测试团队根据非常正式的质量度量指标，来确认产品是否质量达到了发布的标准。这让我们有信心宣布“可以发布产品了”。
测试团队在测试技术和工具方面建立了深厚的专业知识。此模型的好处之一是，当我们完成开发阶段，准备进行产品质量验收时，我们会要求测试人员出具非常正式的验收标准和正式质量度量报告。他们还在测试方面积累了深厚的专业知识，因为测试团队只专注于测试，并日复一日地进行思考这件事。
三、哪些方面不奏效
它真的奏效吗？一言以蔽之——无效。我们已经开始意识到了这种模式中的一些问题，但产品的商业成功在一定程度上掩盖了这些问题。
到90年代末，问题爆发了。开发人员将写好的代码直接丢给了SDET。SDET将写好的自动化测试用例抛给了STE。而我们通过不断增加STE的人力投入（尤其是供应商）来应对越来越多的工作量。STE在测试团队晋升的职业机会非常有限。
维护这种人员配置的代价是非常大的。
测试环节成了产品发布的瓶颈，并导致产品延迟，当然，我们此时也没能看破这个问题的本质。
四、第一次转型：合并SDET和STE，大约在年
到年，整个公司都意识到了这个问题。我们进行了测试团队的第一个重大转变。即：在公司范围内放弃STE这个角色，让SDET不仅负责开发测试用例，还负责运行和维护自动化用例。对于公司而言，这是一个痛苦的过渡。我们努力工作，将STE转移到其他角色，有的人做到了，但更多的人无法完成角色转换。
这改善了我们的团队职责模型。它改善了SDET的责任感，激励他们编写更好且更多的自动化测试用例。但是核心问题仍然存在。SDET无法跟上“墙”那边开发人员丢过来的新功能的速度。
此时，我们只能想到，用“延长产品整个发布周期中的验证阶段”的方法进行补偿。
对这个持续存在的问题的另一种应对方法是引入了称为MQ（QualityMilestone。质量里程碑）的概念。这是在一个新版本的发布周期最开始时，增加的一个特殊阶段，目的是填补上一个版本所遗留下来的所有测试债务。
这本来算是个好主意，但由于下面几个原因，它在实际工作中并不起作用。首先，由于它特意留下了一段时间用来提高质量，但这促使人们推迟在正常工作过程中偿还测试债务。其次，由于有这么一个专门用来提升质量的时间段，它促使团队进行一些相对来说比较随意的质量提升计划。这个MQ通常会导致优先级倒置。最后一点，由于这个阶段需要一个数量的固定人力进行质量提升工作，所以有时不好定义工作优先权，或者让本该做重要事情的人做一些低优先级的工作。
五、第二次转型：进入云节奏
随着年代中期，云时代到来，事情发生了巨大变化。因为微软原来是买套装软件的公司，云时代需要微软自己host云平台，给工程系统带来了新的压力，要求交付速度越来越快。那种有一个时间比较长的软件质量稳定阶段的时代已经过去了。我们无法通过Beta里程碑或“吃自己的狗食”（在Microsoft内部部署自己的代码）获得客户的认可。微服务需要独立且持续地部署。这些服务需要保持高可用性，并且必须支持无停机时间的部署。
最初，我们对这些新挑战做出的反应是：继续使用我们已知的做事方式，只是要做得更快而已。我们用更大的管理力度强行推动现有自动化测试用例的执行，为了让自动化测试用例执行得更快，更智能，我们的手段就是只执行那些我们评估后认为受代码变更所影响的测试用例。
当然，这种方法是行不通的。测试成为主要瓶颈——最终，我们还是达到了一个临界点。从理论上讲，我们是按照云时代所要求的快节奏进行工作的，但是，发布火车并没能按时发车。在AzureDevOps产品上，有时我们会在迭代结束后再花三个星期来稳定和部署——而三个星期正好是下一个迭代所应该有的周期时间。我们有效地消耗掉了一个迭代周期。
六、云节奏下的质量保障，要何去何从？
很明显，这种工作模型根本无法正常运作；我们做错了。其实，我们并不是第一个认识到这个问题的微软团队。在我们之前，还有很多产品，比如必应（Bing），就已经看到了这一点。我们开始观察云时代诞生的那些优秀公司的最佳实践。
在云时代的节奏下，如何改变产品质量保障方法？我们做了三件事。
重新定义了软件质量的所有者，我们修正了质量责任制。
为了频繁发布，Master分支必须始终保持与Release分支一样健康。我们定义了一个核心原则——Master分支一直保持可以随时发布。该原则涉及到软件开发中的方方面面——源代码管理，代码实践，构建等等。从测试的角度来看，我们推动了两件事：测试左移（即，更加强调单元测试）和消除不稳定的自动化测试。
我们的策略中必须有质量右移。在云时代，无法找到一个与生产环境一模一样的预发布环境，所以，我们建立了一套实践，既为生产环境保驾护航，又在生产环境上确保质量的。
换句话说，我们向左推动测试，也向右推动测试（左移右看），并去除了中间部分的大多数测试。这与过去那种“在中间发生的大多数测试活动（实验室中进行集成测试）”背道而驰。下面更多是描述了第一件事：质量责任主体的变化。
七、通过组织变革达到质量责任转移
我们进行了“合体工程（