开发 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、报名明确写出质量风险 & 没覆盖到的点 ，避免背锅 。
可怕
IDO老徐
回复
写得好全，测试时间被压缩，都可以用这招了。
其实这种测试时间被压缩的，质量风险大，整个团队都知道。更多是业务确实非常需要，没有这个都无法开展业务，质量风险大也得顶着先上产生价值。这个时候一般就冒烟通过、未覆盖的点列出来且大家觉得可接受，就直接上了。
这项目排期就存在很大问题啊，83 天开发出 1 个版本？ 我觉得最好拆开几个版本每两周交付 1 版，边开发边测试迭代才是正路
陈恒捷
回复
是的，企业实际过程中，很多这种情况（业务明天就要，传统的全覆盖是不可能的）； 但，作为测试，得把风险写出来（虽然大家都知道这事），避免最后出问题，说测试没测 ；
1.先把排期的揍一顿，如果打不过，再看后面的
2.和开发商量，把任务拆分下，开发时也提测已经开发好的模块 or 功能，总不可能 83 天测试玩着吧。。。开发的时候，可以用实例化需求、分层自动化测试等手段同步进行测试，提前写好的测试没跑过不能提测
3.设置准出标准。5 天测完，报告写清楚覆盖了哪些，如果还有 BUG 没修复或者回归完，也写清楚，质量不达标，原则上不准出。如果非要上线，呐，是他让我打的哦，从没见过这种要求~~
我想一般他这 83 天都是包含同步测试的时间的，如果不包含，这是在为难你胖虎，找项目失败的背锅侠吧。
IDO老徐
回复
解决问题的思路有两方面：
1、解决这个问题本身——对于已经发生的事情，老徐这个套路绝对是老司机必须知道的，无论团队氛围多好，都应该这么做
2、解决根源——这都啥年代了还能瀑布成这个鬼样子也是少见，就算不用敏捷，那小迭代分批次测试、验证都是必不可少的，等到交付 deadline 了才给测试去测，一方面项目经理该死，但是测试团队自己屁股也绝对没坐正——不管你在开发 coding 的时候多忙，但是在老板看来：你划水 83 天才来跟我说只有 5 天不能保证质量？我是老板我也怒
难道你们天天跟我吹的测试左移只是参加一下需求确认？
其实也还好吧 如果前期测试把该投入的投入到位，当开发提测达到标准以后， 3 人五天我觉得肯定是可以测完功能的呀，如果 Bug 太多，开发改不完，那就不是测试的锅了，不过如果该产品还需要测试性能和稳定性的话，那这个时间的确有点紧
其实这个问题的破局方式，我觉得你们都忽略了一个弯道超车的机会，就是 83 天开发，这意味着什么，还可以混 2 个月（60 天，从头开始学一门技术都可以学完了），然后半个月找工作，然后走人，岂不是，然后 10 天交接，直接走人，这样子，在压力下学习，事半功倍，然后又学会了一门技术，然后 2 个月的带薪学习混到手，然后走人~岂不是，美滋滋~~在下愚见不过还是要说，以上的方式基于流氓的方式，对方不给活路，同样，不给活路搞回去~~
如果自测质量达标，并且各种前移、演示都 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 个都找不出来，然后很多模块实际没测到就上线了，然后背锅
这业务放到银行至少做半年！
1、使劲测，能提多少 bug 提多少，我就不信开发能改完，领导说能上线就行；
2、颠，完全不重视测试，待着有何意义，在他们思想中这五天都是多余的。
开发时间： 开发 9 人 83 天，测试 3 人 5 天
测试时间： 5 天，测试 3 人 + 产品设计 x 人 + 开发 9 人测试
质量： 主流程 OK，不关注 UI（UI 产品和设计测）
完美解决
这种如果在我公司出现，我直接叼死这群 PM、Dev，你行你上。
1.开发 83 天是怎么算出来的？是否可以分批次提测？如果可以，那测试时间其实也就不是最后 5 天。而是 83+5-第一次提测时间。
2.功能之间的依赖性确定清楚。先做那个后做哪个。大功能先做，小优化后做。如果全局意识好的话，可以减少很多不必要的测试时间。
3.其次就是测试人员之间的配合问题，谁都有自己擅长的部分。
4.测试用例怎么写也是一个学问，一套有说服力的用例，是可以为自己争取到测试时间的。
这是我自己亲身经历的例子。任何事（面子）都是靠自己挣出来的。