匿名吐槽 敏捷开发，开发测试比 6:1,测试来不及做测试时，产品经理为什么只是催而不能自己帮助测试，同样开发也不能加入测试呢？
敏捷实践中测试环节拖慢整个发布周期
假设一个不变的条件：测试不加人，目前测试开发比例：6:1
流程如下：
- 开发开发功能，没有单元测试，自测也很少，需求做着做着就忘了做完什么了，反正到了他们说的时间就给测试测
- 测试测试，提 bug<->改 bug
- 测试通过，如果能赶上发布时间就发布上线，没有什么分支概念，也不会从分支合代码到主干之后再测试
现在的问题： 测试的工作池里面随着时间的推移堆积的内容越来越多，看起来就成为测试是瓶颈的问题了.
我个人想吐槽的是这样子搞，测试总是瓶颈的。敏捷不是提倡一组人相互帮助为了交付吗，如果交付是最高的优先级，为什么还有那么多产品经理
开发都说测试快点，催呀催的，就是不动手帮测试呢，一起需要发布的内容都测掉呢？
敏捷都是吹的，实际还不是各干各的。测试无法保证质量，开发要交付的东西也不是给测试是给客户用的。质量是一组人的事情，或许我可能太天真了。
伪敏捷而已
你这个并不是敏捷啊。。。
睡前小故事
long long ago,
有个小团队，开始说要搞敏捷，
最早的敏捷项目，产品也没那么混乱，业务没那么复杂。
迭代周期虽然短，但是靠着开发负责人的态度，产品勉强执行的流程，测试努力的跟进，也能在迭代期内好好出东西。
两三个迭代中会穿插着一个优化/修 BUG 的小迭代。
但公司发展越来越开，运营的需求应接不暇。
业务复杂了，对技术实现的深度也有了要求了，开发哥哥们来来去去换了不知道几波人。
但 “敏捷” 的周期还是那么短，喊着敏捷，敏捷中重要的流程也丢失了。
开发也忙于业务了，产品为了运营的营收需求也失去了原则了。
慢慢得发现每次发版本总是有小 BUG，有小范围的 crash。
两三次迭代中会穿插着一个紧急上线修复在线 Crash 的小迭代。
每次产品和开发都来怪测试，测试委屈得很咧。
retrospective meeting 也变成了批斗大会，永远没有深刻的反省。
好像团队中只有测试关注质量，但这并没什么卵用，需求评审、技术评审不再有用，因为发版时间已经是产品和运营之间定了。
最后，这个团队还是能做出东西，能得到嘉奖。
但是开发和测试身心疲惫...越陷越深...
对，说的就是你们团队..对，就是看这段文字的你们团队...【地图炮勿在意】
当开发和产品抱团不对产品的质量去负责考虑的时候，测试是无力的。
还是老话啊，质量是开发出来的...
#4 楼 @anonymous 才发了段子去洗澡，要命哦，现在去加班你来陪我战斗到天亮嘛~~~~
你见过 10:1 的么？你见过 10:1 还要写自动化的么？你见过 10:1 测试还要做单元测试的么？
等你见过你就明白了，也就那么回事。
开发觉得质量要改需要自测才行，开发不改不自测，指望测试就是个很扯淡的事情。
PS：转型做开发呗，既然这比例明显重开发轻测试，与其受气不如自己写代码，谁写的出问题自己背锅去。~
让别人帮你是不可能的，有排期吗，就催？ 排期的时候要不你老大顶住，要不你顶住，顶不住就别干了，这样就算测完了也不会是好产品，最后的黑锅还得给你背。
测不完就把难题说出来，不可能一切都是测试来背锅。开发如果经常犯低级错误，可以先沟通让他们自检，再不改，就直接捅到顶级上司那去。 该做的事情，做好；做不完，那就坦然说我已经尽力了。 如果整个团队都不自省和改进，那就闪人呗。
没有单元自测持续集成的敏捷那就是逗比。。并且这个团队我不建议久待，因为你们的开发实在是 Low 的不行，对于这样的团队直接问题全暴露出来，我不信你们 CTO 只找你的事
接上，另外就你一个测试，你有每周组织团队成员进行一次 test session 么？ 时间不长 20min 就行，你有给他们准备一些 unit test 的例子么？你有去做一些主功能的快速回归自动化么？如果都没有，你自己也是不到位 ，开发不愿意测试你连改变他们的意愿都没有。
没有自动化的敏捷都是假敏捷. 谁在最后环节就坑谁.
敏捷只是一种工作流程和沟通方式, 不解决实际质量问题.
想提升质量就得好好把关, 推动研发走单测. 自己做接口测试, 然后把用例描述清楚, 分摊出去.
- 我觉得工作看三个方面： 前途，钱途和开心。 自己衡量下，如果都没有就闪人。
- 大家都忙成狗，如果你是开发，你会帮助去测试么? 如果帮助了，自己测试的模块出问题了，谁的责任，人其实是自私的动物，只能在一定程度内大公无私。
- 真的不能招人了么？真的尽力和上级沟通了吗？
- 在这里吐槽其实用处不大，找老大吐槽，PM 对自己的功能不负责，开发测试比例过高，没自动化走什么敏捷。。。 朝老大吐槽，如果老大都不帮你，你还待着干嘛啊？
赞同楼上匿名的第一点，在这看你得到的是不是高于你失去的
另外 6：1 实在是太低了，除非开发都很 low，我们这是 3：1 到 4：1，还算比较正常
质量、进度在这种不能同时保证的情况下只能谈了，找 pm 谈，权衡一个大家都可接受的标准~
敏捷项目里人人都要为质量负责，而不单单是测试。我觉得很多项目组里人员眼中的敏捷就是快速开发，快速测试，快速上线。大家只知道各干完各的事就完了，还知道产品的质量由测试负责。而没有意识到敏捷中的质量是由项目全员负责。曾经见过一个项目质量出现一个问题导致重大亏损，整个项目组全部被干掉。此时 Boss 才不管你项目是谁开发，是谁测试，只知道项目组的失误导致我口袋里的钱变少了。只有出现重大亏损时，你们的经理什么的才会意识到全员都要为项目负责。不出现重大亏损，那我只能呵呵了。
传说中没有单元测试的敏捷基本都是失败的。浪费大家时间，该多久时间还是多久。自欺欺人
敏捷也是需要规范的 可以在几个关键节点制定流程卡下 比如冒烟测试环节，只有开发把冒烟用例都 PASS 通了，再介入测试 另外，测试人员缺少这个，要测试主动把项目中其他成员调动起来，比如 PD、交互、使用方等角色。
要自动化起来才能敏捷哦
作为一名测试人员，还是要有项目管理的意识的。除了测试，还有流程规范也要关注，并且能推动团队问题的解决。
测试，首先测试团队及流程规范，其次才是测试软件产品。