可以自动化任何东西吗？ 然后，我们当然会解雇所有测试人员。 为什么现在需要它们，所以没有“手动”测试了。 毕竟吗
这是一个关于DevOps的测试未来的故事。 将有具体的数字和纯实际的结论，证明好专家总是有工作。 （或者没有工作！看看莎士比亚的照片，并担心，您的命运现在将被决定）。
该材料基于JFrog开发者倡导者Baruch
jbaruch Sadogursky的报告抄本。 报告的文本版本和视频已删节。
大家好！ 在上图中看到莎士比亚的名言吗？ 这是亨利六世杀害所有律师的提议。 您知道，从那时起，我们有了更多素食方法来摆脱错误的职业。 我们不会杀死任何人，只会杀了它并解雇所有人。
更准确地说，就是这样的机会。 我们会解雇一个人吗？
这是Vasya。 一天早晨，他来上班，走过主要会议室。 他的老板在那里欢迎一位新顾问。
一位效率顾问来到公司说：“我们将像在netflix中一样进行DevOps *。 我们专门飞往硅谷参加会议，并在那儿被告知他们在netflix的情况。”
*免责声明：Netflix在本文中经常被用作DevOps难以企及的理想。 此用法是家喻户晓的单词。
关于Netflix是否真正具有完善的DevOps的讨论不在本文讨论范围之内（顺便说一句，没有）。
他们安装了Spinnaker，然后启动了Chaos Monkey，一切都自动化了。 我们将做到这一点，并且将非常有效。
老板问，测试人员呢。 “在这里，就像在netflix中一样，
自由与责任 。 开发人员将自己编写测试。”
然后Vasya生病了，因为他看着自己的名片，然后在那里...
Vasya开始担心：上一次效率顾问到来时，他的朋友Natasha被解雇了，他是系统管理员。 因为到处都有DevOps。 然后他意识到很快一切都会变得很糟。
但是，当然，然后Vasya醒了。
我叫Baruch Sadogursky，我是JFrog的开发倡导者。 本文的编辑特别要求写几段文字，以便没人怀疑我有权告诉我们我们将如何解雇测试人员。
JFrog是硅谷的一家初创公司，我们的最新估值超过10亿美元。 我们是正式的
独角兽 ，我们从事DevOps自动化。 我们的产品
-Artifactory ，
X射线 ，
任务控制等-用于将鄂木斯克肉类加工厂变成netflix的高度自动化的工具。
我本人不是测试人员，所以也许我会讲些废话。 在最初阅读本报告的会议日程中，有一个特殊的名称-一张带有莫洛托夫鸡尾酒的照片。 因此，演讲者将带有某种异端，因此听众会发烧。 这是关于我的。 在Twitter上，我是
@jbaruch 。 如您所知，我是一个非常开朗的人，我迫切需要关注。
我有个好消息：80％的开发人员编写测试。 开发人员对各种民意调查感到满意。 好吧，JetBrains对出色
的《开发人员生态系统报告》感到满意。 他们问谁编写单元测试。
- 59％的人自己写
- 11％的人在其代码中看到了单元测试，并且不知道它们来自何处。
总共有70％的开发人员使用单元测试。 太棒了
Hubstaff对开发人员进行的测试进行了更深入的
研究 ，但该研究有些陈旧-2014年。 据他说：
- 85％的开发人员编写单元测试，
- 15％否；
- 40％根据测试驱动的开发方法进行工作；
- 良好的覆盖率-31％的开发人员中介于34和66之间。
绝大多数开发人员声称他们还使用笔进行测试。 它们当然是谎言，但统计数据如下。
自2011年以来，我们最喜欢的报价是：
“每个公司都是软件公司” 。 当然，包括Vasya所在的鄂木斯克肉厂。 到处都有软件，并且使用此软件的每个人都在试图赚钱。 公司想要什么？ 用铁锹划破战利品。 钱从哪里来？ 来自满意的客户。 客户想要什么？ 新功能。 他们什么时候想要新功能？ 现在！
漫画书的首席执行官Dilbert是Vasya的老板。 他还听了各种各样有趣的报道。 他认为，如果客户需要新功能，则他们需要更频繁地发布新功能。 是合乎逻辑的。 为此，减少团队之间的摩擦。
我应该释放更多吗？ 例如，在2017年，Java切换到了更频繁的发行版，因为每个人都想要功能，而且似乎还需要更快地发布它们。 每六个月就会出现一个新的Java。 但是没有人使用它。
我们最近有Joker，我们在上面托管了
Java Puzzlers 。 在开始时，我们总是询问谁在使用哪种Java，以便了解要提出哪些难题。
情况没有改变：80％甚至更多的人仍在使用一百年前发布的Java 8。 没有人拿第九，第十，十一。
要了解为什么他们不使用它，您需要了解我们如何决定是否进行任何更新。 让我们想象一下，如何根据需要放置任何更新-操作系统，应用程序，浏览器。
我们如何发布更新
收到更新通知，让我们安装新的操作系统。 我们要这个吗？ 那里有用吗？或者我们有一个运行在Windows 98 Embedded上的收银机，并且我们不需要其他东西吗？
如果我们想要此更新，下一个问题是它有多危险。 当Facebook更新时，这是一回事，我们一直在滚动，我们无法喜欢。 当医院关闭生命支持系统时，这是另一回事。 如果我们不对风险一窍不通，那就更新一下。 如果存在风险，那么问题就在于信任发布更新的人。
苹果以前没有问题：有一个新的操作系统-让我们开始吧。 以前，现在我们害怕被更新，没有以前的信任。 如果我们信任-没问题，我们正在更新。 如果我们不信任，则需要测试。
我们进行所谓的验收测试。 他们在这里告诉我们：一种新的Java出现了，例如，我们是百度。 高负载，100,500台服务器，云，无处不在的JVM。 我们使用了部分服务器，开始更改Java。 一堆工程师必须做点什么，然后全部检查出来。 每三年一次，这是正常的，但每六个月一次。 我们只会检查六个月。 当然，我们不会将此作为您的新Java。
因此，如果我们可以快速检查，则值得进行更新。 但是，如果您需要检查很长时间，则可以跳过几个版本。 如果我们立即从第八版爬到第十二版，什么也不会发生。
问题在于信任。 如果我们不信任，那么更新将很困难。 如果信任问题已解决，则更新没有问题。 我们有一个功能，或者我们不该死。
使用Chrome。 他从某个版本开始更新，完全不问任何人。 那里的风险很小，但仍然存在。 但另一方面，我们相信那些编写Chrome的人。 通常，当新的Chrome版本发布时，一切都不会中断。 实际上，我们在信任方面没有任何问题，并且我们正沿着这条道路前进。
我们有更新，风险不重要，我们相信-我们会更新。 而且他们不会问我们是否要，因此我们将始终进行更新。 这正是正在做的事情。
想象一下netflix正在推出新的更新，现在我们不仅可以跳过字幕和屏幕保护程序，还可以跳过所有无聊的地方。 酷更新？ 好酷 我们要他吗？ 我们要。 能行吗 很有可能。 在极端情况下，我们将转到YouTube，如果netflix损坏，请看动画片。
信任问题至关重要。 我们该如何解决？ “我们”一词是指JFrog的两位联合创始人，弗雷德·西蒙（Fred Simon），约夫·兰德曼（Yoav Landman）（约阿夫·兰德曼）和您的谦卑仆人。 我们
写了一本书 ，建议如何解决这个问题。
假设我们说服了我们的首席执行官，他读了Liquid Software，现在他明白为什么需要更新了。 他问顾问，我们将如何更频繁地更新。 敏捷！ DevOps！ 什么是DevOps？
开发者
让我告诉您有关什么是DevOps的一些理论，因为我们可以从中赚钱。 看一下图片，我们有以下小组，团队，部门：
有开发人员，也有Ops-系统管理员，他们接受开发人员编写的内容并将其扔到产品上。 在Ops开发人员之间的中间，有正在测试的QA。 也就是说，开发人员坐下来，编写，然后将其带到测试人员，对其进行测试，然后将其分配给系统管理员，然后将其上传到产品中。 为此，我们有独立的部门。
俄语很漂亮：部门总是
分开的 ，这是单词的根源。 用英语来说，这种魅力不是，因此，这些不同的部门称为
筒仓 。
DevOops的最佳
发言人安东·魏斯（Anton Weiss）给出了将这个词翻译成俄文的最佳
方法 。 他称筒仓为“井”。 不同部门-深井。 要在这里加载一些工作，您需要先下降，然后再从那里拉出工作-上升。 分组进行此操作最方便。 我们如何将我们从井中收获的事情归类？
自然地，在水桶里。 也就是说，我们有这样的“工作桶”。 开发人员在井中写东西，我们将其装入桶中，将其从井中取出，然后将其运送到测试人员手中，然后将其放到井中。
为了在不同的井之间转移工作，已经做了很多动作。 当我们将任务分组以节省这项工作时，我们开始加载这些存储桶。 当然，存储桶越大，我们将在此转移过程中节省更多。 因此，桶变大。
大桶有什么问题？ 他们填补了很长一段时间的事实。 因此，当我们有需要紧急发布的重要功能用于生产时，因为有大量的有钱人，我们就不能这样做。 我们有水井，更好的是，我们可以在水桶中收集更多水。 因此，只要我们有足够的能力来填补这些空白，重要的功能就在等待所有的废话。 如您所知，这很糟糕。 我们通过混合所有这些井来解决这一问题。
这不是我的错！ 我只用了三种原始颜色，将它们彼此叠加，结果原来是这种颜色。 现在我们都做一切。 我们有这样的工程师，既是Shvets，Reaper和Dyuras。 这些是开发人员，质量检查人员和操作人员。 他编写并测试了代码，然后将其全部投入生产-这样的独角兽。
独角兽有什么问题？ 他们不存在。 和那些已经存在的公司，它们早已被netflix雇用。 因此，仍然需要我们进行混合。
混合物
我们有共同的文化，共同的目标。 我们离开了井，我们现在在一起了，但是我们仍然具有深厚的专业知识。 与Ops相比，开发人员仍然是开发人员，测试人员而不是开发人员更是测试人员。 不过，他们了解一切。 他们了解自己在做什么，为什么这样做以及它是如何工作的。
也就是说，我们有T形的人，“字母T形的人”。
他们具有深厚的专业知识，非常了解自己在做什么。 他们非常了解，其他一切也都知道。 例如，开发人员对如何正确测试，如何对产品进行布局等有所了解。
DevOps是：
- 我们现在有共同目标的文化，我们了解我们一起做的事。
- 自动化发布更加频繁。
速度与品质
让我们谈谈速度与质量之间存在反比关系的假设。 粗略地说，我们发布的越快，质量越差。 反之亦然：如果我们不着急，我们将有时间彻底测试所有内容。 我们有一个权衡！
为了了解这种依赖性是否确实存在，让我们
来看一下科学论文，并讨论DORA组织
的DevOps状态报告 。 我强烈建议您仔细阅读这份报告。
你有多信任他？ 该报告称，五年内接受了五千多人的采访，2018年将近2000人。 这是一个非常大的样本，例如，基于此数量，在美国大选中会做出预测。 因此，研究是可以信任的。
此外，与我们不同，负责DORA的妮可·福斯格伦（Nicole Forsgren）是一位科学家，所以那里的一切都很认真。 让我们看看DORA告诉我们有关这种逆相关的信息。
首先，他们将所有受访者分为三类：低绩效，中绩效和高绩效。
此外，还有精英。 这是Netflix（实际上不是，请参见上面的
免责声明 ）。
如您所见，比例正在变化。 自然，五年前，有更多的低绩效者，现在有更多的高绩效者，因为我们已经开始了解我们在做什么。
这有点奇怪。 事实证明，使用“ Low”以外的手柄正在测试“ Medium”。 怎么了 是的，因为Low根本不测试任何东西。
它们有一个趋势，称为J曲线的图表，它显示了速度和质量之间的正相关或反相关。 这里的一切都很奇怪。 在某个时候，我们看到这种反相关的确认。 也就是说，我们发布的速度越快，质量越低。
但是，相关不仅是逆的，而且是直接的。 我们发布的越快，我们的质量就越好。 假设我们是中级并且使用笔进行测试。 一切都不错，但是很慢，因为我们相信，如果我们不着急，我们会更好地测试一切。 然后来自DevOps的顾问来对他说：“就是这样，现在我们正在使其自动化。 而且我们不需要测试人员。 一切都很好。”
但是没有测试，这是胡说八道。 当我们意识到需要对所有东西进行测试，并且必须正确进行自动化之后，我们才开始正确进行自动化，并继续努力争取更高的高度。
必须正确解决存在许多错误的这种故障。 如何进入它，我认为没有问题。 问题是如何摆脱困境。
我们需要回答如何在没有手动测试的情况下生活。 答案与不设置服务器如何生活的问题相同。 显然可能。 有什么变化？
以前，我们有一名系统管理员为产品推出产品。 他坐下来，等待开发人员完成写作。 之后，他拿起了该产品，然后去插入CD-ROM并粘贴电线。 此时其他所有人会发生什么？ 其他所有人都在等待。 这是一个瓶颈，堵塞。
我们通过正确的自动化解决此问题。 我们使流程自动化，我们预先准备了一个管道，现在产品在完成写入后会自动推出。 这是否意味着现在不需要这些人了？ 不行 这意味着它们是必需的，但是他们在做其他事情。
与测试相同。 我们有测试产品的测试人员。 他们等到写一个产品。 写-是时候测试了。 其他人在测试时会做什么？ 他们什么也不做，他们在等待。 我们该如何解决？
再次，正确的自动化。 我们正在建立一个流程。 他将保证产品的质量。 我们可以提前准备此过程，然后自动测试产品。
- 例如，这需要跨职能的团队 。 在这里，我们从井里站起来，一起坐下。 现在，我们有一头狮子躺在羊身上，测试人员与程序员一起工作。
- 我们进行持续测试 。 这就像自动测试，但更智能。
- 在开发过程中，进行了“大脑测试” 。 这是比“手动测试”更正确的术语，因为手动测试是关于大脑的，而不是关于手的。 谢谢你这个词对我在Facebook Alexey Vinogradov上的双胞胎。 在开发过程中会进行大脑测试。 一旦出现某种情况，您就可以检查其流程，已经了解其工作原理，可以开始勾勒一些极端的情况，然后我们将其自动化。
- 我们现在正在关注开发人员。 如果他一开始没有写测试，我们可以给他打耳光。 这是测试驱动开发 。
- 即时反馈很重要。 我们应该有一条管道，一旦出现问题，它会立即告诉我们。 因为我们必须立即修复并立即修复。
- 参与设计 。 碰巧您看了一些东西，然后思考我们现在将如何测试这种情况。 但是，对不起，当每个人都决定要拉屎的时候你在哪里？ 您参加会议并说您不同意，您必须在不知不觉中这样做。 您需要参与设计，以确保以后可以测试。
- 工具，安全带，支架 -今天您所做的很多事都没有。 相反，这将更多。 因此，有人应该写这个。
- 混沌工程 。 您一直梦想着在生产中启动Chaos Monkey，尤其是在Windows 95上拥有ATM网络的情况下。这是您的机会。
- 最后，您需要教导无知的人设计测试 。 我们认为开发人员至少声称他们编写了测试。 现在让他们编写测试，只需要我们教他们如何做。 谁来教他们，他们怎么知道如何编写测试？ 只有你 没有人
它仍然可以使一切自动化。 实际上，我们可以使测试自动化。 问题是您可以使某个零件自动化。
大家都知道这个关于测试人员如何进入酒吧，订购啤酒，订购0啤酒，订购99999999999啤酒，订购蜥蜴，订购-1啤酒和订购的笑话...这是一个错误，因为它应该是asdfgh，而不是这个废话
它很容易实现自动化。 显然，这些数字根本没有问题。 我们放了一个随机器，他对我们做了。 今天，即使在那里也已经产生了蜥蜴。 这很令人困惑-希望您听说过它，因为我昨天读过它。
但是随后客户来了，问厕所在哪里，所有东西，酒吧都烧了，所有人都死了等等。 这不能自动化。 好吧，您可以，但是首先您需要头脑清楚，酒吧不仅是饮料所在的地方，也是厕所所在的地方。 此外，服务对象想要上厕所的机会比订购蜥蜴的机会要多。 因此，进行检查更为重要，但是为此您需要了解业务，需要了解产品，并且只有有头脑的人才能做到这一点。
, , , . DevOps. , . T- — , .
, - . « », , . , , , . , Selenium . , .
, .
— . , , . . , , Ops- , , , , , , , .
Developers in test — , , . , . , ; — , ; TDD , , , , . , , .
« ». , , , , , — . , , , , , , , , , , Continuous Testing .
end-to-end , . , , DevOps, .
, - , . , 70- : « DevOps, ». , , .
. -, , , , , . : ( EVP Engineering, SignalFx) , , .
70- . . , , . , . , , , , . , , , , — , netflix .
, , , , , , , , , . . , .
, . . « , », — , , .
«, — . — : , , , . , , , , , . . , - , . ? Artifactory , ?!».
, — , . , . ? !
DORA: , , , .
New Work. , New Work Low — 30%, Medium — 40%, High Elite — 50%. ( , Low) , , .
.
Heisenbug 2018 Moscow, — 17-18 Heisenbug. , . , ( ).