阿列克谢·巴兰捷夫 （
Alexey Barantsev ）可能是俄罗斯测试中最著名的人之一：他不仅在
software-testing.ru和
selenium2.ru中 ，而且通过参与Selenium WebDriver而闻名。 同时，他还是最有经验的人之一：自1994年以来就一直在进行测试。 当得知他将在我们的Heisenbug会议上
发表题为 “ Selenium WebDriver中的故障”的演讲时，我们想请一位这样的发言人。 我们首先提出的问题是90年代的测试与今天有何不同，然后又转向现代现实。
-在面试的读者中，可能有些人甚至在您已经开始测试时还没有出生。 告诉我们，那一切与当今时代有何不同？-如果我们谈论测试的某些基础（理论，关键技术），那么就没有特别的变化。 但是同时，测试自动化当然也在不断变化。 新的开发技术应运而生，而随之而来的是用来测试软件的技术和工具。 一个人如何比较当时和现在的测试？ 无论如何，要进行比较，比较好-曾经是SOAP，现在是REST。 然后，我们测试了使用SOAP编写的Web服务以及现在使用REST编写的Web服务。 有什么区别？
-好吧，有些技术不仅“出现并消失了”，而且成为一种技术，如果没有这种技术，现在很难想象该行业：“即使没有Git，我们怎么生活？”-他们没有Git就能正常生活。 有CVS，我们过得很好，然后有Subversion，然后是Git。 这并不是很有趣，但是真正改变的是速度。 发展的速度，以及随之而来的测试速度。 甚至不是短暂的迭代，敏捷就是组织工作时间的方法。 正是产品开发的速度发生了变化。
在90年代中期开始工作时，我们的项目持续了六个月，一年，两年。 开发和测试。 然后这些项目开始减少到三个月，两个月。 实际上，在一年的两个月内就开发了相同的产品。 现在发生了什么：人们参加黑客马拉松，一天之内就开发出一种有效的产品，对其进行测试并发布。 显然，这仍然是原型，但是仍然可以使用一天。 这是无法想象的。
为什么会这样呢？ 当然，工具也在不断发展。 但这甚至不是工具的问题，有些仍然可以在vi或emacs中编写代码。 更重要的是，已经编写了许多现成的代码；已经对好的库进行了全面测试。 在某个地方，您仍然需要编写大量代码，开发独特的算法，并且在那里一切仍然需要很长时间。 但是在其他情况下，您可以像设计师一样快速地从成品中取出现成的组件来组装成品。 相应地，由于我们已经从可靠的经过测试的组件组装而成，因此测试起来也更加容易。 这已经改变了很多。
-人们的世界观发生了什么变化-我们如何看待测试/开发以及我们对他们的期望是什么？-在90年代，开发人员和测试人员对标准都有更多的信心。 实际上，敏捷并不是从无到有，只是因为所有这些标准都令人失望。
首先，有一个想法是标准将使我们免于劣质代码的困扰：我们将按照标准编写所有内容，并且所有内容都可以很好地工作。 也许这是正确的，只是标准的开发非常缓慢，一切很快就向前发展并在接受标准之前就已经过时了。
其次，我们有信心可以根据UML图正式绘制图，描述软件要求并自动生成源代码，所有这些都将起作用，甚至不需要进行测试。 假定很快开发人员将停止编写代码，而是绘制一些UML图并以某种高级语言描述条件。 它没有起飞，也没有解决。 尽管在我转过身的那个聚会上，对此进行了很大的赌注。
现在，某种新的浪潮可能已经开始：人工智能无处不在，无处不在，这种想法再次出现，即开发人员很快就不会编写代码。 取而代之的是，将对某些人工智能系统进行培训，并且一切都会自行运行。 因此，测试人员将无需执行任何操作。 开发人员将训练人工智能，他将竭尽所能。 让我们看看会如何。 也许它将像上次一样解决。
-让我们继续前进。 您正在使用software-testing.ru。 对于那些不积极跟随他的人：那里发生了什么？-我们发布了很多内容，现在主要部分是翻译内容。 坦率地说，因为在俄罗斯很难找到撰写有关测试的作者。 我不知道为什么会这样：有一段时间，很多人用俄语写信，然后他们的精疲力尽，或者由于某种原因，RuNet中没有足够的博客和文章。 在Internet的英语部分，所有这一切仍在蓬勃发展，那里写了很多文章。
交流逐渐转移到聊天室，即人们不写文字，而是交流。 这并不是说我们正在非常仔细地遵循这一趋势。 我们参与聊天，但不要试图引领这种趋势。 我们仍然按照老式的方式行事，试图为人们提供准确的内容，他们将找到交流的地方。
-现在人们也从文本转移到视频博客-但是测试中是否存在这种情况？-在测试中，这种趋势几乎是看不见的。 从字面上看，只有一两个视频博客，孤立的案例。
-有一个表达方式：“如果您想真正理解某些内容，请尝试向他人解释。” 当您系统地编辑其他人的文本时，您是否开始更好地理解您自己看不见的话题（包括角落）？ 测试人员也可以担任编辑器吗？-编辑工作与读者完全不同。 编辑者的任务不是要理解文本中写的内容，而是不要错过缺陷。 坦白地说，这不会带来整体外观。 当我们选择材料时，我会以读者的身份看待它：阅读是否有趣。 目前，我还不是编辑。 但是，当我们查看翻译的文本并准备发布时，在这种情况下，您将担任编辑。 这样，在编辑过程中，准备发布过程中，就会有所了解-这不会发生。 因此存在不同的模式：一种模式是编辑器，另一种模式是阅读器。
-轻率的问题。 在software-testing.ru上有横幅广告，但是在常规新闻中，很难通过它获利-在测试的情况下会更好，还是不能补偿您的工作，并且网站出于对艺术的热爱而存在？-没有广告收入不会补偿网站上的工作。 它的存在是为了创建图像，即图像，以便维持我们在网络上的存在。 培训中心从我们这里赚钱。
-下一个问题就是培训。 您多年来一直在教别人进行测试，但这如何影响您对自己进行测试的方式？-这里提到的原则是可行的：在向某人解释某些内容时，您自己也会有所了解。 它确实有助于更好地理解，理解。 第一次讲主题时，似乎一切都清楚了。 然后，您可以观看讲座，了解可以更好地讲述，重做的内容，还会出现一些新事物。 之后，有时我会写一些其他文章：首先，您准备本课程的材料，然后您了解到，您需要添加其他内容以使其更加清晰。 当然，获得某种反馈会更加有趣。 人们也在讲一些有趣的事情。 有人问您一个突然的问题，只有在这里您才知道自己不了解。 而且我根本没有想过要考虑的事情。 这很有价值。
-当您教很多人时，您开始注意到许多人典型的一些错误。 您可以制定一些一般的“典型测试仪错误”吗？-任何人通常都会犯的一个典型错误是，大多数IT人员都试图从自己的经验中学到所有东西，经历所有磨难。 从我的角度来看，以一种不同的方式前进是更合乎逻辑的：学习一些东西，然后再进行这项工作。
在这方面，我是一个非典型的人。 当我购买一些家用电器时，我首先要坐下来阅读说明。 因此，将我自己的心理经验传递给其他人对我来说是相当困难的。 我知道，是的，大多数人都不是这样，他们先绕过耙子，然后才开始想办法避免这种情况。 我认为这是错误的，他们认为这是正确的。
-现在我想问一下硒。 Selenium Driver社区及其周围的整个生态系统如何进入社区？ 有没有步骤和成就？ 例如，“执行十个请求请求并转到下一步。”-没有标准程序，没有法规，没有特定的选择标准。 一切都是完全独立的。 当您发现某个人已经参与其中时，便会逐渐获得更多权利。 每个人的登录过程都不同。 有人开始纠正错误并发送请求请求。 然后有人开始对邮件列表中的用户进行响应：我们有一个人员负责与根本没有对代码的任何提交但实际上持有邮件列表的用户一起工作。 有人在写文档-
这是一项涉及到源代码的任务，但是，当然，大多数人特别是通过请求请求来感知参与项目。
拉取请求存在组织上的问题，这与我们没有足够的工人这一事实有关，因此拉取请求可能会说谎很长时间，并且没人考虑。 因此，您必须坚持不懈，才能受到关注。 您不仅需要发送拉取请求，还需要打破请求。 那些突破此筛选条件的人便设法逐步进入该项目。
-向谁写突破？-是的，给大家写信。 在IRC聊天中，要求评估请求请求。 通常，人们会逐渐使用非技术性过滤器。 而且，如果您提出了拉取请求并等到被邀请加入该项目，那么不会，他们不会。
我直觉上想假设，如果要开发一种在测试人员中非常流行的工具，那么它本身已经比一般的IT项目进行了更彻底的测试。 Selenium示例是否证实了这一点？-我不了解“平均项目”，但是Selenium确实经过了彻底的测试。 有很多测试，测试一直在工作，他们一直在寻找bug，包括回归bug，包括浏览器中的回归bug。 我定期向浏览器开发人员撰写错误报告。
在我看来，测试的情况相当繁荣，尽管我不能说到处都是完全系统地编写测试：毕竟，在过去的20年中，它们也有机地增长了。 如果您是从头开始编写它们，请仔细阅读规范并进行设计，那么可能最好以其他方式编写许多测试。 但是到目前为止，还没有人想过坐下来完全重写测试的某些部分，有机成长的测试正在解决他们的任务。
-通常会出现“哪种浏览器更好”的争议，并且由于您向他们发送了错误报告，因此从非标准方面进行比较很有趣：哪些浏览器对错误报告的响应最佳，哪些浏览器的响应较差？-我不想得罪任何人，所以我不会批评任何人，但是我可以赞美。 Firefox开发人员的反应最佳。 在处理错误报告方面，它们是最参与，最活跃的。 也许恰好符合他们的开源精神。
而且最烦人的不是团队对错误报告的反应。 这就是开发封闭代码浏览器的公司（Microsoft，Apple）具有封闭的bug跟踪器的原因。 也就是说，遇到错误时，您看不到有人是否已经发送过此类错误报告，这是否是已知错误。
-几年前，您曾说过Selenium的任务是成为Web标准。 他成了，然后呢？ 下一个重要的里程碑是什么？-面对自动化工具，掌握世界。 也就是说，我们需要确保支持所有此新标准。
-也就是说，要成为所有其他新的UI自动化工具的内置模块吗？-是的 也就是说，他们可以再使用十个其他模块，但是它们都应该能够通过标准协议工作。
在Selenium内部有以下重要任务，将首先通过一些原型实现来解决，然后在该标准的框架内解决。 HTTP协议基本上是单向的，也就是说，一侧发送请求，另一侧处理请求，实际上没有反馈。 而且这还不是很好，而正是在这里，竞争对手非常积极地指出了这一点，给这个痛处施加了压力，因为我粗略地说，我希望回调。 当浏览器中发生某些事件时，我希望收到一些有关此事件的通知。 Selenium工具中还没有此功能。 但是我们真的要添加此内容。 因此，也许会发生主要变化，协议可能会发生变化。 没有这一点，将是困难的。 我们需要双向协议。
“你和西蒙·斯图尔特是硒的主要贡献者，对吗？”-对于Java部分，这是正确的。
“据我所知，您从未见过面。” 怎么发生的？ 硒开发者没有任何“公司”吗？-我们以“会议”的形式召开“公司聚会”，但分开进行-不。 就会议而言，西蒙甚至于去年的海森博格（Heisenbug）来到了莫斯科，但那一刻我不在莫斯科，所以我们没有相交。
但是，坦率地说，我们现在生活在一个可以的世界中，我们仍在不断交流。
-最后一个问题。 您认为总体上，尤其是UI自动化测试的未来会如何？-我不喜欢做预测，因为它们几乎永远不会成真。 测试落后于开发，有些滞后。 因此，开发人员决定了这种方式：他们友好地融入JS-在测试中，所有人也友好地融入JS。 我们将需要跟上变化。 开发人员将拥有什么-谁知道。
Alexey 将于 12月6日至7日在莫斯科Heisenbug 演出 -除他外，还将有数十名其他演讲者。 在Heisenbug网站上，您可以查看完整程序并购买票证。