匿名吐槽 敏捷开发,开发测试比 6:1,测试来不及做测试时,产品经理为什么只是催而不能自己帮助测试,同样开发也不能加入测试呢?

匿名 · November 24, 2015 · Last by 匿名 replied at December 09, 2019 · 2795 hits

敏捷实践中测试环节拖慢整个发布周期

假设一个不变的条件:测试不加人,目前测试开发比例:6:1
流程如下:

  • 开发开发功能,没有单元测试,自测也很少,需求做着做着就忘了做完什么了,反正到了他们说的时间就给测试测
  • 测试测试,提bug<->改bug
  • 测试通过,如果能赶上发布时间就发布上线,没有什么分支概念,也不会从分支合代码到主干之后再测试

现在的问题: 测试的工作池里面随着时间的推移堆积的内容越来越多,看起来就成为测试是瓶颈的问题了.

我个人想吐槽的是这样子搞,测试总是瓶颈的。敏捷不是提倡一组人相互帮助为了交付吗,如果交付是最高的优先级,为什么还有那么多产品经理
开发都说测试快点,催呀催的,就是不动手帮测试呢,一起需要发布的内容都测掉呢?

敏捷都是吹的,实际还不是各干各的。测试无法保证质量,开发要交付的东西也不是给测试是给客户用的。质量是一组人的事情,或许我可能太天真了。

共收到 18 条回复 时间 点赞

伪敏捷而已

你这个并不是敏捷啊。。。

睡前小故事

long long ago,
有个小团队,开始说要搞敏捷,
最早的敏捷项目,产品也没那么混乱,业务没那么复杂。
迭代周期虽然短,但是靠着开发负责人的态度,产品勉强执行的流程,测试努力的跟进,也能在迭代期内好好出东西。
两三个迭代中会穿插着一个优化/修BUG的小迭代。
但公司发展越来越开,运营的需求应接不暇。
业务复杂了,对技术实现的深度也有了要求了,开发哥哥们来来去去换了不知道几波人。
但“敏捷”的周期还是那么短,喊着敏捷,敏捷中重要的流程也丢失了。
开发也忙于业务了,产品为了运营的营收需求也失去了原则了。
慢慢得发现每次发版本总是有小BUG,有小范围的crash。
两三次迭代中会穿插着一个紧急上线修复在线Crash的小迭代。
每次产品和开发都来怪测试,测试委屈得很咧。
retrospective meeting也变成了批斗大会,永远没有深刻的反省。
好像团队中只有测试关注质量,但这并没什么卵用,需求评审、技术评审不再有用,因为发版时间已经是产品和运营之间定了。
最后,这个团队还是能做出东西,能得到嘉奖。
但是开发和测试身心疲惫...越陷越深...

对,说的就是你们团队..对,就是看这段文字的你们团队...【地图炮勿在意】
当开发和产品抱团不对产品的质量去负责考虑的时候,测试是无力的。
还是老话啊,质量是开发出来的...

#3楼 @anikikun 段子王!。话说。。你应该刚去加班才对啊

#4楼 @anonymous 才发了段子去洗澡,要命哦,现在去加班你来陪我战斗到天亮嘛~~~~

你见过10:1的么?你见过10:1还要写自动化的么?你见过10:1测试还要做单元测试的么?
等你见过你就明白了,也就那么回事。
开发觉得质量要改需要自测才行,开发不改不自测,指望测试就是个很扯淡的事情。
PS:转型做开发呗,既然这比例明显重开发轻测试,与其受气不如自己写代码,谁写的出问题自己背锅去。~

让别人帮你是不可能的,有排期吗,就催? 排期的时候要不你老大顶住,要不你顶住,顶不住就别干了,这样就算测完了也不会是好产品,最后的黑锅还得给你背。

测不完就把难题说出来,不可能一切都是测试来背锅。开发如果经常犯低级错误,可以先沟通让他们自检,再不改,就直接捅到顶级上司那去。 该做的事情,做好;做不完,那就坦然说我已经尽力了。 如果整个团队都不自省和改进,那就闪人呗。

没有单元自测持续集成的敏捷那就是逗比。。并且这个团队我不建议久待,因为你们的开发实在是Low的不行,对于这样的团队直接问题全暴露出来,我不信你们CTO只找你的事

接上,另外就你一个测试,你有每周组织团队成员进行一次test session么? 时间不长20min就行,你有给他们准备一些unit test的例子么?你有去做一些主功能的快速回归自动化么?如果都没有,你自己也是不到位 ,开发不愿意测试你连改变他们的意愿都没有。

没有自动化的敏捷都是假敏捷. 谁在最后环节就坑谁.
敏捷只是一种工作流程和沟通方式, 不解决实际质量问题.
想提升质量就得好好把关, 推动研发走单测. 自己做接口测试, 然后把用例描述清楚, 分摊出去.

  1. 我觉得工作看三个方面: 前途,钱途和开心。 自己衡量下,如果都没有就闪人。
  2. 大家都忙成狗,如果你是开发,你会帮助去测试么? 如果帮助了,自己测试的模块出问题了,谁的责任,人其实是自私的动物,只能在一定程度内大公无私。
  3. 真的不能招人了么?真的尽力和上级沟通了吗?
  4. 在这里吐槽其实用处不大,找老大吐槽,PM对自己的功能不负责,开发测试比例过高,没自动化走什么敏捷。。。 朝老大吐槽,如果老大都不帮你,你还待着干嘛啊?

赞同楼上匿名的第一点,在这看你得到的是不是高于你失去的
另外6:1实在是太低了,除非开发都很low,我们这是3:1到4:1,还算比较正常
质量、进度在这种不能同时保证的情况下只能谈了,找pm谈,权衡一个大家都可接受的标准~

敏捷项目里人人都要为质量负责,而不单单是测试。我觉得很多项目组里人员眼中的敏捷就是快速开发,快速测试,快速上线。大家只知道各干完各的事就完了,还知道产品的质量由测试负责。而没有意识到敏捷中的质量是由项目全员负责。曾经见过一个项目质量出现一个问题导致重大亏损,整个项目组全部被干掉。此时Boss才不管你项目是谁开发,是谁测试,只知道项目组的失误导致我口袋里的钱变少了。只有出现重大亏损时,你们的经理什么的才会意识到全员都要为项目负责。不出现重大亏损,那我只能呵呵了。

传说中没有单元测试的敏捷基本都是失败的。浪费大家时间,该多久时间还是多久。自欺欺人

敏捷也是需要规范的 可以在几个关键节点制定流程卡下 比如冒烟测试环节,只有开发把冒烟用例都PASS通了,再介入测试 另外,测试人员缺少这个,要测试主动把项目中其他成员调动起来,比如PD、交互、使用方等角色。

要自动化起来才能敏捷哦

作为一名测试人员,还是要有项目管理的意识的。除了测试,还有流程规范也要关注,并且能推动团队问题的解决。

测试,首先测试团队及流程规范,其次才是测试软件产品。

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up