您如何确定您的项目的质量随着时间的推移而提高？

Question

前言:我知道这个问题可能有点宽泛，所以我希望这个问题不要结束。然而，我觉得这是一个很多QA工程师和经理都在纠结的话题，我不认为只有一种好的方法来做一些事情(就像我们这个领域的很多其他话题)。

正如问题所述，您如何确定您的项目的质量随着时间的推移而提高？您在使用什么以及如何度量项目质量？

就我个人而言，我不认为测试用例的数量和bug的数量在这种情况下是一个很好的衡量标准，特别是在敏捷(在我的例子中是Scrum和看板)工作组织中。我们在两个星期的冲刺过程中为所有团队开发了X特性，测试完成后(而不是在sprint的末尾)，它们就会被部署。虽然来自支持的bug可能是一个重要的起点，但理想的场景将是无法到达那里。

那么，你现在如何评估你的项目的质量呢？你怎么知道你的项目是“质量好”还是“质量不好”？

你做什么，积极或追溯，及时，达到预期的质量水平，也许可以避免业务损失？

Answer 1

一个好的起点是定义质量在你的上下文中意味着什么。然后找出如何测量的方法。似乎你不想说那是什么东西就想测量一些东西。

话虽如此，我们很难在这里告诉你，但也许我们可以给你一些起点，你可以在与你的团队和其他与你所创造的产品(S)有关的人进行讨论时使用这些起点。这个起点可以是这个金字塔：

( 这书中提到)

该产品应满足所有这些水平。它在实践中的意义是，你应该在你的团队，你的客户和客户，在你的上下文中定义一些东西。但至少你一开始就有一些指导方针。

在这种情况下，我不认为测试用例的数量和bug的数量是一个很好的衡量标准。

仅仅是一个数字并不能告诉你多少。虽然他们可能是一些行业，即使是数字本身也可能很重要，但即便如此，也应该有更多的背景与这些数字一起，才能更全面地了解我们正在处理的事情。

你做什么，积极或追溯，及时，达到预期的质量水平，也许可以避免业务损失？

专注于高优先级的特点，最大的风险，广泛的检查和探索性测试。如果可能的话，经常与客户/客户/团队的其他成员交谈，让他们在生产前使用/测试新特性，对他们要说的内容感兴趣，并对此进行跟踪。

Answer 2

对我来说，这是关于可衡量的更快交付有价值的特性，同时减少了功能的停机时间。我认为好的产品和团队加班的速度越来越快。这可能与大多数人所经历的不同，典型的是软件项目超时的速度越来越慢。我想说的是，这是因为功能、结构和过程质量方面的“质量不好”。

根据最近的一项研究，devops2019的报告指出，衡量和改进以下关键指标可以提高这些公司的净收入(如资金、利润)。

• 交货期
• 部署频率
• 变革失败
• 恢复时间
• 可用性

捕获开发和交付过程有效性的前四个指标可以从吞吐量和稳定性方面进行总结。我们使用代码从签入到发布随部署频率变化的准备时间来度量软件交付过程的吞吐量。稳定性是使用恢复时间来衡量的--从检测用户影响事件到进行补救所需的时间--以及更改故障率，这是释放过程质量的一种度量。

见https://services.google.com/fh/files/misc/state-of-devops-2019.pdf中的第16页

衡量你的立场，现在试着成为一名优秀的表演者:)

Answer 3

以下是我们公司按优先级顺序使用的指标：

1. 每个活跃用户数量的支持案例数
2. 应用程序生成和记录的错误数

这包括软件开发的一些基本方面：

1. 该产品的用户友好程度如何？如果不是，那么您将得到更多的支持请求，或者更少的用户。
2. 记录的错误越多，在开发/部署期间漏掉的bug就越多。
3. 我们的产品文档有多好？如果不好，我们会得到更多的支持请求。这是很难测试的，但也是质量的一部分。我们在支持团队、文档编写人员和测试人员之间有一个反馈循环。
4. 测试覆盖率是一个很好的度量，但是您可以拥有很好的测试覆盖率，但是仍然有很多支持案例。在客户眼中，如果他们需要联系我们的主要指标，那么你的产品质量就不高。