这是 Cameron Laird 的客座文章
在当今快速发展的科技世界中，质量是市场上产品之间的关键差异化因素。如果测试被视为团队软件开发生命周期 （SDLC） 中的事后想法，甚至被视为 SDLC 中的一个步骤，那么很可能您的产品不会得到充分测试，QA 将被视为发布的障碍。作为 QA 团队的领导者，随着您的团队迁移到更现代的实践，包括 DevOps、持续测试、CI/CD、分布式协作和精通分析的功能，您可以在文化变革中发挥主导作用。组织需要概念上的改变，甚至比技术上的提升还要大，而 QA 具有实现这种改变的关键优势。
以下是改变您的 QA 文化并将其与 SDLC 的其他部分更紧密地整合的三个成功行动计划：
- 查看并更新您团队的KPIs
- 分析部门的现有文化
- 消除“绿色”的障碍
您组织中没有其他人像您一样了解 QA 改进 SDLC 的能力。对你来说很常规的概念对其他人来说是未知的或令人惊讶的。仔细考虑这三种成功策略，其他人将能够理解 QA 不仅仅是推迟发布。
做这三件事，将 QA 构建到你的 SDLC 中
虽然您的团队可以根据具体情况调整这三点，但即使您按照此处编写的方式采用它们，您也会取得很大的进步。
下面的每个段落都可以是一个 SMART 目标，一个具体、可衡量、可实现、现实和及时的目标。下面的 KPI 不是作为教科书上的概念编写的，人们原则上可以衡量;这个想法是你选择一些，将它们付诸实践，发布每日更新，与他人讨论，并让组织有机会体验他们每天所教的内容。
1. 审查并更新您团队的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 用于衡量团队查找软件中的错误以及验证和确认修复所需的时间。它还会跟踪解决时间，同时衡量和限定测试人员对其 bug 的责任和所有权。
为什么是这十二个？它们是 KPI 的组合，在 QA 中已被证明是有利的，因为它们是可衡量的、历史上有效的和多样化的，足以阐明您部门面临的最大挑战。
您刚刚开始您的 KPI 计划吗？从小处着手，了解哪些 KPI 适合您。特别是这三个 KPI 对于尽早开始跟踪至关重要：
- 需求覆盖范围：一般来说，将每个产品需求都出现在至少一个记录在案的测试中是现实的，即使某些测试是手动的 – 以 100% 的需求覆盖率为目标。
- 缺陷检测效率 （DDE）： DDE 比较发布前后发现的缺陷数。如果 QA 在发布前发现 48 个缺陷，并且客户报告了两个新缺陷，则 DDE 为 96%，即 48 比 48 + 2 的比率。DDE 有利于规划 QA 工作和产品发布。
- 自动化测试的百分比：虽然所有 KPI 都需要随着时间的推移进行跟踪，但自动化测试的百分比几乎完全是关于比较的，而不是绝对水平。如果它回归——如果自动化测试的百分比在产品的生命周期内持续下降——你已经了解到该产品需要立即进行结构性关注，以将其重新设计为更可持续的可测试模型。
您将反复审查您的 KPI 投资组合;总有新的见解需要学习，总是有新的调整需要做出。在评估 KPI 时，您的判断需要处于最佳状态。一个例子：完全依赖组织熟悉的旧 KPI 会限制发现。如果您引入太多新的 KPI，您可能会让您的组织不堪重负，并且任何混乱甚至拒绝都会抹杀潜在的收益。在任何时候，都要寻找能够强化正确执行 QA 有助于更快地创造更有价值的产品的 KPI。
KPI 本身就是商业投资。与十几个人一起练习，就像上面提到的那些，并了解哪些对其他部门有意义、良好的行动指南和激励性（虽然衡量成本低廉）。如果您的 KPI 是私人事务，只有您和您的主管知道，那么它们的成就是有限的。但是，当您的团队或晨间 Scrum 开始就您选择的特定衡量 KPI 进行对话时，您就会知道您正在做出改变。
2. 分析 QA 部门的现有文化
QA 总监所做的最具挑战性和最重要的工作是促进成功的 QA 文化。如果您想提高质量文化的标准或建立新的质量文化，您需要做的第一件事是确保您的公司价值观得到明确定义。想想您的公司已经制定的价值观 – 这些价值观是否与质量有关？这些价值观是您想要的吗？还有改进的余地吗？
您的 QA 员工是否渴望自动化可自动化的测试，并为他们能够可靠地执行尚未自动化的测试的技能感到自豪？他们是否明白会议的目的是决定实际采取和完成的行动？QA 工作人员是否能够与同事和 QA 以外的团队成员进行有效沟通？您的 QA 员工是否有这样的态度，即每个工作日都在进步，无论它发生在产品开发周期的哪个阶段？如果您的员工现在没有这些直觉，您正在做些什么来培养它们？您是否传达了您对 QA 的愿景，以便他们很容易理解他们应该做什么？您如何消除做正确事情的障碍，并鼓励期望整个团队能够有效地执行每个工作日？
有了正确的文化，QA 团队就会主动出击，并寻找让 QA 参与整个 SDLC 的方法。分析您部门的现有文化，并考虑您将做出哪些决定来使这种文化更接近您想要的文化。
3. 消除“绿色”的障碍
太多的组织将 QA 视为实现共同目标的障碍：QA 是产品与其客户之间的障碍，QA 延长了上市时间，等等。专注于为买家提供价值的部门应该对任何阻碍他们的事情持怀疑态度。然后，绝佳的机会是展示 QA 如何成为解决方案的一部分。
当 QA 被管理为仅在产品开发结束时发生的事情时，它可能是一个障碍。当 SDLC 将 QA 局限于产品以其他方式完成之后发生的事情时，不仅 QA 是产品发布的瓶颈，而且 QA 与产品相距甚远，以至于安排或估计 QA 成为一种猜测练习。
随着 QA 完全集成到 SDLC 中，您应该从产品开发的最早时刻开始做出贡献。参与第一阶段可以让我们了解可测试性和进度影响，因为决策的成本最低，回报也最好。从开发或增强的第一天开始就应用“持续 QA”，可以降低仅在产品接近发布时出现大型、令人不快的意外的风险。
“持续 QA”不仅仅是实施持续测试;您可以通过多种方式更全面地将 QA 集成到完整的 SDLC 中。为产品发布流程本身的各个步骤设置测试，以帮助更早地将 QA 集成到 SDLC 中。如果可以的话，参与需求开发并与开发人员结对进行合并请求审查，这样您就可以在获得实际的可测试代码之前就提供 QA 意见。
这样做可以使部分产品保持“绿色”——它通过了相关测试——或者从一开始就几乎通过了绿色。当产品始终保持在与绿色状态的少数修正范围内时，产品开发对开发人员来说要容易得多。一次修复 10 个微小差异比等到产品开发结束必须解决数百个相互作用的缺陷要容易得多。
当产品开始走上“绿色”道路并在每一个失误后迅速返回时，参与产品开发的每个人都有一份更直接的工作。我们并不坚持要求 QA 完全整合到 SDLC 中，以对 QA 友好或以某种方式公平。相反，早期集成充分利用了 QA 的工作，使产品受益，并减轻了其他所有相关人员的负担。
如果 QA 在您的组织中是孤立的，那么是时候做出改变了。您可以通过寻找 KPI 来强化正确执行 QA 有助于更快地创建更有价值的产品的观点。分析您部门的现有文化，考虑您将做出哪些决定来使这种文化更接近您想要的文化，并消除“绿色”的障碍。做这三件事，将 QA 构建到您的 SDLC 中，并看到您的产品质量得到提高！
Cameron Laird 是一位屡获殊荣的软件开发人员和作家。Cameron 参与了多个行业支持和标准组织，包括 Python 软件基金会的投票成员。Cameron 长期居住在德克萨斯州墨西哥湾沿岸，他最喜欢的应用程序是农场自动化。
By 孙晟