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