快捷搜索:  汽车  科技

qa工作内容详细(QA工作如何评价的一点看法)

qa工作内容详细(QA工作如何评价的一点看法)所以,QA发现不了问题的责任不在QA,而是组织。这样的问题不应该打在QA身上,而应打在组织层面。就算QA再认真再努力也不行。所以,长期以来,评价组在评价QA过程域的SP1(客观评价过程)、SP2(客观评价产品)时,经常把评价其他过程域发现的重要的过程问题和产品问题拿过来作为这两个实践没有做好的证据。但是,这样对QA来说是非常不公平的。QA是按照质量保证计划和检查单来工作的,评价员是按照过程和产品是否符合标准和体系的规定来发现问题的,而如果经过组织评审的质量保证计划和检查单没有完全覆盖标准和体系,那么评价员能发现的问题,QA可能根本发现不了。

qa工作内容详细(QA工作如何评价的一点看法)(1)

在实施GJB5000的项目组中,QA(质量保证人员)是个非常尴尬的角色。

一方面,对于这个新生事物,组织对他的职能缺少认同感,做了QA,远不如做开发那样能让组织认可;另一方面,GJB5000评价的时候,就算再认真再努力的QA也会被指出很多问题,这让QA很沮丧。

这里暂且抛开组织对QA这一角色的认识问题不说,只说说为什么评价的时候QA总要担负很多责任——不仅客观评价过程和产品这两个实践有一堆问题,其他过程域的共用实践GP2.9也经常打QA的问题。

这里的一个原因是:一直以来,大家都认为QA是确保过程和产品符合规范的,所以,只要评价的时候发现过程和产品存在的问题,那就是QA的工作没有做好。

所以,长期以来,评价组在评价QA过程域的SP1(客观评价过程)、SP2(客观评价产品)时,经常把评价其他过程域发现的重要的过程问题和产品问题拿过来作为这两个实践没有做好的证据。

但是,这样对QA来说是非常不公平的。

QA是按照质量保证计划和检查单来工作的,评价员是按照过程和产品是否符合标准和体系的规定来发现问题的,而如果经过组织评审的质量保证计划和检查单没有完全覆盖标准和体系,那么评价员能发现的问题,QA可能根本发现不了。

就算QA再认真再努力也不行。

所以,QA发现不了问题的责任不在QA,而是组织。这样的问题不应该打在QA身上,而应打在组织层面。

那么,对QA工作应当如何评价呢?

对QA工作的评价应当从QA的本职工作出发,从以下几个方面对其进行评价:

  • 计划的合理性

QA需要编写质量保证计划,并且确保其与软件开发计划、配置管理计划等计划保持一致。质量保证计划应按GJB438B编写,计划的内容应当完整、正确。

如果计划的内容有错误,比如遵循的标准规范不完整,这样的问题应记在QA过程域的共用实践GP2.2“策划此过程”中。

  • 计划的执行力

QA应严格按照质量保证计划开展工作。质量保证计划中策划了QA评价的过程和产品,以及评价的时机和频次,QA必须按照计划要求去做,不能遗漏一次过程或产品检查。

如果过程或产品的检查没有按计划执行,这样的问题记录在QA过程域专用实践SP1.1、SP1.2中。

  • 检查的有效性

QA依据经过审批的检查单对过程和产品进行检查,他必须逐一核对检查单中的检查项,确保过程和产品符合检查项要求。每一个检查项的“是否不适用”,QA都要认真核实,不能粗心大意给出错误的结论。

如果QA给出错误的结论,这样的问题记录在QA过程域专用实践SP1.1、SP1.2中。

  • 记录的正确性

QA的工作要产生很多记录,如检查单、不符合项跟踪表、QA周报、QA审核报告等。QA必须确保这些记录是完整的、正确的,并且满足体系的要求(比如在QA审核报告中反映质量趋势)。

如果QA的记录不满足体系要求,不完整或有错误,这样的问题记录在QA过程域专用实践SP2.2中。

  • 问题的闭环

QA对评价过程发现的问题,要确保问题闭环。如果问题责任人有争议,可以通过上报渠道仲裁解决。

如果QA的不符合项问题处理不符合体系要求,或者问题实际未关闭,这样的问题记录在QA过程域专用实践SP2.1中。

实际上,这种评价方式已经被很多评价员所接受,并且在评价过程中这样实施。

这正是:

Q A 工作如何评,工作责任要分清

有些问题在组织,个人承受太不公


文章来自软件工程之思,侵权联系删除!!


猜您喜欢: