质量保证流程-最佳想法

• 除非问题率非常低,否则请使用数据库跟踪问题。
• 通过让开发人员进行TDD,使QA过程变得有趣。( Test-Driven Development )这对他们有好处,而且它能清除那些愚蠢的虫子。
• 自动化测试。
• 让QA从一开始就参与到产品中,而不仅仅是最近两周。
• 给他们力量。QA决定产品何时可以发货。
• 给QA一条真正的职业道路。

我认为所有的质量保证都是多管齐下的。开发人员必须测试他们自己的代码,以确保它做了他认为应该做的,并且不会破坏构建。测试人员应该根据规范进行测试,看看开发人员是否正确地解释了它们(开发人员测试几乎从未发现这些问题)。同行应该进行代码审查,以确保遵守标准并促进学习。用户必须同时进行测试,因为他们将尝试做需求中没有人期望或定义的事情。通常这些都是愚蠢的事情,让我们摇摇头,然后说,“为什么每个人都想这样做?”但还有许多是不在规范中的真正需求,因为没有人费心问用户他们需要什么。客户机验收测试应该完成,特别是当您为不同的客户机进行定制开发时。如果客户在工作投入生产之前就已经签署了工作,那么表明新的工作请求是新的开发而不是bug就容易多了。这可以节省大量的合同纠纷,让谁来为某件事买单。

另外,让其他人修复你的坏代码是确保坏代码继续产生的最好方法,这就是为什么我讨厌一些公司的组织结构,即让开发人员做新的事情并支持修复人员。此外,如果管理者修复了错误代码以节省时间而不将其发送回开发人员进行修复,则会给组织带来问题,使其无法修复。

在我看来,QA的另一个重要部分是提前花时间来实际定义需求和标准。(是的,它们将通过任何大型项目进行更改,但它们仍然是必需的)。没有要求,测试最多是随机的。如果没有标准,维护可能会成为一场噩梦,而且成本远比需要的高。

质量保证的最后一部分是从我们的错误中学习。不幸的是,在许多组织中,你不能诚实地进行项目后的讨论,讨论下一次出了什么问题,以及如何避免这种情况发生,而不进行指指点点的指责会议,这会导致人们安静下来,而不是在他们的绩效评估中得到不好的分数。事实上,由于这个原因,绩效评估通常对提高质量的目标有害。(查阅德明和全面质量管理,了解质量大师对绩效评估造成的危害的看法。)

理论上,应该有质量度量标准,您可以使用这些度量标准来度量提升的质量。但实际上,只要您的组织有绩效评估,这些数字通常会被“按摩”以使事情看起来更好或衡量工作(代码行数越少并不意味着在所有情况下代码越好,更多的错误报告可能意味着我们正在更好地查找(或至少报告)错误,而不是代码比以前的项目更糟糕),因此毫无用处。

请注意,“质量保证”通常不注重提高质量,而是提供没有错误的地方。有可能制造出仍有错误的高质量产品。( 但它们最好不是主要的错误 ) 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

当然,无论如何,试图消除产品中的错误并没有错。然而,质量保证的风险在于,将重点放在阻止错误发生上可能会具有讽刺意味地干扰产品质量的提高。汤姆·德玛科在他的一本书中写到了这一点(我不记得是哪本,但可能是 Peopleware )他以Adobe Photoshop为例说明了他所认为的高质量产品及其原因。

从 wikipedia :

史蒂夫·麦康奈尔法典中的定义 完全将软件分为两部分 件:内外质量 特点。外部质量 特征是 面向用户的产品,其中 内部质量特征是 那些没有的。

汤姆·德马克博士的另一个定义 说“产品的质量是 它改变了多少 世界会变得更好。 解释为用户的意思 满足感比 决定软件的任何东西 质量。

我想另一种说法是,如果QA只关注内部质量,而没有其他人对外部质量负责,那么你只能靠运气得到一个致命的产品。我希望我的声音不要像是我对错误的否定消除,我只是想指出,这不是一个银弹。

拥有一个质量保证环境,在交付前对软件进行认证,这是一个很好的实践。在日常报告中提供清晰的质量指标(系统正常运行时间、关键错误数量、流程不良导致的问题数量),如果存在质量问题,则保持对质量问题的清晰关注。在Problmatic项目中,让开发团队参与事后分析,以确定如何改进初始和持续的质量。任何和所有的沟通都应该以积极的声音进行,重点是找出质量低劣的根本问题。有时,仅仅问开发团队他们缺少什么来提高质量就可以解决许多问题。

对于质量保证来说,更重要的是了解产品开发的整个过程,而不是代码审查。作为一个质量保证,非常需要对实际需求、要开发的特性有一个非常清晰的概念,对要开发的单个/多个特性进行跟踪,以便根据该时间线创建测试范围。

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