哈Ha！
我们有一个新的重要主题-IT产品的高质量开发。 我们经常在HighLoad ++中谈论如何使加载的服务快速运行，以及在Frontend Conf上谈论-不降低速度的凉爽用户界面。 我们经常有关于测试的主题，还有关于结合不同过程（包括测试）的DevOpsConf的主题。 但是关于什么可以整体上称为质量，以及如何进行全面的工作，没有。
让我们将其
固定在
QualityConf上 -我们将在开发的每个阶段为用户开发一种思考最终产品质量的文化。 习惯不要挂在您的责任范围上，而要把质量不仅与测试人员联系起来。
根据削减计划，我们将与计划委员会负责人，Tinkoff
Business测试负责人，讲俄语的质量检查社区
Anastasia Aseeva-Nguyen的创建者讨论质量检查行业的状况以及新会议的使命。
-纳斯蒂娅，你好。 请介绍一下您自己。
阿纳斯塔西娅（Anastasia） ：我负责银行的测试，我负责一个非常大的团队-我们有90多个。 我们有一条重要的业务线，我们负责法人实体的生态系统。
我在mehmat学习，最初想成为一名程序员。 但是当我有一个有趣的报价时，我决定尝试自己作为一名测试员。 奇怪的是，这竟然是我的电话。 现在，我看到了我在这个行业中的所有工作。
我是质量保证学科的热心拥护者。 我不在乎创建什么产品，它们与公司，团队，以及原则上在开发过程中如何与质量相关。
对我来说，很明显，至少在俄罗斯
，这个方向的
社区还不够成熟 。 我们并不总是了解质量保证不仅是测试应用程序是否符合要求的事实。 我想改变这种情况。
-您使用“质量保证和测试”一词。 在普通人眼中，这两个词经常相交。 如果您深入研究，它们有何不同？阿纳斯塔西娅：相反，他们没有什么不同。 测试是质量保证学科的一部分；这是一项直接的活动-我正在测试某些东西。 实际上，测试的类型很多，并且由不同的人负责不同类型的测试。 但是在俄罗斯，当一波外包商为公司提供测试人员时，测试就简化为单一视图。
在大多数情况下，它们仅限于功能测试：它们会验证开发人员编译的内容是否符合规范，仅此而已。
-请告诉我，还有哪些其他质量保证学科？ 除测试外，它还包括什么？阿纳斯塔西娅 ：质量保证首先是关于创造优质产品。 也就是说，我们想知道我们的产品应具备哪些质量属性。 因此，如果我们理解这一点，就可以比较谁对这些质量属性有影响。 没关系，
开发人员，项目经理或产品经理是影响产品开发，积压和策略的人。
测试人员会更好地意识到自己的作用。 他了解他的任务不仅是测试是否符合要求，还包括测试要求，质疑产品技术人员的语言，以及揭示客户的所有隐含要求和期望。 当我们向客户提供新功能时，我们必须真正满足他的期望并解决他的痛苦。 如果我们考虑质量的所有属性，客户将感到满意，并会理解他所使用产品的公司真正关心他的利益，并且不遵循“仅发布功能”的原则。
-您刚才描述的似乎是产品技术人员的任务。 从原则上讲，这与测试无关，而与质量无关；通常与产品管理有关，不是吗？阿纳斯塔西娅 ：包括。 质量保证不是一个特定人员要负责的学科。 现在在测试中有一个流行的方向，一种称为
敏捷测试的方法。 在他的定义中，听起来很简单，这是一种团队测试方法，其中包括一组特定的实践。 整个团队负责实施此方法，甚至没有必要将测试人员加入团队。 整个团队致力于为客户提供价值，以使这一价值能够满足他的期望。
-事实证明质量与几乎所有周围学科相交，在周围的所有事物上都建立了框架吗？阿纳斯塔西娅 ：对。 当我们考虑要创建高质量的产品时，就开始考虑质量的各种属性。 例如，如何检查我们是否确实实现了客户所需的功能。
这种测试就像
UAT （用户接受测试）一样弹出。 不幸的是，在俄罗斯很少实践它，但是有时它作为最终用户的演示出现在SCRUM团队中。 在外国公司中，这是一种相当普遍的测试类型。 在向所有客户开放该功能之前，我们首先制作UAT，也就是说，我们邀请进行测试并立即提供反馈的最终用户-产品确实满足期望并解决了痛苦。 只有在此之后，才能扩展到所有其他客户端。
也就是说，我们专注于业务，最终客户，但同时
不要忘记技术 。 产品质量也很大程度上取决于技术。 如果我们的体系结构不佳，我们将无法快速发布功能并满足客户期望。 尝试扩展或重构时可能会有很多错误，我们可能会破坏某些东西。 这都会影响客户满意度。
从这个角度来看，该体系结构应该使得我们可以编写干净的代码，使我们能够快速进行更改，而不必担心会破坏一切。 仅仅因为我们有很多遗产，我们需要做很长的测试步骤，所以精炼的迭代不会花几个月的时间。
-总的来说，开发人员，架构师，产品专家，产品经理，测试人员本身已经参与其中。 谁还参与质量保证过程？阿纳斯塔西娅（Anastasia） ：现在想象我们已经向客户提供了一项功能。 显然，您需要监视产品的质量以及产品何时投入生产。 在此阶段，可能会出现非显而易见的情况，即所谓的错误。
第一个问题是在发布产品后如何处理这些错误？ 例如，我们如何应对负载？ 如果页面加载超过30秒，客户端将不会非常满意。
这就是开发或现在称为
DevOps的地方 。 实际上，这些人负责产品已经售出时的操作。 这包括各种类型的监视。 甚至还有一种测试类型：在产品上进行测试，即当我们不允许自己在推出产品之前不进行测试并立即在产品上进行测试时。 从基础结构的组织角度来看，这是一系列措施，使您可以快速响应事件，对其进行影响并进行纠正。
基础设施也很重要。 通常，在某些情况下，在测试期间无法确保我们确实拥有想要提供给客户的一切。 我们推出了产品-并开始发现不明显的情况。 都是因为测试中的基础结构与产品上的基础结构不匹配。 这导致了一种新型的测试-
基础结构测试 。 这些是各种配置，设置，数据库迁移等。
这就引出了一个问题-也许团队需要使用基础架构作为代码。
我相信基础架构会直接影响产品质量。
我希望会议能有一个真实案例的报告。 如果您准备根据自己的经验告诉我们基础架构作为代码如何影响质量，请给我们写信。 将基础结构作为代码可以更轻松地检查所有设置并测试原本无法实现的测试。 因此，开发也参与了开发优质产品的过程。
-那么分析和文档呢？Anastasia ：这更适用于企业系统。 当我们谈论企业时，立即会想到分析人员和系统分析人员。 他们有时被称为技术作家。 他们收到一个任务来编写规范并完成它，例如，一个月。
反复证明，编写此类文档会导致开发过程很长的迭代，而提炼过程又很长的迭代，因为在测试过程中会发现错误，因此开始退货。 结果，有很多循环会增加开发成本。 此外，这可能会引入漏洞。 我们似乎已经编写了参考代码，但是随后进行了更改，打破了经过深思熟虑的体系结构。
结果是产品质量不是很高，因为补丁已经在体系结构中出现，某些地方的代码没有被测试充分覆盖，因为截止日期已到，所以您需要更快地关闭所有错误。 都是因为在原始规范中并未考虑所有需要实现的要点。
开发人员不是害虫，也不会专门编写有错误的代码。
如果我们最初想到了一个涵盖所有必要要点的规范，那么一切都将按照应有的方式实施。 但这是乌托邦。
编写100页的完美规范可能是不可能的。 因此，
我们需要考虑编写文档 ，指定，设置任务的
替代方法，这将使我们更接近于开发人员完全按照我们的需要进行工作的事实。
这就是敏捷方法-带有接受标准的用户案例。 这更适用于小迭代开发的团队。
-可用性测试，产品可用性，设计如何？阿纳斯塔西娅（Anastasia） ：这是非常重要的一点，因为团队中有设计师。 设计师通常将其作为服务使用-设计部门或外包设计师。 通常情况下，设计师似乎已经听过产品技术人员的话，做了他所理解的事情。 但是，当我们开始迭代时，结果表明并没有真正完成预期的工作：设计师忘记了某些东西，因为他不在团队或上下文中而没有仔细考虑行为，或者前端开发人员没有完全理解它布局。 仅因为前端开发人员对设计的理解存在问题，可能需要进行多次迭代。
另外还有另一个问题。 设计系统越来越受欢迎。 他们大肆宣传，但是它们的好处并不完全明显。
我发现，设计系统一方面简化了开发，另一方面对接口施加了很多限制。
结果，我们没有提供客户想要接收的功能，而是为我们提供了方便的功能，因为我们已经有了可以使用它的某些多维数据集。
在我看来，您应该注意这个主题，并考虑我们是否真的能够解决客户的痛苦，以简化设计工作。
-事实证明，许多主题与质量保证有关。 俄罗斯有没有可以讨论所有问题的会议？Anastasia ：最古老的测试会议将于今年第25届举行，称为SQA Days质量保证会议。 它主要讨论功能测试人员的工具和特定的测试方法。 通常，关于SQA Days的报告会深入检查测试人员自身职责范围内的特定区域，而不是复杂的事件。
它有助于理解各种工具和方法，以及如何测试数据库，API等。 但是，与此同时，一方面，它并没有激发将测试不仅包括在创建更好的产品中的动机。 另一方面，为了考虑产品及其业务组件的全球目标，测试人员不会更多地参与该过程。
我领导一个大部门，进行了大量采访，这实际上使我们可以想象整个行业的状况。 通常，我们的员工在企业工作，他们有明确的职责范围。 在国外项目中工作的同事使用不同类型的测试：他们自己可以进行压力测试，性能测试，有时甚至是安全测试，因为他们确实可以帮助团队为产品提供高质量的产品。
我希望我们在俄罗斯的人们也开始认为该行业不会以功能测试而告终。
-为此，我们正在组织一个新的会议QualityConf，专门讨论作为整体学科的质量。 告诉我们更多关于这个想法的信息，会议的主要目标是什么？阿纳斯塔西娅（Anastasia） ：我们希望创建一个对生产优质产品感兴趣的人的社区。 提供一个平台，让他们可以参加会议，听取报告并在会议结束后离开会议，并具体了解他们需要为提高质量而需要改变的地方。
现在，我经常听到咨询的要求，即在测试和质量存在问题时该怎么办。 当您开始与团队交谈时，您会发现问题不在于测试人员本身，而在于构建流程的方式。 例如，当开发人员认为他们只负责编写代码时，他们的职责恰好在将任务转移到测试时终止。
并非每个人都认为编写质量差，架构差的代码给项目带来了很大的问题。 不要考虑错误的成本，因为生产中的错误会给公司和团队带来巨大的成本。 没有文化可以考虑。 我希望我们开始在会议上分发它。
我知道这不是创新，爱德华·戴明（Edward Deming）是14条质量假说的作者，他在上个世纪写下了错误的代价。 本书以质量保证作为一门学科，但是不幸的是，现代发展却忘记了它。
-您是否打算直接涉及有关测试和工具的主题？阿纳斯塔西娅 ：我承认会有关于这些工具的报道。 公司和团队可以使用相当通用的工具来影响产品。
所有报告将在全球范围内以一个共同的使命团结在一起：向听众传达，通过这种方法，工具，方法，过程，测试类型，我们影响了产品质量并改善了客户的寿命。
绝对不会因为该工具而有关于该工具的报告。 属于该计划的所有报告将按照一个共同的目标进行统一。
-谁会对您正在谈论的内容感兴趣，并看到您是会议的邀请对象？阿纳斯塔西娅（Anastasia） ：我们将为对他们的项目，产品，系统的命运毫不关心的开发人员提供报告。 对于测试人员来说，这同样也很有趣，在我看来，尤其对于管理人员而言。 对于管理人员，我指的是做出决定并且可以影响产品，系统，团队的命运和发展的人。
这些人想知道如何提高产品，系统的质量。 在我们的会议上，他们将了解各种复杂的事件，并能够了解哪些是不正确的，哪些需要更改。
我认为主要标准是要了解质量问题，并希望对其进行影响。 也许，这是第一次接触到相信它会成功的人，但我们不会成功。
-您是否认为整个行业已经成熟，以便不仅谈论测试，而且谈论质量文化？阿纳斯塔西娅 ：我想我已经成熟了。 现在，许多公司正在从传统的Waterfall方法转向敏捷。 以客户为中心，团队中的人们开始真正考虑如何创建高质量的产品。 即使在企业公司中，也有重新定位以提高质量。
从社区中出现的查询数量来看，我认为是时候了。 当然，我不确定这将是一次大规模的革命，但是我希望这种意识发生改变。
-同意！ 我们将灌输一种文化并改变主意。关于QualityConf IT产品质量发展的会议将于6月7日在莫斯科举行。 您知道优质产品是由什么阶段组成的，在库存中有成功地解决错误的案例，我们在实践中测试了流行的方法-我们需要您的经验。 请在5月1日之前发送您的申请 ，计划委员会将帮助该主题聚焦于会议的整体完整性。
连接到我们讨论质量问题和会议的聊天室，订阅Telegram频道以了解节目新闻。