这样啊 2018年，在Heisenbug（莫斯科测试会议）上，Baruch Sadogursky（JFrog的开发倡导者）发表了有趣的主题演讲，他在演讲中谈到了他的基本想法。 2019年，在同一个Heisenbug上，他就如何实现这一目标举行了报告续集。 一方面，我想支持他播出的B. Sadogursky运动的版本，但首先我还是不知道，其次，我将冒险根据自己的经验制定自己的愿景并描述我的个人道路。
给定
对于上下文（它是虚构的，与实际案例的任何巧合都是纯巧的巧合），我们将介绍一些具有较大开发部门的区域性IT供应商公司。 在这个单元内有一个测试功能，该功能由30名具有不同知识和技能水平的人员组成。
公司介绍
所介绍的公司有许多产品已经发布了很长时间，并且其开发的初始阶段已经在7-8年前完成。 考虑到该公司是供应商，它会监视其产品并定期开发它们，但不会从头开始对其进行翻新。 这意味着产品包含大量的遗留代码，“古老的”技术和体系结构解决方案。 在按照“更快，更快并且在生产中”的原则进行产品开发之前，没有考虑对这些产品进行初始阶段的测试，但是今天有大量的手动测试-回归测试和测试新功能。 从意识形态上讲，产品开发是在业务需求的压力下进行的，因此没有时间重新思考意识形态和重构产品本身。 仅在每个人都知道这与“完全”一词不再起作用时，才进行此操作。
除旧产品外，该公司还使用最新技术和体系结构方法开发全新的解决方案。 但是在这里，并非所有事情都是顺利的，因为来自业务需求的总体压力并未减弱。 在开发的早期阶段就已经进行过此类项目的测试，但是，“手动解决方案”仍然占主导地位，它可以提供最快的结果，并允许开发人员仅编写产品代码而无需考虑如何测试。
测试功能
现在，关于结构的几句话：正如我说的，大约30个人是测试功能的一部分。 其中，17-19岁是与该领域经验不超过1年的初级纽带。 通常，这些人没有受过技术教育，但是有着“灼热的眼睛”，并且非常渴望在IT领域工作（为什么他们有这种愿望是一个单独的讨论话题）。 其余的11-13人是高级和中层管理人员：3-4人代表高级管理人员，而7-10人代表平均水平。 整个测试功能分布在13-15个不同的产品/项目中，参与程度，复杂性和参与程度不同。
文化文化
这是最后的介绍。
不幸的是，对于测试功能可以带来的价值仍然存在一些误解。 这是因为以新功能形式出现的工作结果（例如）对所有人都是可见的，可以理解并且实际上是“有形的”-实施后，产品的整体质量将提高，并且至少对于公司的产品不会感到尴尬。 同时，有些狂热的开发人员认为以下陈述是正确的：“开发人员是主要参与者，如果他不在场，则可以解雇其他人”，以及“开发人员是一种昂贵的资源，他们应该只编写产品代码，而不要因不重要的活动而分心”。 基于这些陈述，该公司已形成某种“文化”。
问题陈述
正如他们所说，这是什么问题？ 如果一切正常，为什么要更改某些内容？ 如果有可行的模式，为什么要搬到某个地方，并带来好处呢？
从逻辑上讲，这些问题可能发生在为整个发展付出代价的人中。 但是在测试职能部门中，有3-4个人认为自己被低估了，他们看到了B. Sadogursky的第一份报告，不仅看到了情况的相反方面，而且还想改变正在发生的事情，并因此解决了一些问题生病”问题。
下一步-纯粹的幻想和建议，基于IT领域不同作者和专家的资料。
解决方案（可能）
让我们从在变更框架内定义目标开始。 我们将有意识地忽略重商主义的一面，而不是提出它，这对大头菜是一个单独的主题，特别是因为它在该公司的当前状况中发挥了重要作用。
我们描绘了未来。 我们追求什么？
首先，我们希望在短时间内获得可带来相当高利润的高质量（！）产品库。 您需要了解“赢利”并不意味着“质量”。
我们需要做什么才能达到目标？ 首先，我建议从技术而不是商业的角度考虑路径。 为了实现该目标，有必要关注以下事实：产品必须满足最终用户的需求，同时在开发新功能和维护已投入生产的产品方面具有低成本。 也就是说，在开发过程中，我们必须：a）清楚地了解运动向量，b）使产品足够可靠，以使其操作没有问题，简单来说，请确保用户使用产品时没有错误。 基于此，我们应该对所有产品都拥有所谓的“零错误政策”，也就是说，作为一个过程，我们的测试应保证没有生产错误。
第二方面的重点是整个开发过程的最终结果，这将使我们无法开发用户无法使用或无法理解如何使用的内容。 我们仅在顺便提及第二部分，因为该主题非常广泛，但是如果不涉及它，它将无法工作。
因此，我们的目标是：
“ 快速，高效，合理地赚钱 ” （很可能，您不可能立即做到这一点）。
现在，让我们尝试将给出的内容与预期的目的相关联。
快点 是的，这是可能的，但是我们会危害质量：现有的手动质量保证流程将只能在具有简单用户案例的小型产品上提供足够的执行速度。 此外，公司的形象是开发用于业务流程自动化的相当复杂的解决方案。 结论-“快速”不起作用，因为先验的体力劳动将无法使用任何自动化解决方案。
注重结果 。 这是可能的，但它要求参与者产生足够深的沉浸在主题区域中的值，并花费大量时间将其传递给最终执行者。 同时，执行者是开发人员，他们作为语句之一的一部分，应花费最大的时间编写代码，而不会受到环境的干扰。
由此可见，为了解决主要问题，不仅需要质量检查专家，还需要开发人员参与测试过程。 同时，为了提高价值交付的速度，有必要更仔细地考虑交付自动化和对所交付内容进行验证的自动化过程。
解决主要问题需要做什么？
我个人认为，根据经验，它要求：
- 使开发人员更沉浸在他们产品的产品目标中；
- 使企业确信自动化成本很重要，并为所有经济成本提供更多的经济利益。
- 明智的做法是使所有可以自动化的东西都自动化，从而将手工工作从价值传递过程中排除到最大程度。
- 实施零错误政策，否则用户将面临排斥我们产品的问题。 顺便说一句，“ DoDo”的成功例子表明这是可以实现的。
我们需要做些什么来说服参与者改变态度和世界观的必要性？
开发者
如何争论-他们为什么除了自己喜欢的功能代码编程外还需要做其他事情？ 我建议直接关注此类组织所产生的问题。 其中有几个：
- 开发没人需要的东西。 恕我直言，这是第一个问题。 开发人员正在做某事，保持对自己做对的信心，但最终他们得到了最终用户想要的错误结果。 怎么了 因为任务和问题不是由最终使用产品的人员传递给他们的，而是由后来不使用这些产品的经理或客户传递给他们的。 为什么会这样呢？ 所有人都有不同的看法。 如果开发人员不是纯粹的技术人员，而是要在输出端对结果进行描述的功能性任务（甚至更好的是，对该任务应解决的问题进行描述），那么对结果的理解就会更多，因此，开发某些东西的案例数量也会更多不必要的会减少。 是的，这是一个众所周知的事实，但是问题仍然没有解决，需要与业务部门一起解决，以略有不同的方式证明制定发展任务的合理性。 关于如何将其传达给企业-进一步。
- 需要在上下文之间切换。 通常，在存在手动测试的开发过程中，测试结果会很晚，因此，开发人员必须分散注意力以解决由于测试而出现的问题。 是什么阻止开发人员在实现自己的结果后进行检查？ 有两点。 首先是缺乏质量保证领域的知识和技能。 第二-开发人员经常认为这不是他们的工作，因此，它不想这样做。 在RadioQA的早期播客之一中，有一个关于没有测试人员的开发的完整问题，该问题足够详细地描述了这种影响以及这种“不情愿”的原因。
测试将如何帮助开发人员或如何帮助他们解决所指出的问题？
- 获取有关主题领域或要解决的任务目的的更多信息。 开发人员在介绍任务时会问什么典型的问题？ “如何执行此操作？”“在这里需要做什么？”“尽管仅知道这一点，如何执行此操作？”“这将如何影响该功能？”所有这些问题旨在阐明任务的执行 ，并且不了解这项任务的可变性。 当测试人员熟悉新功能的新描述时会做什么？ 他还问了一些问题，但方式略有不同： “如果发生什么情况？”“为什么要这样？”“我到底应该得到什么？”“一开始我要得到什么？”“这应该如何关联？那样吗？” 也就是说，几乎所有问题都旨在准确识别用户场景并了解此功能的结果。
重要的是什么？ 通过不仅要问清楚问题（如何实现），还要问一些旨在理解最终结果的问题，您可以获得有关任务的更多信息，不仅可以期望所熟悉的方法，而且可以更简单，更有效。 在积极的情况下，这将有助于避免编写额外的代码或准确创建最终用户的需求，而这正是我们所需要的。
有人会问：“作为开发人员，我为什么要对此感兴趣，或者我应该考虑一下？” 我们将回答-为了避免“陷入困境”。 对我的环境中的开发人员进行的一项调查结果显示，您做某事但不发布它（将其放在架子上）时有多大的动力。
- 另一个问题： “作为开发人员，如果我们有测试人员， 为什么我需要进行 测试？”或“为什么我需要开发一些不满足设定产品任务的其他代码？” 。 在这里您可以提供其他东西。 自动化测试本质上是与遵循相同编程规则的代码略有不同的代码。 当开发人员在大型产品的框架内工作时，他必须服从产品中选择的开发规则和技术，并以使用该产品所使用的框架编写该产品所使用的语言来编写。 编写测试时不必这样做：没有人会强迫您使用相同的语言或相同的方法：实施自动测试时，您可以轻松尝试一种全新的语言并获得使用经验。
开发人员在编写产品代码时遵循一个简单的规则-最大限度地优化您的工作，优化资源消耗，优化性能，（最好是）最大程度地重用等等。 在开发自动化测试时，也有规则，有模板，有框架，但是它们是不同的。 他们的任务是使他们能够尽快制作测试代码，这将正常工作。
自动测试中的优化和执行速度是次要点，不会立即被记住。 因此，如果您突然想尝试使用Kotlin，Java或任何其他语言，但是该项目使用与所需语言完全不同的语言编写（例如，使用C＃），则可以通过开发自动测试将其更改为所需的语言。
- “我该如何测试？ 我对此一无所知。 我只是一个开发人员。” 在这里，测试人员将是急救人员，或者是QA工程师，他们非常了解编写主要产品所依据的所有技术。 多亏了他们的知识，他们可以帮助开发人员了解如何进行测试以及如何测试，如何选择正确的数据，数据生成器应该采取什么措施以最大程度地降低按类型划分的风险以及您根本不应该注意的内容。 在这种情况下，测试人员会充分利用自己的知识，而开发人员不会做不必要的工作。
- “但是速度呢？ 她在受苦！” 是的，她将在项目开发的初期遭受苦难，是的，当然，从一开始就投入完全自动化是很昂贵的。 怎样才能使成本最佳？ 至少，我们必须清楚地了解如何以及如何自动化。 而且，不要无所顾忌地通过测试关闭所有内容并争取100％覆盖代码，而是基于风险模型来做到这一点也是有意义的。 质量检查工程师也会这样做。
- “速度！ 我们希望尽快交货。 我们也希望得到信任，我们的产品没有错误！” 在这里，我建议改变发展方式。 如果以前在本地以调试模式运行所有内容的流行方式，现在对于严重的应用程序通常需要一些基础架构才能正常工作。 这是关于dockereization和各种标准实施的所有新趋势的最佳选择。 另一件事很重要：即使在开发的最初阶段，您也需要考虑如何将其交付给工作台，也就是说，不仅要手动部署所有内容，还要设置一个自动化的部署过程。 它会给我们什么？ 当需要交付生产时，仅更改计算点就足够了，而无需从头开始配置整个过程。 这会给开发人员带来什么？ 他对自己做的所有事情都更有信心，因为已经检查了交付脚本超过一轮，并且发行版应该没有问题。
业务领域
但是生意呢？ 他为什么对这种转变感兴趣？ 为什么他对这种方法进行投资有意义？ 建立解释，我将以同样的方式进行。 该业务现在有哪些问题，在IT领域工作和开发高科技产品时，您需要解决什么问题？ 再次，我将在此完全依靠我的意见：
- “什么可能最不适合企业？” 通常，开发人员忘记了，不仅必须开发产品，而且还必须销售产品，为此需要采取足够多的措施，包括为进入市场做准备。 产品开发完成后这样做是有保证的，这就是为什么准备销售渠道和推广新产品的大部分工作几乎是在开发开始的那一刻开始的。
“如果开发迟于发布日期会发生什么？ 开发会不会给市场带来质量不足的产品？“会有损失。 而且不仅是物质，而且是声誉。 对于企业而言，重要的是要确保在开始销售时，产品不仅准备就绪，而且质量适当。 如果在开发过程中存在手动测试阶段，则不可避免地需要重新安排截止日期，或考虑这些阶段的中断风险。 可以预测人为因素，但这很困难，而且（我认为）同样昂贵。
- “企业还关心什么？”当然，他担心发展中的资本投资。 但是，大部分资本投资虽然庞大，但都是在初始阶段进行的。 在发布之前或至少在发布之前，成本不会被销售抵消。 除资本投资外，还有一些运营费用会在运营阶段开始摊薄，因此，尽量减少这些费用非常重要。
“在这种情况下，为什么自动化相对于人工方法而言相当昂贵（就资本支出而言）？”我的观点是显而易见的因素。 自动化是同一个发展。 , . , , , , . , . 为什么这很重要？ . , , « , , , » , , .
- — . , . , , . , .
? , - . . , , , . , , , , , . , .
, « ». ?
- , , , , . : X Y , , , X Z , Z < Y. : , , ( ) .
- — QA-. , «» . , QA- , , , . : , , , , , .
— , . . , , , , , , , , , . .
- — . , , . , , , , . , QA-. , . , , «» — , , , . , , .
- , , — (, , - ). . , . , , , , , (), .
— , . , , , , . , , , « » — . , .
. .
? , 90% , 60% , .
, . , , - . , . , , , , — , .
«» , . «» , QA-. , — . , , ShiftLeft- QA- , - , QA- .
- . , . .