DevOps 测试文化：在整个 SDLC 中构建质量时要避免的 5 个主要错误
公司希望提供质量，但也必须平衡开发时间表、市场需求等，以尽快推出新功能。将 QA 纳入您的 SDLC 并确保彻底的测试是每次交付质量的关键。然而，如果您的组织将 QA 视为团队软件开发生命周期 (SDLC) 中的事后想法或瓶颈，甚至将其视为 SDLC 中的一个步骤，那么很可能您的产品不会经过充分测试，而 QA 也将受到影响。被视为发布的障碍。
在我们的上一篇文章DevOps 测试文化：如何在整个 SDLC 中构建质量中，我们讨论了如何开始在 SDLC 中构建 QA。这篇文章将讨论在整个 SDLC 中构建质量时应避免的五个最常见错误。
积极的目标激励我们。同时，了解一些“难闻的气味”或警告信号以及当它们出现时该怎么做也是一个很好的做法。以下是 QA 团队最常犯的五个错误，以及如何绕过这些错误以确保安全。
在没有明确定义的需求或用户故事的情况下进行测试
有时，走向健康的 QA 部门的第一步，也许也是最重要的一步，就是停止。没做什么。休息一下。在分配用于测试本身的软件的要求超过您的质量阈值之前，根本不运行任何测试。
组织习惯于将软件留在 QA 的门口，假设 QA 可以进行逆向工程、读心术并推测软件为客户带来的价值。停止任何形式的行为。坚持让 QA 持续测试明确的书面目标。创造力是一件美好的事情，但这是错误的地方。您的员工为弄清楚软件应该做什么所做的任何努力都会干扰他们验证软件功能的能力。满足模糊或模糊的要求并不“好”：它会流失力量，远离它需要的地方。
像这样的变化会对产品管理带来挑战吗？也许; QA 创造力的最佳应用是帮助产品管理制定良好的需求。首先帮助编写它们是理想的选择。然后您就会知道它们是什么，并且它们是可测试的并且与用户故事保持一致。在产品定义之前编写需求时，您可以测试需求本身并验证其完整性、清晰度、简洁性、一致性和连贯性。
并非所有情况都是理想的。但是，在过渡期间，您可能需要对您未帮助指定的产品进行质量检查。不过，无论之前发生了什么，都要确保 QA 不会猜测需求。仅在软件构建之后才以某种方式出现的需求是更深层次问题的征兆。
您周围的人可能会根据您对测试框架的了解或测试人员发现的错误数量来评判您。然而，通过改变组织的运营方式，以实现与最终用户共同构建的清晰、合理的目标，您的价值会倍增。在正确完成需求之前停止测试，或者至少在您弄清楚之前停止测试，是一项巨大的成就，也是您应该追求的目标。
收到需求后如何测试？这是一个很大的主题，主要超出了本介绍的范围。现在，根据您的经验：您知道像“快”这样的主观标签需要量化。您知道，当最终用户做了没人预料到的事情时，需要注意“不愉快的路径”。在 SDLC 中尽早提供监督和审查，并告诉整个产品团队QA 的参与是有回报的。
通过会议进行沟通
QA 是否会与开发人员会面以传递您的发现？过去有理由以这种方式进行沟通，但现在，在 2022 年，您需要更好的渠道。
QA 通常会生成调查结果的集合；它可能被称为“遗留问题清单”、“错误报告”、“票据收集”等等。尽快将 QA 的发现传达给开发人员至关重要，但不是通过会议。
您可能已经有了错误或问题管理器。测试人员应该在找到项目后立即将其输入其中。等待每周例会并不能改善沟通；发现问题后立即开始沟通。测试人员需要学习如何编写报告，以便问题可以重现。更好的是，使用测试管理工具根据测试结果数据和您的评论自动生成错误报告。
编写可重现报告的技能对测试人员来说是极大的解放：拥有该技能意味着，一旦输入错误报告，他们就可以离开它们并将注意力完全转向以下任务。不再需要在 Bug 会议之前的几天里记住要说什么；需要说的一切都符合可复制的报告。
通过问题经理进行的沟通还可以通过多种方式使开发人员受益。它将认知负荷分散到一周内，提供了适当深度研究错误的机会，并让他们有机会聘请合适的人才来承担特定项目。
会议非常适合讨论困难、分享观点、将部分理解拼凑成更完整的计划以及建立责任制。不过，对于技术发现的日常交流，我们可以做得更好。
将“错误报告”会议的交通拥堵改为整个星期的顺畅写作，从发现问题的测试人员到解决问题的开发人员。
做出产品决策
您是否曾被问过产品是否“足够好，可以发货”？作为 QA 部门的领导者，这个问题有一个永远不应该改变的简单答案：“这不是我的决定。”
“Go-no-go”是产品管理的领域。与产品需求一样，您只能通过澄清边界、接口和职责来帮助组织。QA 的任务是发现软件满足定义需求的程度；关于向客户提供什么产品的决策是一个完全不同的领域。
如果您愿意，欢迎您帮助进行产品管理。您可能对客户如何接收特定版本有个人意见。明确区分并保护 QA 核心活动的完整性。QA 必须确保将大部分精力用于分析需求并报告任何未能满足这些需求的情况。
每次冲刺都变得紧张
怀疑同步问题。您是否有一个为期四个星期的冲刺，您的测试人员在前十天无所事事，然后在冲刺的最后几天通宵达旦？这是更严重困难的明显症状。改变 SDLC 的工作方式，以便分散负载，以便测试人员可以在冲刺的所有阶段高效地进行测试。当然，临近发布时，会对传统错误进行 QA 测试。不过，早些时候，可能还有很多事情要做：
测试要求本身，
确认测试环境具有足够的硬件容量来处理需要处理的负载
与开发人员合作实施持续测试 (CT)
对之前的 QA 周期进行回顾
等等
更一般地说，任何时候一个团队等待另一个团队都代表着一个机会，可以重新思考工作流程中的依赖关系和库存，并可能消除潮起潮落。问题经理很大程度上解决了“错误会议”问题；明智地使用更好的“数据结构”可以解决许多其他过度同步的问题。例如，一个好的工单或事件或项目经理应该有足够强大的报告，以便经理可以找到感兴趣的错误的状态，而不需要专家背诵有关它的叙述。这样一来，需要安排的谈话或会议就少了一次。
下面是一个示例：QA 测试人员可以在获得批准后立即开始阅读需求。不要等到实施准备就绪，而是在冲刺的第一周查看书面要求。识别任何歧义，并安排任何特殊的环境配置。这使得第六周（也就是一个月前）需要付出的一些努力得以转移。它可以更智能地分散 QA 的负担，并有助于改善与其他部门的合作。
任何类型的大刘海
警惕戏剧。构建 QA 活动，使日常或冲刺之间的变化基本上很小。帮助建立跨多个周期有效的良好惯例，而不是指望英勇的努力或特殊事件。通过“缓慢而稳定”的努力赢得比赛。作为导师，你可以向初级同事传授的最有价值的技巧之一就是将大任务分解成更小的任务，并确保每天甚至每小时都有进展。
告诉您的团队和同事您将采取上述行动。当您通过这些行动取得成功以及当您了解到需要进行调整时，请告诉他们。QA 可以提高整个 SDLC 的质量并管理风险；从上述开始，通过正确的策略选择，质量检查可以在发挥这一潜力方面取得出色的记录。遵循具有战略意图的行动和响应，您将创建一个质量保证部门，取得比其他人想象的更多的成就。
售前咨询专员
