不要让开发人员兼职测试的角色

作者 | Wolfgang Platz

译者 | 杨志昂

如今在持续集成 / 持续部署（CI/CD）中，软件测试开发工程师（software development engineer in test，SDET）越来越被认为是一个非常关键的角色。然而，也有一些人认为，由于系统不同组件之间的差异，SDET 这个角色可能并不一定适合每一种场景。

在微软首先创立了 SDET 这个概念之后，随着敏捷开发的普遍推行，又进一步模糊了测试人员和开发人员过去角色之间的差异，这固然是一件好事。因为当一切顺利的时候，开发人员就会执行更多的测试，并对产品质量承担起更多的责任。而测试人员在每个 sprint 前期就开始测试，而且由于有了共享办公空间和每日站会，在 sprint 循环里测试工作会一直保持运行。如果一切顺利的话，代码库中引入的缺陷会更少，测试人员的角色也会从对开发人员的错误单纯地吹毛求疵提升到主动拥护更好的用户体验。

然而，关于应该将多少测试责任分担给开发人员，以及对于测试人员来说了解编程有多重要，一直都存在着激烈的争论。并且，我个人认为，两种“合并”的提议，即开发人员成为测试人员，或者测试人员成为开发人员，都有可能会破坏敏捷的目标。所以，在这篇文章中，我讨论了为什么合并开发和测试角色并不可取，并描述了如何为开发人员和测试人员二者之间获取最佳的工作关系。

除了 GAFA 之外，其它公司让开发兼任测试都会影响创新速度  

谷歌、苹果、Facebook 和亚马逊并称为”GAFA“，因为这四家公司总是能源源不断地招揽到顶尖人才，所以他们永远时刻准备着以闪电般的速度让各种创新迅速进入市场。如果你是 GAFA 公司里 DevOps 团队的一员，当需要让现有的项目提速或者是启动全新的项目的时候，就可以从世界顶级的开发人员中任意挑选团队成员。你甚至可以奢侈地将顶级开发人员放到 SDET 角色上。在这些公司中，许多满怀激情的开发人员能勉为其难地接受 SDET 这个并不太理想的职位，但内心还是渴望有一天自己能成为这家理想雇主公司中的一名成熟的开发人员。

然而，在许多大型企业中，你通常没有那么多顶级开发人员来主动敲公司的门。而在这些公司里，通常需要上下持续不断的努力才能吸引和留住有价值的开发人员。因此，为了满足企业对软件永不知足的需求，得让所有能干活的开发人员都专注于开发任务，这件事情本身已经够困难了。这种情况下，如果还让一些开发人员去承担高级测试任务，付出的代价通常是公司承担不起的，而在这些测试任务上，就算不比开发人员做得更好，专业的测试人员也绝对是足以胜任的，。

最精益的自动化测试方法不需要编程技能  

现在的开发方法已经变得更加精益、更加轻量级，能辅助团队更快地生产出更多软件，满足业务目标。同样地，测试技术也有了长足进步，可以采用轻量级的无脚本方法，这样的测试架构也更适应敏捷特有的快速变化。然而，许多团队仍然固步自封地抱有陈旧想法，还认为测试自动化和几十年引入时一样，需要付出较高的维护成本，且测试主要基于脚本方法，但是交付的结果仍然差强人意（一般最多只有 20% 的自动化率）。现在几乎在所有的行业中，人们都已经开始使用通过对复杂程度的抽象来实现高级自动化的软件。因此，软件测试行业现在也是时候做出改变了。

我们在 Tricentis 咨询公司中对不同行业的企业环境的研究中，发现无脚本方法比脚本方法产生的可持续性自动化程度要高得多。此外，这些无脚本方法还移除了困扰敏捷团队最多的测试常见瓶颈，因为：（1）这些方法让人人都可以参与测试，这就扩大了可支持测试工作的团队成员范围；（2）由于这些方法有较高的可重用性和模块化，能更加容易地与快速演进的应用程序保持同步；（3）这些方法让人们解放出来，不用去维护一个仅仅为了测试生产代码而设计的测试代码库。

开发和测试都做测试工作，能更快找到缺陷。  

我保证，如果你同时让开发人员和专业的测试人员进行测试，你将更快地让那些关键问题暴露出来。我们都熟悉缺陷曲线，它显示了解决缺陷的时间、成本和工作量是如何随着时间推移呈指数级增长的。所以在可能的情况下，应该尽快挖掘出每个缺陷，这对单个 sprint 内的生产速率有很大的影响，并且可以避免之后部署现场报告的缺陷对未来的 sprint 产生影响。

“开发测试”是暴露编程错误的理想方法。针对为实现用户故事而编写的代码，这种测试会深入检查代码的功能和稳定性。这点是至关重要的。如果代码库里有一些低级错误，例如举一个简单的例子，一个乘数的小数点错了一位，直接使用开发人员的单元测试去查找和诊断这类问题，绝对比从用户角度用端到端的测试去检查功能要有效得多。

但是，如果你的测试主要是由开发工程师设计的自底向上的白盒测试构成的，那么这样又可能会忽略一些站在用户角度多半会遇到的关键问题。

新功能能否在更广泛的端到端的事务中做到无缝工作？如果用户以开发人员没有预料到的方式去运行应用程序，该应用程序能以合理的方式做出响应吗？在多重依赖项同时出现的情况下，你的功能是否能正确地执行所有的行为交互？由于专业测试人员会在实际的业务事务环境中严格地对各种核心功能进行测试，即自顶向下地以用户的角度来审查产品，这样将不可避免地发现许多问题，而这些问题通常在正式投入生产之前是不会被开发人员所注意到的。

因此，当开发人员与专业测试人员一起进行测试时，你将更清楚全面地了解与产品发布相关的业务风险。同时，在用户遇到高风险问题之前，你将有机会去解决掉这些麻烦。这也正是测试的最终目标——它需要多个角色之间更多的协作，而不是针对开发人员 / 测试人员谁该承担测试任务争论不休。

关于“辩论：SDET vs 测试人员”，这里有更多的讨论：

https://www.tricentis.com/resources/the-great-debate/

作者介绍

Wolfgang Platz，Tricentis 公司的创始人兼首席产品官，该公司于 2007 年成立，是一家测试咨询公司。他大力推动了软件测试方面的创新，例如基于模型的测试自动化，以及线性扩展的测试设计方法。

原文链接：

https://thenewstack.io/why-merging-testing-and-developer-roles-is-a-bad-idea

---

活动推荐

SQL 的性能问题一直是影响到金融系统用户体验甚至是系统可用率的关键因素。陆金所的解决方案为：基于陆金所数年的 SQLmap 代码、执行计划、生产运行监控信息、DBA review建议等数据结合 AI 算法训练和优化 AI SQLreview 系统。具体成效如何呢？推荐大家到ArchSummit全球架构师峰会（北京站）听听王英杰老师怎么说～

8折购票倒计时，限时立减1760元，团购更便宜哦～了解详情请联系票务经理灰灰：15600537884 （同微信）。