问答 开发 9 人 83 天,测试 3 人 5 天,各位对此有何看法

studyUp · 2020年04月03日 · 最后由 chen 回复于 2020年05月07日 · 3842 次阅读

开发 9 人 83 天,测试 3 人 5 天

新系统,6,7 个服务,新产品。
还涉及到资金问题,出 bug 就是 P1 级的。

强制的,直接拍死了。我们能有啥办法= =

共收到 33 条回复 时间 点赞

有没有走人的觉悟?如果觉得没可能保证质量,就拿出数据来证明这个任务完成不了,谁完成得了让谁来。反正自己不要扛这个雷,大不了领 n+1,不要主动辞职

让开发自己测

这尼玛叼炸啦!

哈哈哈,提上 200 个 bug,让开发慢慢修

基本的不就是一比一么

这谁顶得住

哈哈,可怕的比例!

要不,请个 3 天假?不行的话,上线不批单子呗

测试结果如实写,不慌

开发 4 人 10 测试 1 人 20 天 新系统人脸服务 ,色值差都是 p 级 bug。开发先自测,ok 才提测,

还是第一次遇见这样的公司

83 天的任务他们怎么排的下来的?没有 BETA 版本?
如果真是这样,那真是牛逼了。
别虚,1 周 1000 多个 BUG 都见过,也没见把谁干掉。

1、开发自测,没达到准入标准,不准入;
2、客观提出所有 Bug 再说,至于是否改完 ...
3、报名明确写出质量风险 & 没覆盖到的点 ,避免背锅 。

IDO老徐 回复

写得好全,测试时间被压缩,都可以用这招了。

其实这种测试时间被压缩的,质量风险大,整个团队都知道。更多是业务确实非常需要,没有这个都无法开展业务,质量风险大也得顶着先上产生价值。这个时候一般就冒烟通过、未覆盖的点列出来且大家觉得可接受,就直接上了。

这项目排期就存在很大问题啊,83 天开发出 1 个版本? 我觉得最好拆开几个版本每两周交付 1 版,边开发边测试迭代才是正路

陈恒捷 回复

是的,企业实际过程中,很多这种情况(业务明天就要,传统的全覆盖是不可能的); 但,作为测试,得把风险写出来(虽然大家都知道这事),避免最后出问题,说测试没测 ;

1.先把排期的揍一顿,如果打不过,再看后面的
2.和开发商量,把任务拆分下,开发时也提测已经开发好的模块 or 功能,总不可能 83 天测试玩着吧。。。开发的时候,可以用实例化需求、分层自动化测试等手段同步进行测试,提前写好的测试没跑过不能提测
3.设置准出标准。5 天测完,报告写清楚覆盖了哪些,如果还有 BUG 没修复或者回归完,也写清楚,质量不达标,原则上不准出。如果非要上线,呐,是他让我打的哦,从没见过这种要求~~

我想一般他这 83 天都是包含同步测试的时间的,如果不包含,这是在为难你胖虎,找项目失败的背锅侠吧。

IDO老徐 回复

解决问题的思路有两方面:
1、解决这个问题本身——对于已经发生的事情,老徐这个套路绝对是老司机必须知道的,无论团队氛围多好,都应该这么做
2、解决根源——这都啥年代了还能瀑布成这个鬼样子也是少见,就算不用敏捷,那小迭代分批次测试、验证都是必不可少的,等到交付 deadline 了才给测试去测,一方面项目经理该死,但是测试团队自己屁股也绝对没坐正——不管你在开发 coding 的时候多忙,但是在老板看来:你划水 83 天才来跟我说只有 5 天不能保证质量?我是老板我也怒😎 难道你们天天跟我吹的测试左移只是参加一下需求确认?

其实也还好吧 如果前期测试把该投入的投入到位,当开发提测达到标准以后, 3 人五天我觉得肯定是可以测完功能的呀,如果 Bug 太多,开发改不完,那就不是测试的锅了,不过如果该产品还需要测试性能和稳定性的话,那这个时间的确有点紧

如果自测质量达标,并且各种前移、演示都 OK,我觉得测试不需要独占周期也挺不错的呀

hyeebeen 回复

边开发边测,我唯一的一个感受就是,提了 bug,开发直接说没时间,去开发新功能去了。所以测试不独占周期是不现实的。开发只有把功能都先开发完成才能对上面交差,修复 bug 是要放在后面的。

太真实了……我司也是,本来测试时间就给得很不合理了,开发还经常占用测试时间……我给开发说 开发:测试时间应该 1:1,他们觉得我疯了,说我开发个功能好几天,你也要测好几天?几十秒就够了……你们说咋办……无语……

槽神 回复

测试左移(产品设计时提改进、开发技术设计时提意见、开发阶段 review 代码) 对于 99.9999999% 的测试来说 行吗?

MichaleScold 回复

左移就一定要移的这么高端吗,提前介入测试还是很简单的吧,就算没有集成环境也有开发本机环境,没有条件测试都可以争取、创造的,一定要等着别人 “按流程规范” 提交给你测试了,那还有什么理由搁这郁闷呢,因为你没努力呀。

再者说了,在 老板们 看来,产品设计时提改进、开发技术设计时提意见、开发阶段 review 代码这些活也 “很简单” 呀,月薪 5 毛钱请来的的测试就应该能做这些,毕竟不是月薪 1 毛钱雇的,啥?外面给月薪 20000?你要知道人家月薪 20000 是可以造火箭的,balabala……😂

所以你到底是要解决自己的困境还是拿理想中的假如来跟自己较劲,看自己选择咯。当然最简单直接的办法就是撒丫子闪人,去一个更好的地方——开发 120 天,测试 3 天~

开发 9 人 83 天,你就 3 人 5 天,我都怀疑你能不能找出 999 个 bug,可能 100 个都找不出来,然后很多模块实际没测到就上线了,然后背锅

王加 回复

这种我一般自己把 BUG 改了。。。谁还不会开发似的,惯他们

这业务放到银行至少做半年!

1、使劲测,能提多少 bug 提多少,我就不信开发能改完,领导说能上线就行;
2、颠,完全不重视测试,待着有何意义,在他们思想中这五天都是多余的。

开发时间: 开发 9 人 83 天,测试 3 人 5 天
测试时间: 5 天,测试 3 人 + 产品设计 x 人 + 开发 9 人测试
质量: 主流程 OK,不关注 UI(UI 产品和设计测)
完美解决

这种如果在我公司出现,我直接叼死这群 PM、Dev,你行你上。

1.开发 83 天是怎么算出来的?是否可以分批次提测?如果可以,那测试时间其实也就不是最后 5 天。而是 83+5-第一次提测时间。
2.功能之间的依赖性确定清楚。先做那个后做哪个。大功能先做,小优化后做。如果全局意识好的话,可以减少很多不必要的测试时间。
3.其次就是测试人员之间的配合问题,谁都有自己擅长的部分。
4.测试用例怎么写也是一个学问,一套有说服力的用例,是可以为自己争取到测试时间的。
这是我自己亲身经历的例子。任何事(面子)都是靠自己挣出来的。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册