Copyright © 2018-2022 All Rights Reserved.
了解最新技术文章
在当今快速发展的科技世界中，质量是市场上产品的主要区别因素。如果测试被视为团队软件开发生命周期 (SDLC) 中的事后想法，甚至被视为 SDLC 中的一个步骤，那么很可能您的产品不会经过良好的测试，并且 QA 将被视为障碍到发布。作为 QA 团队的领导者，当您的团队迁移到更现代的实践（包括 DevOps、持续测试、CI/CD、分布式协作和分析功能）时，您可以在文化变革中发挥主导作用。组织比技术进步更需要概念变革，而质量保证拥有实现这一变革的关键优势。
以下是三个成功的行动计划，可改变您的 QA 文化并将其与 SDLC 的其他部分更紧密地结合起来：
审查并更新团队的 KPI
分析您部门现有的文化
消除“绿色”障碍
您的组织中没有其他人了解 QA 改进 SDLC 的能力。对你来说司空见惯的概念对其他人来说是未知的或令人惊讶的。仔细思考这三种成功策略，其他人将能够理解 QA 不仅仅是推迟发布。
虽然您的团队可以根据具体情况调整这三点，但即使您按照此处所写的那样采用它们，您也会取得很大的进步。
下面的每一段都可以是一个SMART 目标，一个具体的、可衡量的、可实现的、现实的和及时的目标。下面的 KPI 并不是作为教科书概念编写的，原则上可以进行衡量；这个想法是，你选择一些，将它们付诸实践，发布每日更新，与其他人讨论它们，并让组织有机会体验他们每天教授的内容。
错误计数至关重要。继续举报他们。也就是说，只要有可能，就应关注以成本、价值或风险表示的关键绩效指标 (KPI)。“我们的测试人员在上周发现了 53 个缺陷”强调了 QA 是一个成本中心。当您重新审视相同的现实时，“我们上周发现并能够解决 3 个对客户来说风险较高的关键缺陷”，“我们已将平均检测时间从 87 天缩短到 11 天”，甚至更好的是，“我们上周发现的错误代表客户支持节省了 33,420 美元”，您可以帮助组织了解 QA 是一项投资，而不仅仅是一个成本中心。
世界各地的组织都在使用大量的 KPI。作为对可能性的介绍，请考虑您的组织可能能够计算和欣赏其中哪些：
需求覆盖范围
该 KPI 衡量至少一个测试用例所针对的需求的百分比。测试经理确保所有功能需求与其相关测试用例相关联，反之亦然。这种做法确保所有需求都有足够数量的测试。目标是保持需求与测试用例的映射达到 100%。
编写测试
该 KPI 用于衡量在定义的时间间隔内设计的测试用例的数量。编写的测试可以由测试经理或同事进行审查，因为它有助于分析测试设计活动。这也有助于根据需求衡量测试用例，并且可以进一步评估设计的测试用例以将其包含在回归测试套件或临时测试套件中。
缺陷泄漏
允许软件测试人员在产品的用户验收测试 (UAT) 阶段之前分析软件测试过程的效率。如果任何缺陷未被团队发现而被用户发现，则称为缺陷泄漏或错误泄漏。
缺陷泄漏 =（UAT 中发现的缺陷总数/UAT 之前发现的缺陷总数）x 100
模块特定的缺陷密度
缺陷密度帮助团队确定在特定时间段（操作或开发）内软件中发现的缺陷总数。然后将结果除以特定模块的大小，从而使团队可以决定软件是否已准备好发布或是否需要更多测试。缺陷密度按每千行代码计算，也称为 KLOC。
缺陷密度 = 缺陷计数/版本或模块的大小
变更风险分析
该 KPI 通过结合定性和定量标准来评估与变更相关的风险级别，帮助您提高生产力。您可以通过使用一致且标准的流程评估风险来提高变更的准确性。
未解决的缺陷
该 KPI 用于衡量已在缺陷跟踪系统中注册但团队尚未解决的缺陷数量。该指标表示给定日期未解决的缺陷数量。
未解决的严重缺陷
此 KPI 旨在将应用程序中的严重缺陷数量控制在限制范围内（如果存在的严重缺陷多于需要立即采取措施的缺陷）。但在使用此功能之前，测试团队需要接受适当的培训，以正确识别严重缺陷。
拒绝缺陷
该 KPI 衡量被拒绝的缺陷与报告的总缺陷相比的百分比。如果百分比高于设定的阈值，则需要识别预期产品行为或缺陷定义文档中的潜在问题并采取行动。这可能意味着对软件测试人员进行更多培训或更好的需求文档。
（开发团队拒绝的缺陷数量/报告的缺陷总数）x 100。
测试用例质量
书面测试用例将根据定义的标准进行评估和评分。该指标的目的是了解测试人员团队在每个测试阶段执行的测试用例的效率，并通过关注您编写的所有测试中定义的标准来生成高质量的测试用例场景。
自动化测试的百分比
此 KPI 用于衡量自动化测试用例相对于测试套件中测试用例总数的百分比。通常，百分比越高意味着捕获软件交付流中引入的关键和高优先级缺陷的可能性就越大。
缺陷检测效率（DDE）
缺陷检测效率，也称为缺陷检测百分比，是指在软件测试阶段检测到的缺陷总数的百分比。DDE的计算公式为：
DDE =（一个阶段检测到的缺陷数/缺陷总数）x 100 %
缺陷解决时间
该 KPI 用于衡量团队发现软件中的错误以及验证和验证修复所需的时间。它还跟踪解决时间，同时衡量和鉴定测试人员对其错误的责任和所有权。
为什么是这十二个？它们是 KPI 的组合，已被证明在 QA 中具有优势，因为可衡量、历史上有效且多样化，足以阐明您部门面临的最大挑战。
您刚刚开始 KPI 计划吗？从小事做起，了解哪些 KPI 对您有用。这三个 KPI 对于尽早开始跟踪尤其至关重要：
需求覆盖率：一般来说，目标是每个产品需求至少出现在一个记录的测试中是现实的，即使某些测试是手动的 — 目标是 100% 的需求覆盖率。
缺陷检测效率（DDE）： DDE 比较发布前后发现的缺陷数量。如果 QA 在发布前发现 48 个缺陷，并且客户报告两个新缺陷，则 DDE 为 96%，即 48 比 48 + 2 的比率。DDE 有利于规划 QA 工作和产品发布。
自动化测试的百分比：虽然所有 KPI 都需要随时间进行跟踪，但自动化测试的百分比几乎完全是比较而不是绝对水平。如果它出现倒退——如果自动化测试的百分比在产品的生命周期内持续下降——您就会了解到该产品需要立即进行结构性关注，以将其重新加工成更可持续的可测试模型。
您将反复审查您的 KPI 组合；总是有新的见解需要学习和调整。在评估 KPI 时，您需要发挥最佳判断力。一个例子：完全依赖组织熟悉的遗留 KPI 限制了发现。如果引入太多新的 KPI，您的组织可能会面临不堪重负的风险，任何混乱甚至拒绝都会消除潜在的收益。无论何时，寻找能够强化这一点的 KPI：正确执行的 QA 有助于更快地创建更有价值的产品。
KPI 本身就是商业投资。与上面的十几个左右进行练习，并了解哪些对其他部门有意义、良好的行动指南和激励性（同时衡量成本低廉）。如果你的 KPI 是私人事务，只有你和你的主管知道，那么他们的成就就会受到限制。不过，当您的团队或早间例会开始讨论您选择的具体衡量 KPI 时，您就会知道自己正在发挥作用。
质量保证总监所做的最具挑战性和最重要的工作是促进获胜的质量保证文化。如果您想提高质量文化的标准，或建立新的质量文化，您需要做的第一件事就是确保明确定义您的公司价值观。想想您的公司已经确立的价值观——这些价值观是否代表质量？这些值是您想要的吗？还有改进的空间吗？
您的 QA 员工是否渴望自动化可以自动化的测试，并为他们可靠地执行尚未自动化的测试的技能感到自豪？他们是否明白会议的目的是决定实际采取和完成的行动？QA 工作人员是否能够与同事以及 QA 之外的团队成员进行有效沟通？您的 QA 员工是否有这样的态度：无论在产品开发周期的哪个阶段，每个工作日都取得进步？如果你的员工现在没有这些本能，你会采取什么措施来培养他们？您是否传达了您对 QA 的愿景，以便他们很容易理解他们应该做什么？如何消除做正确事情的障碍，并鼓励整个团队在每个工作日有效执行的期望？
有了正确的文化，QA 团队就会采取主动，并寻找让 QA 参与整个 SDLC 的方法。分析您所在部门的现有文化，并考虑您将做出哪些决策来使该文化更接近您想要的文化。
太多的组织将 QA 视为实现共同目标的障碍：QA 是产品与其客户之间的障碍，QA 延长了上市时间，等等。专注于为买家提供价值的部门应该对任何阻碍他们的事情持怀疑态度。然后，绝佳的机会是展示 QA 如何成为解决方案的一部分。
当质量保证仅在产品开发结束时进行管理时，它可能会成为一个障碍。当 SDLC 将 QA 限制在产品完成后发生的情况时，QA 不仅成为产品发布的瓶颈，而且 QA 与产品的距离如此之远，以至于安排或估计 QA 变成了一种猜测。
随着 QA 完全集成到 SDLC 中，您应该从产品开发的最早时刻开始做出贡献。当决策是最便宜且回报最好时，参与第一阶段可以提供可测试性和进度影响的视角。从开发或增强的第一天开始应用的“持续质量检查”可以降低只有在产品接近发布时才会出现巨大的、令人不快的意外的风险。
“持续质量保证”不仅仅是实施持续测试；您可以通过多种方式将 QA 更全面地集成到完整的 SDLC 中。为产品发布流程本身的各个步骤设置测试，以帮助尽早将 QA 集成到 SDLC 中。如果可以的话，参与需求开发并与开发人员配对进行合并请求审查，以便您可以在获得实际的可测试代码之前提供 QA 输入。
这样做可以使部分产品保持“绿色”——它通过了相关测试——或者从一开始就几乎如此。当产品始终保持在绿色状态的少量修正范围内时，产品开发对于开发人员来说要容易得多。一次纠正十个小差异比等到产品开发结束时必须解决数百个相互作用的缺陷更容易。
当产品开始走上“绿色”道路并在每次失误后迅速返回时，参与产品开发的每个人的工作都会更加简单。我们并不坚持将 QA 完全集成到 SDLC 中以对 QA 有利或以某种方式公平。相反，早期集成可以充分利用 QA 的工作，使产品受益，并减轻其他相关人员的负担。
如果 QA 在您的组织中是孤立的，那么是时候做出改变了。您可以通过寻找 KPI 来实现这一点，这些 KPI 强调正确执行的 QA 有助于更快地创建更有价值的产品。分析您部门现有的文化，考虑您将做出哪些决策来使该文化更接近您想要的文化，并消除“绿色”的障碍。执行以下三件事将 QA 构建到您的 SDLC 中，并看到您的产品质量得到提高！
售前咨询专员
