博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
有效性的QA审核检查单
阅读量:5935 次
发布时间:2019-06-19

本文共 7169 字,大约阅读时间需要 23 分钟。

经常有这么一个问题:QA为什么对过程改进有帮助。答案当然与如何理解、如何管理、如何处理QA与项目之间的关系密不可分。这里有很多议素我们需要好好探讨。其中一个比较实在一点的,就是如何让QA可以在审核之中,发现项目是否遵从标准规程之余,还能否发现可以提高项目效率的机会,并且提出有针对性地建议,让项目可以更有效地达成项目的目标。
  QA审核的内容,通常都可以从审核的检查单之中看到一个端倪。如果检查单里的问题,他们的答案明显与项目的效能无关的,按照这样的检查单审核,就当然不能发现如何帮助项目提高效能。所以我提到QA需要制定“有效性”的检查单。
  问题立刻出现了,就是“什么样的检查单才是有效性的检查单?”本文的目的就是希望解答这个问题。
  
让我首先作几个声明:
  1)当我们谈“有效性”审核的时候,我们不是说“遵从性”的审核不好。我希望强调一点:“遵从性”是制度化与成熟程度的基础。没有了遵从性的团队、组织,是不成熟的,过程操作一般是低效的。只有具备了一定程度上的遵从性,过程管理才能开始生效。请大家明白这一点。
  所以我们谈有效性审核,其实是说在遵从性审核的基础上,考虑有效性的问题。这是一个能力水平的提升,而不是一个对标准规程的叛逆。
  2)要提升过程的效能,因为每一个项目团队能力、风格不一样,是需要针对性的。这些针对性,就反映在调整检查单上面。我也遇到过这样的问题:“QA的标准规程里有标准的检查单,我们是否必须者用同样的检查单,才是符合标准的QA审核?”
  我希望说明的就是:在符合标准要求的情况下,进行部分的调整是可以容许的。这个概念,就体现在   要求标准规程里提供“适配”,并要求制定适配的准则。我们需要了解这一点。当然这个需要对规程与过程管理具备一定的了解与判断能力。这些知识与经验是需要积累的。
  3)千万不要认为只有一个方法制定检查单。做任何事情,都有很多实际方法、途径可以完成。这里只是一个案例。我希望大家可以看到要考虑什么问题,要如何思维,然后发展自己的观察、分析、判断等能力,这才是最重要的。
  好了,我们就谈谈如何制定“有效性”的检查单吧。我拿了一个案例来说明。这个案例是一个组织在使用的,用来审核“估算”的标准检查单。这里就来说明如何从这个检查单开始,加入“有效性”因素的考虑,来达到一个既满足本来的遵从性审核任务,也可以反映项目的操作是否有效的检查单。
  
制定有效性检查单的步骤:
  1)我们要知道,“有效性”就是能够达到目标。如果没有目标,或是QA不清楚目标,有效性是无从谈起的。
  所以QA一定需要知道检查单上面每一个条款,如何与项目的目标相关联。
  2)符合性与有效性既相互关连,也相互独立。如果要过程有效,我们需要建立制度化。制度化的一个条件,就是每一个员工都需要有愿意遵从规程,符合规程的意愿。我们需要用一种大家都了解的,一致的方法,来处理日常的、或是不理想的、特殊的情况。要过程改进,我们就需要有遵从的纪律。
  所以有效性是建立在“遵从、符合”的基础上的。
  另一方面,如果规程制定得不合理,或是缺乏灵活性,来适应不同的项目、技术、产品。比如,无论项目大小,周期长短,都要求用“Wideband Delphi”进行估算。这就不灵活了。短周期的小项目就很不适合了。又或是要求严格复杂的 分析、策划等等,也有同样的问题。那么,项目的过程就是符合,也不会有效。
  所以QA需要具备专业态度与独立精神来处理现实中“符合性”与“有效性”的冲突与一致。
  3)因为过程有效性,就是能够达到目标。那么,审核过程的有效性,就需要判断。所以一定要求审核的人(QA)具备这种判断能力,而不是期待把检查单细化到没有判断能力的人也可以实施。
  
举一个例子,如果检查单里的问题是:
  一)估算是否按计划的时间完成? 那么谁都可以判断。但这不是有效性的。因为我们没有考虑不按计划的时间完成是否影响项目的目标。
  二)估算完成的时间是否对项目达成目标造成风险?这个问题才是有效性的。那么,就需要判断了。我们不能够有效地定义:超时两天就可以,三天就不可以。这在大部分的情况底下其实是不可能的。能够回答这类问题的人,需要有判断能力。
  这是为什么我们要求QA不断提高自己的能力的原因。
  谈到QA能力,我在这里先问一下:我们可否识别“子过程的目标”与“审核子过程的目标”?我们需要能够分辨这个。举一个例子:“同级评审”的目标,就是发现缺陷。但是为什么我们要审核“同级评审”这个子过程?那么目标就可以有很多:比如,作为考核的依据;查看项目是否遵从标准规程;评价这个子过程的操作实效;发现项目是否具备实施同级评审的技巧,等等。我们一定要能够分辨这些不同层次的目标。
  4)总结一下:要从事有效性的审核也好,制定有效的规程也好,就需要考虑:
  每一个条款或是步骤是为什么,要解决什么问题? (要解决什么?)
  这个条款或是步骤有什么后果? (有什么后果?)
  这些要解决的问题与实施后果如何影响项目的目标?(对项目的影响与风险)
  这些就是QA需要能够回答的问题。
  QA需要养成一个考虑这些问题的习惯来建立自己回答这些问题的能力。
5)假设我们已经具备这些能力,那么制定有效性的检查单就不难了。第一个考虑的概念,就是“层次”。假设EPG提交了一个检查单,如下:
  
检查项包括:
  是否按时进行了二次估算?
  作者是否参与集成测试活动估算?
  作者是否参与各模块开发活动估算?
  开发相关人员是否都参与集成测试活动估算?
  是否会议方式估算?
  详细设计估算是否完整有效?
  编码估算是否完整有效?
  单元测试估算是否完整有效?
  集成测试用例估算是否完整有效?
  集成测试执行估算是否完整有效?
  偏差超过约定的偏差值是否再次估算?
  是否完整填写估算人员姓名及过程数据?
  估算报告是否及时归档?
  
我们可以看到,这个单里的条款,它们的重要性不是同一个层次的。这不是一个制定任何规程的好习惯。我们需要知道把同一个层次的条项罗列在同一个层面上。比如:
  是否按时进行了二次估算?
  作者是否参与集成测试活动估算?
  有哪些与这个估算相关的活动?
  作者是否参与各模块开发活动估算?
  开发相关人员是否都参与集成测试活动估算?
  是否会议方式估算?
  有哪些与这个估算相关的绩效?
  详细设计估算是否完整有效?
  编码估算是否完整有效?
  单元测试估算是否完整有效?
  集成测试用例估算是否完整有效?
  集成测试执行估算是否完整有效?
  偏差超过约定的偏差值是否再次估算?
  估算报告是否及时归档?
  层次这个概念在很多地方都有应用。看看我们公司的结构,你就可以体会到层次的普遍应用程度。不同层次的,就不会在同一个级别的领导之下。比如,生产、财务、市场都是在同一个层次上。我们不会把“融资”放在同一个层次,它一定是在财务底下的。
  层次会影响效率。比如我们的检查单,合理的层次,会让员工与QA更明确各个部分的重要性,在开展工作的时候也可以更好地掌握注意力。
  要了解层次,可以这样看:同一个层次的,是比较相对独立,互不影响的。低一个层次的,是它上面层次的一部分,或者说,是会对上面层次的提供贡献。比如:“是否按时进行了二次估算?”和“有哪些与这个估算相关的活动?”是相对独立的。但“作者是否参与各模块开发活动估算?”就是与估算相关的活动之一。这个有点像CMMI的级别定义原则。这些都是帮助有效的理念,并且被广泛应用在过程管理与以外的很多方面的。
  检查单的组织可以考虑条项的层次。
  如果不了解这个“层次”的观念,就请你提问。我们务必交流清楚。
6)下一步就是分辨符合性与有效性。还记得上面提到的三个考虑么:
  每一个条款或是步骤是为什么,要解决什么问题?(要解决什么?)
  这个条款或是步骤有什么后果? (有什么后果?)
  这些要解决的问题与实施后果如何影响项目的目标?(对项目的影响与风险)
  我们要知道,如果问题是:
  是否按时进行了二次估算?
  我们的答案就会是“是”或是“否”。这个问题要解决的,就是:你是否遵从计划?是一个符合性的问题。所以解答这个问题一点都不难。但是如果问题是:
  完成二次估算的时间对项目有什么影响?
  这个问题要知道完成时间对项目有什么影响,要知道估算知否有效。这才是有效性的检查项。回答这个问题就一点都不简单。我们要知道这个完成时间有什么后果。早于计划的要求完成?按计划时间要求完成?超时了?超了一点点?超了很多?还有更厉害的:这个模块/任务是否在关键路径上面?我们要知道所有这些,可能还有其他的,才能作一个判断。做这个判断,就要知道关键因素与它们的后果。比如:
  估算晚了两个星期。但这是一个2 年的项目,而且这个任务可以有5 个星期的灵活性。那么,这样晚了两个星期的作用就不很大。他是不符合。但后果不大。
  如果估算晚了两个星期,项目是2 年的项目,而且任务是在关键路径上。后果就可能让项目延误两星期。是大概2 %的延误。这样的延误,绝大部分客户可能发现(重要),但都不会太计较的(不严重)。
  如果估算晚了两天,任务在关键路径,项目是2个月的项目。这样问题就严重好多了。
  所以如果要作有效性审核,我们需要知道关键因素,以及他们的后果。
  一个步骤的目的,如果单单是看项目是否符合,而不考虑后果的,这样的管理,目的就是在于“限制行为”。限制或是规范行为的坏处,就是引起项目的抗拒。所以“限制行为”的管理很难有好效果的。
  7)那么,我们可以开始把这些关键因素组织一下,为把检查单改变成为有效性的检查单做准备。我们需要把原本的改成符合与有效兼顾,并且增加一些遗漏的关键因素。首先,我们可以把下面的条项:
  是否按时进行了二次估算?
  作者是否参与集成测试活动估算?
  有哪些与这个估算相关的活动?
  作者是否参与各模块开发活动估算?
  开发相关人员是否都参与集成测试活动估算?
  是否会议方式估算?
  有哪些与这个估算相关的绩效?
  详细设计估算是否完整有效?
  编码估算是否完整有效?
  单元测试估算是否完整有效?
  集成测试用例估算是否完整有效?
  集成测试执行估算是否完整有效?
  偏差超过约定的偏差值是否再次估算?
  估算报告是否及时归档?
  小心看一下,用提高效率的观点,考虑每一个条项的后果,改编成有效性的条款,如下:
  估算完成的时间对项目的影响:
  作者乐于承诺估算结果的程度与原因:
  (暂时忽略)
  估算的方法与过程保证了估算的合理性:
  (暂时忽略)
  (暂时忽略)
  估算结果得到维护与使用:(包含了“估算报告是否及时归档?”)
  我们现在加入我提到的三个因素:
  负责任务的人亲自牵头估算
  大家(项目组与客户)对任务范围与内容的认识是一致的。
  方法与参考数据的使用是合理的
  检查单就变成:(斜字代表这个步骤新加进来的。)
  估算完成时间对项目的影响:
  作者乐于承诺估算结果的程度与原因:
  负责任务的人牵头估算
  估算的方法与过程保证了估算的合理性:
  大家对任务范围与内容有一致的认识
  估算方法适合项目要求
  方法的调整是合理的
  估算结果得到维护与使用:
  项目计划使用了估算结果来安排任务
  如果需要,可以把原来的符合性的放回去。可以把它们放在另一个部分,也可以把它们放在适合的层次。比如:
  估算完成得时间对项目的影响:
  ·  是否按时进行了二次估算?
  作者乐于承诺估算结果的程度与原因:
  ·   负责任务的人牵头估算
  估算的方法与过程保证了估算的合理性:
  ·  大家对任务范围与内容有一致的认识
  ·  估算方法适合项目要求
  ·  方法的调整是合理的
  ·  是否会议方式估算?
  ·   作者是否参与各模块开发活动估算?
  ·   开发相关人员是否都参与集成测试活动估算
  ·  (如果用Delphi方法)偏差超过约定的偏差值是否再次估算?
  估算结果得到维护与使用:
  ·   估算结果在计划里项目计划使用了估算结果来安排任务
  ·   估算报告是否及时归档?
  以往估算的绩效:
  ·   详细设计估算是否完整有效?
  ·   编码估算是否完整有效?
  ·   单元测试估算是否完整有效?
  ·   集成测试用例估算是否完整有效?
  ·   集成测试执行估算是否完整有效?
  现在的检查单包含了本来的条项,也包括了从有效性的角度的内容。但有效性方面还是不充分的。所以我们需要每一个条项都问这个问题:
  我如何可以判断这些条项的有效程度?这个也需要我们了解过程的关键因素!
  上面已经提到过估算的完成时间如何影响项目。包括延误的比率、客户的要求、任务是否在关键路径等等。其他的,我就把我考虑的加到相关的条项底下,如下:
  估算完成得时间对项目的影响:
  ·   是否按时进行了二次估算?
  ·   延误程度对比项目的里程碑与周期的影响有多严重
  ·   延误如何对比任务的关键路径宽容时间
  ·   考虑这个任务的关键性与项目对它的依赖程度
  作者乐于承诺估算结果的程度与原因:
  ·  负责任务的人牵头估算
  ·  判断负责人对结果的信心
  ·   查看负责人以前的承诺(按时完成任务)表现
  估算的方法与过程保证了估算的合理性:
  ·  大家对任务范围与内容有一致的认识
  o    在如下面两条罗列的估算活动以及其他情况底下,多方面的干系人的表达是一致的。
  o    如果有开估算会议,讨论覆盖足够的内容与议素,但进行顺利,没有理解不一致的迹象。
  o    (还可以有其他的蛛丝马迹来判断)
  · 估算方法的效能适合项目的目标
  ·  参考与使用的历史数据与对比、调整的合理性
  ·  是否会议方式估算?
  ·  作者是否参与各模块开发活动估算?
  ·  开发相关人员是否都参与集成测试活动估算?
  ·   偏差超过约定的偏差值是否再次估算?
  估算结果得到维护与使用:
  ·  项目计划使用了估算结果来安排任务
  ·  项目明确有哪些活动受这个估算结果影响(可以更好处理将来的延误)
  ·  估算报告是否及时归档?
  以往估算的绩效:
  ·  详细设计估算是否完整有效?
  ·  编码估算是否完整有效?
  ·  单元测试估算是否完整有效?
  ·  集成测试用例估算是否完整有效?
  ·  集成测试执行估算是否完整有效?
  希望大家可以关注到这里检查点之间的关联性,以及我们的步骤如何影响项目的专注。
 8)上面的表就是一个从你们本来使用的检查单,增加了审核有效性的角度而得来的。让我们把这个资料放到一个表格里:
  大家可以补充“检查方法”这一列。大家也可以按这个思路,增、减因素与检查项的内容与细节。其实标准的检查单,也应该可以让大家按情况“调整”。请留意,我不说修改,而说调整,含义是:我们需要按标准的思路,让它更有效,而不是把内容随意变动。我说的明白么?
  这样的表格跟以前的有两个分别:
  语气是开放式的,不鼓励是否地打勾。每填一个条项,都希望QA知道需要明白后果。以后习惯了这样思维,我们就可以不那么关注语气的问题了。我鼓励大家目前还是在意一点比较好。
  内容多了一些有效性的关键因素。这个是可以积累的。我们需要从工作中观察,以需要多讨论,多交流,多看书。一位QA发现一个关键因素之后,不能单单加到自己的检查单里。QA小组最好组织讨论会议,让每一位QA都知道一个关键因素的来龙去脉,原因后果。这样才能让QA团队的经验建立起来。
  也请留意,每一个关键因素都有数个检查项,但对项目来说,同一个关键因素的所有检查项加起来只有一个后果,我们不单单在乎是否打勾,而是要判断项目的表现有什么后果。我们可以按关键因素预设一些后果。比如:超越预期、没有风险、有可承担的风险、有不可承担的风险、不可承担又不可缓解的风险等。项目的操作状态,就是这几个关键因素的执行后果。每一个关键因素的后果,都取决于它下面的检查项。但我以前也说过,我觉得每一项打分,然后加起来,不是一个很好的方法,因为有些条项的重要性,会因为其他的条项内容而改变的。我们可以这样做,然后参考那些分数。只是不要把分数看成决定一切就可以了。
  想象一下,如果我们的QA审核报告都是这样的,大家就会越来越清楚如何提高项目的效率。将来的过程问题,大部分都可以从QA报告的历史资料找到答案。过程改进将会变得非常容易。
  9)不要以为这是唯一的有效性检查单,所以不要把这个看成经典。有效性的检查单可以有很多。比如,我们如果不一定要求从你们本来的检查单开始,我们可以从我提到的三个因素开始。那么,检查单就会不一样。
  我们要能够分辨得细一点,要争取了解细一点的议素。比如,不要把上面的检查单看成固定不变的。但也不要以为什么事情都不能是固定的。有些事情固定了,就不灵活,不能适应不同的情况,效果就不好。有些事情是不会改变的,改了,就没有效果了。如何判断呢?
  基本上:
  因果关系是不会变的。没有了因,就不会有果。
  解决方案,就几乎永远都会有不同的方案,达到相同或是接近的效果。
  要进步,我们就要慢慢掌握这些理念,并且能够把它应用到自己的工作上。
最新内容请见作者的GitHub页:http://qaseven.github.io/ 

转载地址:http://vbntx.baihongyu.com/

你可能感兴趣的文章
Polar码引发舆论狂欢 5G标准远未定局
查看>>
KSImageNamed-Xcode-master
查看>>
tomcat 8.0虚拟机配置文档
查看>>
轻松实现基于Heartbeat的高可用web服务集群
查看>>
pxc群集搭建
查看>>
JS中加载cssText延时
查看>>
常用的脚本编程知识点
查看>>
坐标转换convertRect
查看>>
XILINX_zynq_详解(6)
查看>>
计算机网络术语总结4
查看>>
新手小白 python之路 Day3 (string 常用方法)
查看>>
HTML5 Geolocation API工作原理[转载]
查看>>
soapUI的简单使用(webservice接口功能测试)
查看>>
框架 Hibernate
查看>>
python-while循环
查看>>
【微信小程序】再次授权地理位置getLocation+openSetting使用
查看>>
手机端上传图片及java后台接收和ajaxForm提交
查看>>
HDU 5030 Rabbit's String
查看>>
【MSDN 目录】C#编程指南、C#教程、ASP.NET参考、ASP.NET 4、.NET Framework类库
查看>>
jquery 怎么触发select的change事件
查看>>