砸场子的来了～：SQA有啥用？

ivan_d

看来QA的工作很难做呀,不过一定要坚持

ivan_d

刚开始做QA,先来学习一下,收益匪浅!

rainshadow96

原帖由 iamredeye 于 2008-5-21 21:47 发表
总结几个问题吧：
1。QA自身有能力给项目带来价值吗？如果不明白pm，process，engineering等等，那就。。。
2。身在局外，QA能否有渠道了解项目中真正发生的事情？还是只能吃PM嚼过的馍，发一些PM根本不关注的repo ...

说得很好, 特别是第六点。

blanche

QA更多的时候应该是个咨询师呢，所以做好QA不容易，但做好了就会非常有用噢

iamredeye

楼上说得很对。以Auditing的方式确保项目的成功并不是一个好的选择，反而退一步提供咨询更容易摆正位置。

但是成功的咨询需要相当的火候。

iamredeye

原帖由 Scott 于 2008-4-23 13:14 发表
本来想写写，发现何丹博士的生如夏花已经描述的很清楚，这里只能借花献佛了：QA，从监督到咨询。

我在引导一个项目时，项目刚刚完成单元测试阶段，准备进入系统测试阶段（集成测试裁剪掉了）。这时我对单元测试阶 ...

to Scott，我刚才在复习这个帖子，看到你们在跟踪单元测试，比较好奇，因为刚好最近对这个比较关注。单元测试如果有bug的话一般来说是不允许进行integration的，可能除了少数暂时不重要的warning，这也就是单元测试为什么存在。所以我对你说的这个下限我比较困惑。能否简单介绍一下你们的策略和方法？谢谢

Scott

请完整的看这段话：
"我在引导一个项目时，项目刚刚完成单元测试阶段，准备进入系统测试阶段（集成测试裁剪掉了）。这时我对单元测试阶段做了一个质量分析，发现这个阶段发现缺陷虽然满足目标下限，但是远低于同类项目的平均水平，而这个项目最终的质量目标比同类项目还要提高很多。"

意思是：UT已经结束，Bug已经解决了，没有遗留，接下来裁剪了IT，所以直接进入ST。

至于下限，举一个例子：比如我们单元测试缺陷发现密度质量目标是10个/Lloc，上限12，下限8；系统测试5个/Kloc，上限7，下限3（数字纯属虚构）

UT结束后，我们发现为8.2个/Kloc，达到下限8个/Kloc。但是同类项目基本都在11左右，那么我们有理由怀疑UT不充分，为此，我们可以提升ST阶段质量目标为7，上限9，下限5。从而引导项目组在ST阶段发现缺陷，而不是遗留到外部。

iamredeye

了解！

另一个问题：那在你们公司的实践中，会不会有个别项目组为了满足这个单元测试缺陷密度目标有意或多或少降低coding质量，去提高缺陷密度呢？

iamredeye

了解！

另一个问题：那在你们公司的实践中，会不会有个别项目组为了满足这个单元测试缺陷密度目标有意或多或少降低coding质量，去提高缺陷密度呢？或者说怎样避免这种情形？

yesongke

redeye，你说的现象也是有可能出现的，不过出现更多的会在测试用例的设计上。通过设计无用、多余甚至是错误的测试用例，来满足测试密度和缺陷率。
    这个时候最主要也最有效的方式就是同行评审，对代码的评审，用例设计的评审，抓好评审的质量，基本上就可以避免了。但指标也只是参考，不能为了达到指标而盲目地要求项目组。
    说明一下，即使同行评审通过了，也有必要对其中部分成果物做抽查，做了是一回事，相信是一回事，而结果是另一回事。总不能因为相信人不会犯错就把检察院、纪委都给撤销了吧

iamredeye

层层检查监督毕竟都是事后处理，当然未必没有效果；不过有没有更好的鼓励或引导方式呢？

Scott

如果你是用代码规模或者引入缺陷来衡量开发人员，或者用发现缺陷来衡量测试人员，那么不可避免的会产生你说的情况。

但是，有一个人你可能忽略了，那就是项目经理。我们无法去准确衡量或者说成本较高的衡量开发人员参与每个项目的情况，但是我们可以跟踪这个项目/版本的最终质量，比如半年后我们来回头统计这个项目/版本的缺陷，那么这个项目经理也就被考核了。反过来，他要保证缺陷尽可能的被发现而不是遗留到交付之后。同样，这些缺陷可以用于产品线的衡量，直接关系到产品线的奖金。

从一个完整的版本来看绩效，而不是从局部来看绩效，这是一个很关键的问题，QA也应该具有这种全局观，否则只会“头疼医头，脚疼医脚”。

Scott

“说明一下，即使同行评审通过了，也有必要对其中部分成果物做抽查，做了是一回事，相信是一回事，而结果是另一回事。总不能因为相信人不会犯错就把检察院、纪委都给撤销了吧”

可能各个公司的情况不一样，各个QA的能力也不一样。我比较忌讳的是审核，我很少开不符合项，来了快1年只开过2个，而且都是已经更改完成只是走个流程的。

我觉得无论是审核项目组或者项目经理，其实他们有时也很无辜，很多时候是因为我们的流程真的做不到有效，比如估计，哪有什么真正意义上可参考的数据，可我们非要项目经理去参考，结果还是要靠项目经理的经验，有的PM好些，做了也不说什么，有的愿意唠叨就说几句，有的不愿意“中性”就是不写，结果就被QA审核出来，不过这个估计更改一些对产品最终质量会有很大影响么？我个人持怀疑态度。
还有的非要项目经理去纠正，可高层领导在催着项目“交货”，自然就出现对付的情况。

万事皆有因，皆有果。出了问题大家一起来分析解决才是一个很好的办法，不要强迫，要学会尊重，记住QA不一定会比PM强很多。

QA和PMA总拿着手里的两种武器，一是审核，二是设关卡，这两个对于项目组就像税收对于农民；其实QA和PMA的眼光应该放的大一些，就像一个国家，粮食丰收了，少的税收，但是国运会更加昌盛，从一个国家角度来说是好事，如果QA和PMA能够帮助项目一路解决问题，用不了2个项目，你就会融入到项目组里去。

所以说，我做QA的体会是 用心。用心去体会项目组的困难，用心去了解整体的情况，用心去解决真正的问题，问题没有大小，解决一个少一个，1年不行就3年，3年不行就5年，只要你经历过这些问题，以后也就不成为问题。其实很多QA觉得很难做QA，不愿意做QA，就是缺少用心二字，遇到问题就抛给项目组，可实际上自己都没有一个很好的解决办法。我从来不会只提问题，我提出的问题都会带着至少一个解决方案，而且如果这次我不能说服项目经理，我不会要求他一定执行，我回头会再去找解决的办法，下次继续说服他，很多这样的项目经理甚至产总都是这样多次磨下来的，我叫做自己是跟屁虫。

yesongke

原帖由 iamredeye 于 2008-7-10 12:58 发表
层层检查监督毕竟都是事后处理，当然未必没有效果；不过有没有更好的鼓励或引导方式呢？

        CMM/CMMI体系本身就有提高项目过程可视化、透明度的含义，检查监督是事后的，不过是部分的事后，我们一般会在该阶段工作完成1/5～1/4的时候进行抽查，（太少会缺少普遍性，太多了意义就不大了），当然，同意Scott的意见，尽量不要开不符合项，我们一般会跟PM报告这种现象（记着是这种现象而不是这些责任人），并尽可能提出改进意见，最后协同PM一起解决，同时继续跟踪问题的状况。
    过程的执行和过程的执行质量是两码事，我们也很愿意相信每个人都会尽力做到最好，但也不可否认会存在内在的、外在的、自觉的、不自觉的、不可抗拒的因素，使得即使过程执行了也只是一个形式，如果是这样，强调过程反倒是项目的一种累赘了吧？
    说起来评审等都应该是对事不对人的，对人员的衡量也不应该仅仅通过缺陷等来确定。工作量、工作质量、工作效率，工作态度、协作能力等等都可以列为考核的内容，而且为避免主观性，考核评定人也应该是多方面的吧。比如PM、SQA、被评定人自评等。啊。。。说起绩效考核，好像又跑题啦:P

Scott

to yesongke，你对研发绩效管理了解如何？有兴趣可以再开一贴来讨论讨论，最近研发总工就和我说这个问题，问我研发绩效管理如何建立会比较适合公司，弄得我脑袋晕晕的，一直在找这方面的知识。说实话，开发人员还好说，那些测试部、系统部、硬件...的人都是很难管的主：（