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