在软件开发的某个时期，专业化是必要的。在《How We Test Software at Microsoft》一文中，我们讲述了微软第一位测试人员的故事——他被雇佣通过新的编译器运行Basic编写的游戏。从那时起，测试与开发之间的分工关系就形成了。
几年后，吉恩·金（《The Unicorn Project》的作者，以及更直接的《DevOps Handbook》）谈到了开发人员和运维专家之间的相似分歧，并展示了如何打破这些壁垒以加快和改善软件交付。
思维的墙
我不是唯一一个讨厌用“DevOps”这个词来描述组织内部某个职位的人。DevOps不是需要所做的事情，而是一种工作方式。它最初是一个用来描述开发人员和运维团队合作的术语——来源于2009年的一次演讲——《10+ Deploys Per Day - Dev and Ops Cooperation at Flickr》。
这个概念很简单——合作与协同比把东西交给一支团队要高效得多。
那些从事过测试工作的人可能会看到其中的相似之处。微软的第一位测试人员后来发展成为一支庞大的测试团队。到了2000年代中期，微软拥有近10000名测试人员，尽管他们在产品周期的早期就参与进来，并与开发团队进行了合作，但整个公司还是发生了很多测试人员与开发人员之间的沟通不畅的情况。
如今，大多数成熟的组织都意识到，交接工作会降低速度并引入风险。因此，许多公司意识到，他们所需的测试人员数量远少于以往。开发人员自主测试已被证明与质量和交付高度相关。
同样，DevOps文化的兴起也催生了专注于“平台工程”或“开发者体验”的中央团队，他们构建工具和自动化基础架构，并在必要时提供专业知识，使开发团队能够更轻松地运行基于云的服务和应用程序。
早在2006年，沃纳·沃格尔就大力推崇“You Build It, You Run It”的文化。
让开发人员承担运营职责极大地提高了服务的质量，无论是从客户角度还是技术角度来看都是如此。传统的做法是将软件交付给开发和运营之间的隔离墙，然后将其扔过去并置之不理。但在亚马逊并非如此。You Build It, You Run It 使得开发人员能够接触到其软件的日常运营，同时也让他们能够与客户进行日常接触。这种客户反馈循环对于提高服务质量至关重要。
抱怨者
优秀的软件团队通过减少交接工作并负责产品的交付来提高效率和质量。但是有些开发者并不在乎这些数据，因为他们“不想做测试”，更“不想做DevOps”。
当然这些人有固定思维模式。
在《Mindset》一书中，卡罗尔·德威克谈到了这一点。她认为，人们对学习和挑战的态度是由固定型思维模式或成长型思维模式决定的。持有固定型思维模式的人认为自己的能力（或所做的事情）是固定不变的、与生俱来的。这些人会避免挑战，并对失败感到威胁。相反，持有成长型思维模式的人会将挑战和新想法视为学习的机会。
如果数据表明拥有更多软件测试和运维方面技能的开发者是有益的，而你的回答却是“这不是我的工作”，那么你的成长将受到限制，而且你的职业生涯也会受到影响。
学习者
在我的职业生涯中，我面试过很多技术岗位的候选人。发现那些长期取得成功的候选人的超级秘密是关注学习和心态。如果你想在技术领域取得成功，那么热爱学习、勇于迎接新挑战的心态与长期的成功高度相关。反之亦然。
有时候，开发人员不想学习如何测试或了解服务交付，因为他们认为自己高人一等，这是“别人的工作”。他们不相信数据，拒绝改变。
通常来说，“不想做”综合症是恐惧的。开发人员一开始害怕测试，因为他们害怕自己可能会遗漏一个bug。开发人员害怕运行自己的程序，因为他们害怕自己会以某种方式摧毁整个互联网或者造成其他无法弥补的损失。
我并不是建议每家公司都取消测试人员，专业技能是有益的——但要谨慎，因为这也可能成为瓶颈。你不希望开发团队依赖于其他团队——相反，测试团队、平台团队和开发经验团队应该加快这些团队发布高质量软件的能力。
测试团队的存在是为了帮助团队更好地进行测试，而不是替开发团队做测试。
学习、成长才能开发出更好的软件。
- END -
下方扫码关注 软件质量保障，与质量君一起学习成长、共同进步，做一个职场最贵Tester！
- 关注公众号, 后台回复【测开】获取测试开发xmind脑图
