无赖的工作，望大家指点迷津

首先说明下我现在是手机上的网，内容格式可能不太好，望大家见谅。我主要想问下大家：如何保证测试与研发的良性发展。由于我自己没的这方面的经验，只是以前在网上看到如下做法：每测一bug，奖测试人员多少钱，扣开发人员的钱。但明显这样做并不好，有人提出只奖不扣，但这样似乎又存在作※卍弊隐患。当然也有人建议不采取任何措施，各尽其责。我现在的工作和这种状况很相似，希望大家给指点一下，不甚感激。目的主要是保证产品质量和公司部门的良性竞争与发展。

评论

22 楼 kimmking 2010-06-16  

我们目前的team是出一个稳定版本前，举行一个为期一周的bug bash，
每天出问题最多的模块，开发人员晚上请宵夜。
一周后，统计所有人发现bug的数量*加权，总分最高的前几名有100-500的奖励。

21 楼 86asm 2010-06-15  

   谢谢大家的意见，我现在才深刻体会到管理确实不易，看似没的什么可做，实际是无从下手，虽然现在真正要我做的事很少，但也感觉不怎么能适应，上班有一段日子了，感觉没做到什么有实质性的事，有点小迷茫。。。
    至于提到信任问题，个人觉得不是所有事都能靠信任解决，而且测试来讲我个人感觉应该是对事不对人。还有大家提到一个TEAM，由于某些原因这个目前在我们这不怎么可能，老大的老大看的是结果，而我们要注意的是在过程中监控协调好。
    还有度的问题，确实不怎么好把握，不过老大提到的“开发人员要有品质意识”，个人认为这点对于开发人员的来讲还是有点意义。
    至于大家提到的一些较具体的方案，我只能是向上面反映下，看上面怎么做。。
    3Q了
   
   

20 楼 linxux 2010-06-14  

这个……
我们没有什么bug的奖罚机制 感觉这个具体不好界定不好实施……

现在的要求是
开发的检查代码覆盖率，
测试的编写测试用例，然后一起做个用例review
等...

19 楼 miaow 2010-06-13  

抛出异常的爱 写道

miaow 写道

呃，都有奖有罚就好了。
开发人员的bug在一定范围内不扣，UAT阶段bug低于一个比例有奖。
测试人员SIT阶段发现bug有奖，UAT后出bug超过一定数量的扣钱。

不能光想着不花钱，整个团队做得好是要总和起来有奖拿的。
大家可以都拿奖，如果能做到发现的bug一直够少。
也可能大家都受罚，如果发现的bug很多而且UAT阶段bug也很多。
要是公司不这么认为，作为项目经理至少要尽量争取。

PS,主要是具体数量范围这玩意不好定。
PS2,我觉得用规划人天的bug数比行数好点。当然这也是拍脑袋。

没作过测试所以.....
会有这种想法.....
等你作作测试就明白了

请明示。

18 楼 a282791718 2010-06-13  

钱不是解决根本问题的办法，要做好前期的需求准备，测试计划准备。
测试人员首先要完成测试用例，
同时允许开发员出现可允许范围的bug数量。毕竟人无完人。
最大程度的控制bug的产生，对项目有可控性。

17 楼 fantasy 2010-06-13  

有BUG是正常现象。不完善的软件开发过程中，成本都消耗在修改BUG当中了，与其消耗不如奖励。
能够将BUG数控制在一定的区间内，如90%，应该奖励。
如果BUG数在一定区间下，应该先面谈一下，如果持续出现，就应该惩罚了。

16 楼 Angel_Night 2010-06-13  

紧急下潜 写道

想依靠考扣钱来提高质量，这是我见过的最差劲的做法。
我认为除了扣钱之外，可以提高软件质量的方法真的有很多，就看你自己有没有这个决心和能力

能列举一下么...

这样说太概括了...

我见识少...真不知道那些方式比较好

15 楼 紧急下潜 2010-06-13  

想依靠考扣钱来提高质量，这是我见过的最差劲的做法。
我认为除了扣钱之外，可以提高软件质量的方法真的有很多，就看你自己有没有这个决心和能力

14 楼 huangc1215 2010-06-13  

测试和开发人员捆绑在一起，要奖都奖，要罚都罚。要不就等着两边干架吧

13 楼 抛出异常的爱 2010-06-13  

miaow 写道

Angel_Night 写道

关键在于度吧
比如说 每千行允许出现多少个bug...超了再扣钱...

呃，都有奖有罚就好了。
开发人员的bug在一定范围内不扣，UAT阶段bug低于一个比例有奖。
测试人员SIT阶段发现bug有奖，UAT后出bug超过一定数量的扣钱。

不能光想着不花钱，整个团队做得好是要总和起来有奖拿的。
大家可以都拿奖，如果能做到发现的bug一直够少。
也可能大家都受罚，如果发现的bug很多而且UAT阶段bug也很多。
要是公司不这么认为，作为项目经理至少要尽量争取。

PS,主要是具体数量范围这玩意不好定。
PS2,我觉得用规划人天的bug数比行数好点。当然这也是拍脑袋。

没作过测试所以.....
会有这种想法.....
等你作作测试就明白了

12 楼 miaow 2010-06-13  

Angel_Night 写道

关键在于度吧
比如说 每千行允许出现多少个bug...超了再扣钱...

呃，都有奖有罚就好了。
开发人员的bug在一定范围内不扣，UAT阶段bug低于一个比例有奖。
测试人员SIT阶段发现bug有奖，UAT后出bug超过一定数量的扣钱。

不能光想着不花钱，整个团队做得好是要总和起来有奖拿的。
大家可以都拿奖，如果能做到发现的bug一直够少。
也可能大家都受罚，如果发现的bug很多而且UAT阶段bug也很多。
要是公司不这么认为，作为项目经理至少要尽量争取。

PS,主要是具体数量范围这玩意不好定。
PS2,我觉得用规划人天的bug数比行数好点。当然这也是拍脑袋。

11 楼 Ben.Sin 2010-06-12  

测试人员不懂细节，项目负责人或者熟悉的成员要讲解，就像给开发人员讲解需求一样

10 楼 hotjava 2010-06-12  

我的团队中测试人员就负责提交测试文档，糊弄一下局方，起不到多大作用。

你想让一个测试人员熟悉公司的全部产品的全部细节，怎么可能。
测试还是要靠自己把关。程序更到测试域以后所有开发人员都测一边， 上生产以后有条件的再测一边。

时间允许的条件下能测多细就测多细。不过就这样还是每次更包都心惊胆战。

9 楼 Angel_Night 2010-06-12  

奖罚必然要有..不然你就需要靠领袖魅力了

关键在于度吧
比如说 每千行允许出现多少个bug...超了再扣钱...

8 楼 chandler 2010-06-12  

   你都开始怀疑员工的职业操守了。你应该找你自己的责任。你的人是否那么不值得信赖。如果就是你的问题了。
   天底下没有完美的制度，制度永远是个摆设。再好的制度，如果人的水平达不到，早晚千疮百孔。这个人包括管理者。

7 楼 former 2010-06-12  

<p>楼主说的测试，是做手工集成、验收测试的吧？</p>
<p>我们这么做的：</p>
<ol>
<li>测试和开发同在项目组。</li>
<li>开发人员面向需求做设计，开发人员根据需求做设计，并交由项目组评审。</li>
<li>测试根据需求设计测试用例，这个工作与开发同时进行，并交由项目组评审，之后做执行。</li>
</ol>
<p>简而言之，放在一起，互评互测。</p>

6 楼 zhangzhenting 2010-06-12  

测试和研发应在一个项目组，项目上线，共同分享项目奖金，不涉及到奖和扣的问题。
测试用例可以由开发组组长以及测试人员（前方，与客户沟通的人员）共同讨论编写，也可以交由一方编写并经过对方审核。当需求出现变动时测试人员也需要及时的与研发组进行沟通，提高研发的质量与效率。

5 楼 nothink 2010-06-12  

很好，测试的就奖，开发的就扣。不出一个月。程序光光。项目也光光。game over

4 楼 lishimin95 2010-06-11  

测试用例，每个功能、条件可能出现的情况都应在测试用例中体现。个人认为：测试用例应由业务经验丰富的开发人员或测试人员来编写。这样测试可以更好地检验程序。

3 楼 抛出异常的爱 2010-06-11  

测试是在没有测试之前写测试计划的.

测试计划写完了,正确,错误的数量就固定了.(及使代码还没有开发完成)

测试计划是以覆盖率为标准的....覆盖大于75%分支才算合格.