质量保证的最佳流程是什么（除了测试）？您是否使用代码评论，代码分析器？您是使用质量保证标准文件还是眼球代码？另外，您如何向开发人员提供反馈？ 你为QA做了什么？
答案 0 :(得分：7)
答案 1 :(得分：3)
我认为所有质量保证都是多方面的。开发人员必须测试自己的代码，以确保它能够执行他认为应该执行的操作，并且不会破坏构建。测试人员应该针对规范进行测试，以确定开发人员是否正确解释了它们（开发人员测试几乎从未发现这些问题）。同行应进行代码审查，以确保遵循标准并促进学习。用户必须进行测试，并且他们将尝试执行没有人期望或在需求中定义的事情。通常这些都是愚蠢的东西，让我们摇头而出，“为什么每个人都会想到这样做？”但是许多其他都是真正的要求，而不是规范，因为没有人费心去询问用户他们需要什么。如果您为不同的客户进行自定义开发，则应特别进行客户验收测试。如果客户在投入生产之前签署了工作，那么表明新的工作请求是新开发而不是错误要容易得多。这可以节省大量的合同战争，而不是为谁支付费用。
此外，让其他人修复您的错误代码是确保继续生成错误代码的最佳方法，这就是为什么我讨厌某些公司拥有开发人员做新事物并支持修复人员的组织结构的原因。此外，管理员修复了错误的代码以节省时间而不将其发送回开发人员进行修复，这导致组织无法解决问题。
我认为质量保证的另一个重要部分是预先花时间来实际定义要求和标准。 （是的，他们将通过任何大型项目进行更改，但仍然需要它们）。没有要求，测试最多是随机的。没有标准，维护可能会成为一场噩梦，而且成本远远高于需要。
质量保证的最后一部分是从错误中吸取教训。不幸的是，在许多组织中，你不能诚实地讨论出错的问题，以及如何防止下次没有陷入指责责任的会话导致人们保持沉默，而不是因为他们的绩效评估而得到不好的评价。 。实际上，性能评估通常对于提高质量的目标是有害的，因为这个原因在许多其他方面。 （查看戴明和全面质量管理，了解质量大师对绩效评估造成的损害的看法。）
理论上，您应该使用质量指标来衡量不合格的质量。但实际上，只要您的组织进行绩效评估，这些数字通常会被“按摩”以使事情看起来更好或衡量问题（更少的代码行并不代表所有情况下更好的代码，更多的错误报告可能意味着我们在查找（或至少报告）错误方面做得更好，而不是代码比过去项目更糟糕，因此无用。
答案 2 :(得分：2)
请注意，“质量保证”通常不是专注于提高质量，而是提供缺乏错误。有可能制作出仍然存在错误的高质量产品（但最好不要成为主要错误）。 It is possible to make a product that is 100% free of errors but still does not provide quality. laser guided scissors http://www.computerweekly.com/Assets/GetAsset.aspx?ItemID=40649
当然，尝试通过各种方式删除产品中的错误并没有错。然而，质量保证的风险在于，关注阻碍发生错误可能会讽刺地干扰提高产品质量。 Tom DeMarco在他的一本书（我不记得哪一本，但可能是Peopleware）中写到了这一点，他将Adobe Photoshop作为他认为高质量产品及其原因的一个例子。
来自wikipedia：
Steve McConnell的代码中的定义 完成将软件分为两部分 件：内部和外部质量 特点。外在质量 特征是a的那些部分 面向其用户的产品，在哪里 内部质量特征是 那些没有。
Tom DeMarco博士的另一个定义 说“产品的质量是一个 它改变了多少的功能 世界变得更好。“这可以 解释为用户的意思 满意度比重要 确定软件的任何事情 质量。
我想另一种说法是，如果QA只专注于内部质量而没有其他人对外部质量负责，那么你最终只能凭借运气获得杀手级产品。我希望我听起来不像是对错误删除不利，我只是想指出它不是一个银弹。
答案 3 :(得分：1)
拥有QA环境，在交付之前对软件进行认证是一种很好的做法。在日常报告中提供清晰的质量指标（系统正常运行时间，关键错误数量，由于流程不良导致的问题数量），如果存在质量问题，则会明确关注质量问题。关于问题项目涉及开发团队的验尸，以确定如何改善初始和持续的质量。任何和所有的沟通都应该是积极的声音，并专注于找到质量低劣的根本问题。有时只是向开发团队询问他们缺乏哪些改进质量的东西可以解决许多问题。
答案 4 :(得分：-1)
对于质量保证而言，了解产品开发的整个过程而不是代码评审更为重要。作为质量保证，非常需要有一个非常清晰的实际需求概念，要开发的功能，保持对单个/多个的跟踪，以便可以根据该时间线创建测试范围。 / p>
为了向开发人员提供反馈，只需查明用户需要的条件，传达任何可能起作用或不起作用的不匹配。这将是一个有效的反馈。