站在QA的角度如何设置一份针对项目的考核表？
各位：目前有这样一个问题：站在QA的角度如何设置一份针对项目的考核表？
目前公司还处于QA和SCM的初期阶段，那么应该对项目考核哪些指标才合适呢？
同行评审发现的问题，配置项周报是否提交，bug率。。。 站在QA角度？考核项目？ 。。。这不能叫考核吧 考核只能针对人员
站在质量保证角度对项目进行考核
领导要求做：站在质量保证角度对项目进行考核。我们公司还没怎么开展质量保证工作，现在就要做这个项目考核表，我都不知道如何入手
我简单做拉一个项目考核表，希望大家能给我多提意见
附件中是我简单设计的一份项目考核表，其中有很多检查项我还不知道要考核哪些指标，希望大家能给点意见补充。目前公司情况是：QA工作还没正式开始，可领导就要弄个考核表，所以我只能根据自己的理解简单做拉一份。我实在不知道在QA实施初期要考核哪些指标。
回复 #4 xiaoqingyu 的帖子
如果你们公司还处于初级阶段，我建议你按照两大方面来进行评价：1、检查执行情况：被检查项目数，不合格项目数，已解决项目数，未按时对应数，
（数据来源：SQA不合格项目一览）
2、配合状况：执行态度，自我解决能力进行打分。
我们公司也是从初级阶段做起的，刚做的时候项目负责人及项目成员这方面的意识不够，配合的很困难，就和你们一样采用评价的手段了。效果真的不错。
回复 #5 xiaoqingyu 的帖子
我正好也在做这个，我们可以交流一下sdlkfj5 项目要考核，考核的方面太多了，所以要做一个项目考核表，似乎有点难！sdlkfj5我想，是否可以先明确你们公司想考核项目哪些方面的情况，然后再针对这些方面分别做出相应的检查表，所有的检查结果统计起来就可以用来考核项目啦。
项目考核的方面，大致可以包括：计划、需求变更管理、评审、配置管理、文档、费用、测试、维护等等~
回复 #5 xiaoqingyu 的帖子
OK sdlkfj2 我也看看 原帖由 luoyear 于 2006-12-19 19:09 发表 http://bbs.51testing.com/images/common/back.gif站在QA角度？考核项目？
楼主看看版主的这篇贴吧
我看你意思是需要建立项目度量，但是项目度量的目的绝不是为了考核，它的目的有两点
1. 一个是反映当前项目的真实状况（问题，成绩等），帮助管理层更好的了解项目状况，项目经理及时调整计划
2.积累历史数据，为以后的项目或者组织内部的基线做贡献
如果我们把项目度量认为是一种考核，就偏离它真正的目的，效果也不会好的
当然我理解在建立质量体系初期，管理层往往希望通过这种方式来加强大家对质量工作的重视，但是如果用它来考核项目或者是项目组成员，很大的一个问题就是你很难收集到真实的数据（原因我就不用说了吧）
所以要明确一点，质量保证工作不是针对人，是要针对过程和系统，做项目度量是为了帮助项目更好的完成项目目标和质量要求，达到客户满意 让QA来公开考核一个项目的情况，易形成项目组和QA人员的对立情形 谢谢楼主了，帮你顶一下 初期，不得不考核，我也选择同样的方式，不然工作难以推动，自己也看不到效果。 QA我个人认为还是不要把自己与项目组对立起来，过程的改进是一个循序渐进的工作，也是一个循环的过程，考核这个词太过于重视，容易引起QA与项目组的对立，这样，QA看到的数据，进行的活动遇到的阻力会很大。
鼓励项目组的成绩，提出更好的建议，采集数据进行度量和分析，总结提交给相关的干系人，初期来说做到这样我个人认为是可以了的 项目质量其实就是研发团队的开发质量，所以你的目的是要去考核研发团队的开发质量。。。
QA去考核的话难度比较大，所以你要换一个说法去执行，站在QA的角度如何去采集相关数据帮助研发团队提高开发质量！（自己清楚是考核就行）
执行方针：考核对象模糊化（不是针对一个项目做的，而是针对一个研发团队的）；考核指标数据化（所有的指标都要量化）
前期状态，结果控制
1.A研发团队的单月bug的关闭周期（总的bug关闭日期/总的bug数量）--关闭时间越长，项目的上线周期也就越长
2.A研发团队的单月bug的Reopen率（总的bug Reopen次数/总的bug数量）--Reopen率越高说明研发修改bug质量不高，会导致bug关闭时间延长，影响项目上线
3.A研发团队的单月bug的later率（很多情况下，为了赶项目进度一些不严重的bug修改会被延后）（总的later bug数量/总的bug数量）--later率越高，说明上线项目问题越多，稳定性越差
4.A研发团队的单月项目平均产生bug数量（总的bug数量/总的项目数量）（数据再细致的话最好采集的是单月A研发团队的平均修改文件产生的bug--总的bug数量/总的文件修改数量）
后期发展，结果控制发展为过程控制（这部分需要QA与SQA紧密配合才行）
举例说明下：A研发团队5月完成40个项目的研发
a.10个项目经过需求评审，设计评审，UC评审，TC评审后测试上线，修改文件100个，发现bug10个，平均项目bug为1个，单个文件修改产生的bug为0.1，平均上线周期为4天
b.20个项目经过需求评审，设计没有评审，UC没有评审，TC没有评审后测试上线，修改文件50个，发现bug40个，平均项目bug为2个，单个文件修改产生的bug为0.8，平均上线周期为8天
c.10个项目没有经过需求评审，设计没有评审，UC没有评审，TC没有评审后测试上线，修改文件50个，发现bug80个，平均项目bug为8个，单个文件修改产生的bug为1.6，平均上线周期为16天
通过一系列的数据对比，很直观的反映出严格的过程执行是质量的保证前提，说白了也就是告诉老板严格按照流程走了，质量就有保证，不按照流程执行，后果一目了然（当然不能说的这么直白）
建议：1.给老板和研发负责人看的时候把所有的数据都图形化，这样更直观
2.给老板看之前先和研发负责人进行沟通（毕竟不教而诛非君子所为） 不错，有收获 其实就是定义出项目的质量目标，双方达成一致后，QA通过一些载体进行数据收集，对质量目标进行度量。
比较说明问题的目标体现在： 交付缺陷率， 客户满意度，送测冒烟通过率，进度偏差率等
页:
[1]
