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