开发 9 人 83 天,测试 3 人 5 天
新系统,6,7 个服务,新产品。
还涉及到资金问题,出 bug 就是 P1 级的。
强制的,直接拍死了。我们能有啥办法= =
有没有走人的觉悟?如果觉得没可能保证质量,就拿出数据来证明这个任务完成不了,谁完成得了让谁来。反正自己不要扛这个雷,大不了领 n+1,不要主动辞职
让开发自己测
这尼玛叼炸啦!
哈哈哈,提上 200 个 bug,让开发慢慢修
基本的不就是一比一么
这谁顶得住
哈哈,可怕的比例!
要不,请个 3 天假?不行的话,上线不批单子呗
测试结果如实写,不慌
开发 4 人 10 测试 1 人 20 天 新系统人脸服务 ,色值差都是 p 级 bug。开发先自测,ok 才提测,
还是第一次遇见这样的公司
83 天的任务他们怎么排的下来的?没有 BETA 版本?
如果真是这样,那真是牛逼了。
别虚,1 周 1000 多个 BUG 都见过,也没见把谁干掉。
1、开发自测,没达到准入标准,不准入;
2、客观提出所有 Bug 再说,至于是否改完 ...
3、报名明确写出质量风险 & 没覆盖到的点 ,避免背锅 。
可怕
写得好全,测试时间被压缩,都可以用这招了。
其实这种测试时间被压缩的,质量风险大,整个团队都知道。更多是业务确实非常需要,没有这个都无法开展业务,质量风险大也得顶着先上产生价值。这个时候一般就冒烟通过、未覆盖的点列出来且大家觉得可接受,就直接上了。
这项目排期就存在很大问题啊,83 天开发出 1 个版本? 我觉得最好拆开几个版本每两周交付 1 版,边开发边测试迭代才是正路
是的,企业实际过程中,很多这种情况(业务明天就要,传统的全覆盖是不可能的); 但,作为测试,得把风险写出来(虽然大家都知道这事),避免最后出问题,说测试没测 ;
1.先把排期的揍一顿,如果打不过,再看后面的
2.和开发商量,把任务拆分下,开发时也提测已经开发好的模块 or 功能,总不可能 83 天测试玩着吧。。。开发的时候,可以用实例化需求、分层自动化测试等手段同步进行测试,提前写好的测试没跑过不能提测
3.设置准出标准。5 天测完,报告写清楚覆盖了哪些,如果还有 BUG 没修复或者回归完,也写清楚,质量不达标,原则上不准出。如果非要上线,呐,是他让我打的哦,从没见过这种要求~~
我想一般他这 83 天都是包含同步测试的时间的,如果不包含,这是在为难你胖虎,找项目失败的背锅侠吧。
解决问题的思路有两方面:
1、解决这个问题本身——对于已经发生的事情,老徐这个套路绝对是老司机必须知道的,无论团队氛围多好,都应该这么做
2、解决根源——这都啥年代了还能瀑布成这个鬼样子也是少见,就算不用敏捷,那小迭代分批次测试、验证都是必不可少的,等到交付 deadline 了才给测试去测,一方面项目经理该死,但是测试团队自己屁股也绝对没坐正——不管你在开发 coding 的时候多忙,但是在老板看来:你划水 83 天才来跟我说只有 5 天不能保证质量?我是老板我也怒 难道你们天天跟我吹的测试左移只是参加一下需求确认?
其实也还好吧 如果前期测试把该投入的投入到位,当开发提测达到标准以后, 3 人五天我觉得肯定是可以测完功能的呀,如果 Bug 太多,开发改不完,那就不是测试的锅了,不过如果该产品还需要测试性能和稳定性的话,那这个时间的确有点紧
其实这个问题的破局方式,我觉得你们都忽略了一个弯道超车的机会,就是 83 天开发,这意味着什么,还可以混 2 个月(60 天,从头开始学一门技术都可以学完了),然后半个月找工作,然后走人,岂不是,然后 10 天交接,直接走人,这样子,在压力下学习,事半功倍,然后又学会了一门技术,然后 2 个月的带薪学习混到手,然后走人~岂不是,美滋滋~~在下愚见不过还是要说,以上的方式基于流氓的方式,对方不给活路,同样,不给活路搞回去~~
如果自测质量达标,并且各种前移、演示都 OK,我觉得测试不需要独占周期也挺不错的呀
边开发边测,我唯一的一个感受就是,提了 bug,开发直接说没时间,去开发新功能去了。所以测试不独占周期是不现实的。开发只有把功能都先开发完成才能对上面交差,修复 bug 是要放在后面的。
太真实了……我司也是,本来测试时间就给得很不合理了,开发还经常占用测试时间……我给开发说 开发:测试时间应该 1:1,他们觉得我疯了,说我开发个功能好几天,你也要测好几天?几十秒就够了……你们说咋办……无语……
测试左移(产品设计时提改进、开发技术设计时提意见、开发阶段 review 代码) 对于 99.9999999% 的测试来说 行吗?
左移就一定要移的这么高端吗,提前介入测试还是很简单的吧,就算没有集成环境也有开发本机环境,没有条件测试都可以争取、创造的,一定要等着别人 “按流程规范” 提交给你测试了,那还有什么理由搁这郁闷呢,因为你没努力呀。
再者说了,在 老板们 看来,产品设计时提改进、开发技术设计时提意见、开发阶段 review 代码这些活也 “很简单” 呀,月薪 5 毛钱请来的的测试就应该能做这些,毕竟不是月薪 1 毛钱雇的,啥?外面给月薪 20000?你要知道人家月薪 20000 是可以造火箭的,balabala……
所以你到底是要解决自己的困境还是拿理想中的假如来跟自己较劲,看自己选择咯。当然最简单直接的办法就是撒丫子闪人,去一个更好的地方——开发 120 天,测试 3 天~
开发 9 人 83 天,你就 3 人 5 天,我都怀疑你能不能找出 999 个 bug,可能 100 个都找不出来,然后很多模块实际没测到就上线了,然后背锅
这业务放到银行至少做半年!
1、使劲测,能提多少 bug 提多少,我就不信开发能改完,领导说能上线就行;
2、颠,完全不重视测试,待着有何意义,在他们思想中这五天都是多余的。
开发时间: 开发 9 人 83 天,测试 3 人 5 天
测试时间: 5 天,测试 3 人 + 产品设计 x 人 + 开发 9 人测试
质量: 主流程 OK,不关注 UI(UI 产品和设计测)
完美解决
这种如果在我公司出现,我直接叼死这群 PM、Dev,你行你上。
1.开发 83 天是怎么算出来的?是否可以分批次提测?如果可以,那测试时间其实也就不是最后 5 天。而是 83+5-第一次提测时间。
2.功能之间的依赖性确定清楚。先做那个后做哪个。大功能先做,小优化后做。如果全局意识好的话,可以减少很多不必要的测试时间。
3.其次就是测试人员之间的配合问题,谁都有自己擅长的部分。
4.测试用例怎么写也是一个学问,一套有说服力的用例,是可以为自己争取到测试时间的。
这是我自己亲身经历的例子。任何事(面子)都是靠自己挣出来的。