1

质量保证的最佳流程是什么（除了测试）？你使用代码审查、代码分析器吗？您使用 QA 标准文档，还是仅使用眼球代码？另外，您如何向开发人员提供反馈？你为质量保证做什么？

4

5 回答 5

7
  • 除非您的问题率非常低，否则请使用数据库来跟踪问题。
  • 通过让开发人员进行 TDD（测试驱动开发）来使 QA 过程变得有趣。这对他们有好处，它摆脱了愚蠢的错误。
  • 自动化测试。
  • 让 QA 从一开始就参与产品，而不仅仅是最后两周。
  • 给他们权力。QA 可以决定产品何时可以发货。
  • 给 QA 一条真正的职业道路。
于 2009-04-17T17:03:02.793 回答
3

我认为所有 QA 都是多管齐下的。开发人员必须测试他们自己的代码，以确保它做他认为应该做的事情并且不会破坏构建。测试人员应根据规范进行测试，以查看开发人员是否正确解释了它们（开发人员测试几乎从未发现这些问题）。同行应进行代码审查，以确保遵循标准并促进学习。用户必须进行测试，就像他们将尝试做没有人期望或在需求中定义的事情一样。通常这些都是愚蠢的事情，让我们摇摇头，“为什么每个人都想这样做？” 但是许多其他的真正需求不在规范中，因为没有人费心去问用户他们需要什么。应该进行客户验收测试，特别是如果您为不同的客户进行定制开发。如果客户在工作投入生产之前已经签署了工作，那么表明新的工作请求是新的开发而不是错误要容易得多。这可以节省大量关于谁来支付费用的合同纠纷。

此外，让其他人修复您的错误代码是确保继续生成错误代码的最佳方式，这就是为什么我讨厌某些公司的组织结构，即让开发人员做新事物并支持进行修复的人。此外，修复错误代码以节省时间而不将其发送回开发人员进行修复的经理正在给未修复它们的组织带来问题。

在我看来，QA 的另一个重要部分是花时间实际定义需求和标准。（是的，它们会在任何大型项目中发生变化，但仍然需要它们）。没有要求，测试充其量是随机的。如果没有标准，维护可能会成为一场噩梦，而且比需要的成本要高得多。

QA 的最后一部分是从我们的错误中学习。不幸的是，在许多组织中，你不能诚实地在项目后讨论出了什么问题以及如何防止下一次出现问题，而不会陷入相互指责的指责会议，这会导致人们保持安静，而不是因为他们的绩效评估而受到不好的评价. 事实上，出于这个原因，绩效评估通常对提高质量的目标是有害的。（查阅《戴明与全面质量管理》，了解质量大师对绩效考核危害的看法。）

从理论上讲，应该有可以用来衡量改进质量的质量指标。但在实践中，只要您的组织进行绩效评估，这些数字通常会被“按摩”以使事情看起来更好或衡量磨损的事情（更少的代码行并不意味着在所有情况下都有更好的代码，更多的错误报告可能意味着我们在发现（或至少报告）错误方面做得更好，而不是代码比过去的项目更糟糕）因此无用。

于 2009-04-17T17:16:47.643 回答
2

请注意，“质量保证”通常不专注于提高质量本身，而是提供没有错误。有可能制造出仍然存在错误的高质量产品（但它们当然最好不是重大错误）。可以制造出 100% 没有错误但仍不提供质量的产品。 激光制导剪刀 http://www.computerweekly.com/Assets/GetAsset.aspx?ItemID=40649

当然，无论如何尝试消除产品中的错误并没有错。然而，QA 的风险在于，专注于阻止错误发生可能会讽刺地干扰产品质量的提高。Tom DeMarco 在他的一本书（我不记得是哪一本，但可能是Peopleware）中写到了这一点，他在其中以 Adob​​e Photoshop 为例说明了他认为什么是高质量的产品以及原因。

来自维基百科：

Steve McConnell 的 Code Complete 中的定义将软件分为两部分：内部质量特性和外部质量特性。外部质量特征是产品面向用户的部分，而内部质量特征是不面向用户的部分。

Tom DeMarco 博士的另一个定义是：“产品的质量取决于它使世界变得更好的程度。” 这可以解释为意味着用户满意度在确定软件质量方面比任何事情都更重要。

我想另一种说法是，如果 QA 只关注内部质量，而没有其他人对外部质量负责，那么您最终只能靠运气获得杀手级产品。我希望我听起来不会对错误删除持否定态度，我只想指出这不是灵丹妙药。

于 2009-04-17T18:29:19.280 回答
1

拥有一个在交付之前对软件进行认证的 QA 环境是一种很好的做法。在每日报告中提供清晰的质量指标（系统正常运行时间、严重错误的数量、由于流程不善导致的问题数量）可以明确关注质量问题（如果存在）。对于有问题的项目，需要开发团队进行事后分析，以确定如何改进初始和持续质量。任何和所有的沟通都应该是积极的声音，并专注于寻找质量差的根本问题。有时只是询问开发团队他们缺乏什么来提高质量就可以解决许多问题。

于 2009-04-17T16:59:18.780 回答
-1

对于质量保证，了解产品开发的整个过程比代码审查更重要。作为质量保证，非常需要对实际需求有一个非常清晰的概念，要开发的功能，跟踪要开发的单个/多个，以便可以根据该时间表创建测试范围。

为了向开发人员提供反馈，只需确定用户需求的条件，传达任何可能是功能性或非功能性的不匹配。这将是一个有效的反馈。

于 2018-04-02T22:56:59.233 回答