在软件行业中，作为质量保证的一部分，始终希望确保产品/项目以最高的质量达到预期。但是，真正具有讽刺意味的是，我们所有的质量指标都归结为数量和术语，例如记录的错误，编写的测试用例，执行的测试用例，测试所花费的时间，测试的 BUG 率，漏测率等等。
工作职责要求我们将质量置于数量之上，但最终会在定量方法上进行分析。专注于定量测试方法对您的软件测试团队来说是不公平的，即使我们遵循定量方法，也必须有系统的方法来根据我们的软件测试指标来判断个人的工作量。
如何证明每一条量化指标能够体现测试人员工作的价值？一个简单的例子是：使用记录的 BUG 数量衡量团队的效率。
每个团队成员都会采用的一种方法是，在应用程序中的任何位置查找尽可能多的 BUG。
纵观正在使用的敏捷软件开发方法，随着缩短的周期和将测试推迟到每个周期的末尾，留给测试人员的似乎只是在尽可能短的时间内测试应用程序的巨大压力。每个版本都需要执行基于各类风险的测试和冒烟测试，以确保应用程序完美交付到用户。
如今，保持质量的方法已经完全不同，仅代表利益相关者的满意程度。质量完全由客户驱动。利益相关者认为质量等于利润。利益相关者会知道他在产品稳定性方面所处的位置，以及如何将产品推向市场。但这完全由于启动项目的开始工作方式而丢失，即收集需求，定义测试范围，团队协调和分配，测试活动等，我们往往忘记了测试人员的真正使命这是 “建设项目的主要目标 ”。这是制作有助于解决最终用户问题的项目的唯一原因。
但是，重要的问题应该是，我们是否正在测试以确保解决这些问题？如果不是，我们是否会经常向利益相关者提供反馈，以帮助他们更好地了解项目。不断质疑自己很重要：“ 这是客户的期望吗？” 或 “是否有更好的方法来解决同一问题 ”。仅从客户那里获得要求并建立要求并不能使我们的工作得到满足。当我们开始进行项目时，我们需要与客户坐下来，以了解他们对项目的期望以及他们如何可视化项目的质量方面。
例如，如果客户更关注品牌方面，那么即使是像素化标识问题，对于开发人员而言，其严重性也很高。如果目标是构建金融产品 APP，那么与用户数据的安全性相比，UI 和 UX 可能不太重要。这里的 “客观” 是关键。作为测试人员，这是我们需要做的事情。这应该是团队的 OKR（“ 目标和主要结果”），而不是那些受数字驱动的指标。
OKR 是一种流行的领导过程，可帮助个人，团队和组织共同努力以一个统一的方向实现其目标。跨团队和组织设置目标。这样的 OKR 有助于专注于生产力并推动公司文化。
实际上，这有助于我们决定要解决的问题，而不要解决的问题。总而言之，最重要的是，对利益相关者的观点和项目使命的了解越清晰，则对测试工作的构建和优先排序就越好。通过问自己 “客户想要什么？” 来分析风险，将帮助您提高质量。这听起来更像是业务分析师的角色和职责，但是我们不能忽略，因为测试人员也需要具备这种基本技能。这些测试本身就是我们的测试策略。
因此，让测试工程师应该着重于编写客户驱动和项目目标驱动的测试用例，而不是着重于编写确保不出 BUG 的大量测试用例。突出显示严重性高的问题，而不仅仅是用大量的小细节填充用例仓库。优先考虑可以降低用户评估矩阵的风险。
量化测试过程无论如何都不能满足要求，但是，对于那些需要进行测量的组织来说，这个问题仍然没有百分百正确的答案。那么，我们如何测量质量呢？拥有这些指标的主要目的是专注于如何提高/降低这些数字，或者如何达到提高质量的水平，但是由于人本身的原因，因此应该更认真地推动它们发展，因为这些指标将会为我们评估自身增长重要依据。
到目前为止，已经基本明白质量测试胜于数量测试。确保朝正确方向迈进的方法是，在团队中招募合适的软件测试人员，并在已经拥有的软件测试团队中吸收质量测试而非数量测试的概念质量。
许多测试人员最常见的行为是：一旦将需求分配给他们，他们便开始编写测试用例。由于各种因素，他们经常于忘记基本的基础步骤，即先来分析需求中提到的要求。
在开始编写有效的测试用例之前，一定要坚持要核对需求，这有助于正确地进行测试。另一个重要方面是回溯，无论是需求还是 BUG。这有助于确保不遗漏要求，并且能够找到问题的根本原因，这有助于减少此类错误的发生。良好的 BUG 报告和积极的态度也有助于成为一个优秀的测试人员。
优秀测试人员的一些素质包括：
作为测试人员，有一些 “ 不需要 ” 或 “ 不良 ” 的素质，这些 “技能” 很普遍，例如：
下面是提高测试人员技能的一些方法，会在团队中发挥积极的品质：
不少软件测试人员将过多的精力放在增加 BUG 数上，结果，他们最终将偏离要测试的功能的目标。高质量测试用例非常关键，这是提高各类指标的基础。
明确定义的 OKR，可以帮助团队提供优质的产品，而不是比较和分析团队成员之间的无价值数字（指标）。因此，不要推动数量来提高质量。质量应该单独驱动。