为了快速实现需求 快速上线 都敏捷化了 把很多传统的步骤都省掉了
现在就是要效率 接口 ui 等等 就是为了能跟上节奏
又快又好 只能说是追求的目标
另外，测试的上限本来就不高，选择了这个职业就要接收这个现实
技术是一方面 业务上也要精通 尽量在组织内体现出自己的价值就好了
但是技术一般有通性 业务在不同的行业和组织差别很大 更多的还是要沉淀自己理解需求、快速解决问题的能力

流程跟不上研发节奏，标准化不接团队地气，没有形成团队共识。

这是流程化、标准化的工具的通病，很多流程化、标准化的工具，慢慢的被变化的团队结构和研发流程所遗弃或者选择性使用了。

流程化壁垒太高，你要打通各个部门 各个环节。但是收益是绝对有的，那么多搞 DevOps，以及现在有些搞 ServerLess 的都涉及到研发流程相关的改造。这事情需要有大领导的支持。

业务理解也很重要的,招来一个新人,从小白到业务大拿也得好久,但是现在情况就是,好多人感觉做业务不利于后续跳槽,所以都倾向于做技术去了,有点偏离了测试的本意

没办法，现在测试的业务能力在面试的时候很难看出深浅，所以就。。。

我的理解：

1、流程化和标准化其实都很重要，也有不少 devops 的文章有提及先标准化，后工具化这样的顺序。但实际做起来，成本高、见效慢、不可控因素太多，要真的做好需要天时地利人和，特别是上级领导的协助。而且很多时候测试团队在研发团队地位并不算高，自己的活都没能做的非常出彩，这时候去推动外面改变基本是不大可能的。所以做得好的相对少，做得好且大家看得到的更少而已。

2、流程化，标准化的工具却渐渐式微，我觉得只是这方面工具不再是由测试来做而已吧？tapd、jira、云效、teambition、乃至禅道，都挺多团队用的呀。只是这方面的理念这几年好像也没什么大变化，所以这些工具不管新老，用起来觉得合适就继续用下去了。

3、不用标准化的流程，不用测试计划、测试报告 这个，我待过的一些互联网公司，测试计划和测试报告确实有时候会省略，但只是不记录为正式文档或邮件，过程中还是要有计划（或者叫测试排期，确定测试内容，根据资源给出预计测试时间）和报告（或者叫测试结论，先说是否通过，然后说风险）的。至于标准化的流程，不知道楼主所说的标准化流程是怎样的？

说实话，我做测试 5、6 年了，目前在公司内部是专家级别，但是确实觉得自己才刚开始入门。做好太难了😂。

真心不觉得测试瓶颈低，而是自我要求低，且做出来的成果低

大佬，能详细说说吗

昨天和一同事说 C++ 又有啥门槛。。。
有门槛的职位本来就少，接受自己的平庸，然后再去做挑战自己平庸的事情。
标准化在大型项目中存在大量协作时才有意义，可能超过 200 人以上的团队才有意义，问题是现在有多少真正的大型项目？
流程本身就压制自由，现在公司和个人都缺乏安全感，1 年半年换个人，流程不麻烦？

有几点思考
1、质量重要，但是没有想的那么重要，只要不是致命的，让公司无法开展业务，存在些 bug 老板们是不愿意投入过多资源去完善质量的，而且这里面也有个投资收益的边际效应；
2、技术不够，流程来凑。如果不能很好的解决某类问题，那就增加一类流程。实际上流程也是成本，过分强调流程，新的参与者会融入，想创新怎么破局都是问题。流程是应该有的，怎么恰到好处，难。
3、市场的竞争速度、质量，速度有时候比质量更重要，大多数时候速度才是第一位的。只要车能跑，刹车没有问题，车身出点其他什么问题，都可以慢慢修。
4、楼主的场景如果真的是标准化、流程化的产品特征，那就可以走标准化、流程化。
5、关于瓶颈。不只是测试，研发产品的瓶颈都很低。因为它都是一个群体，这个群体叫工人阶级。大多数人到瓶颈就到了，突破者少之又少，我们应该减少成为高阶打工者的想法，就像股市，80% 亏钱才是主流。只有社会分配制度改善了，相对公平了，大家才不会像现在这么焦虑，显然目前是不现实的。

接收现实吧，入行测试就要有这个觉悟

我现在也是遇见了这样的瓶颈，在手工测试中无法在提升自己，然后对工具的使用也算是个半吊子。

深有同感，业务在熟练，跳槽的时候用的还是不大，主要还是问那些技术相关，而且一跳槽，原先熟悉的业务可能为今后的工作作用不大。

大佬说的有道理

质量没问题，如何描述是因为我厉害？

在保证质量不变的情况下，把效率提升，就很厉害了

敢问是如何一步步进阶成专家的呢

老图，一直适用，这社区里我都发了好几回了
楼主显然处于绝望之谷……不要着急，快了快了

有些朋友可能误解了。

我本身从业很长时间了。大部分工具我都开发过，不存在要求低。本文讨论都也不单单是个例都问题，没必要无限拔高。讨论都是普适性的问题，就是大部分人的问题，即不只是我自己的疑虑。

为何有此一问，主要是在做 Devops 的工具，我负责测试管理的工具，在实际的调研跟过程中发现很多的一线团队不管基于什么原因，都在有意无意的忽略流程，唯工具，唯技术论。所以，我也把我跟我领导（开发出身）的一些讨论放出来。

可能标题起的有点惊悚，大家的讨论有点跑偏。我的问题。哈哈。

有意无意的忽略流程算是不错的，我跟你做差不多同样的事情吧——效率和标准化，我面临的情况是大部分开发 leader 和 PM 反对流程，总觉得工具能解决一切，并且反对在工具里面加上流程、规则的控制点。

我觉得这种时候就没必要指望至下而上的达成共识了，自顶向下的流程强推反而会更有效！

好奇想了解下，一线团队忽略流程，忽略的是什么流程，他们反馈的是什么原因？

我们以前推一些流程，比较有效的做法是问题驱动。比如多次开发不经过测试评估直接上线出问题，就上线流程上改为只有测试才有权限；开发自测经常没做好冒烟不通过，就直接改为开发演示，在测试和产品面前演示核心流程可以跑通，然后直接提测，测试也省掉冒烟（开发演示的和冒烟的内容差不多）。至于没怎么出过问题的地方，也说明团队已经磨合好没太大问题，所以推流程急迫度也不高。

我们流程推动，一般都是先有流程并开始小范围试点，这个阶段主要靠领导强推和持续反馈。跑通了且有效果，再工具提效和巩固。

流程最终落地靠的是一线的同学，自顶而下可以破局，但如果下面持续不认可，最后这个流程其实也落不下去。这个时候领导也容易觉得这个流程其实推不推关系不大（本来就没做到位，自然出不了效果），继续强推反而容易反弹，也不会再继续强推了。

门槛低

一般忽略的就是我在另外一个帖子提到的：测试计划、测试报告
你们团队的文化，可能决定了，测试可以抱怨，而团队会因此做出改进。但从我做工具的角度，还是希望一开始就能给一个一步到位或者大概齐的解决方案（流程）给到用户。这样别人才会愿意购买我们的服务。

而如果大部分用户都不希望有流程，不认可流程有价值。从做 SaaS 的角度，我考虑的是，我是不是也应该弱化产品这块的功能，顺应潮流？做其他更有价值的功能。

我们是做 SaaS 服务的。所以可能要更多考虑业内大部分的形态，以及产品的生存问题

哦哦，明白了。那你们场景和我以前的不一样。

从我的经历看，每个公司这方面的流程都不大一样，用的系统也都不大一样。经历了 4 家公司，除了 jira ，没见到两家公司用同一个流程工具的。而且虽然用 jira ，但自定义的工作流也是有不少差别的，基本都不会用自带的默认流程。

如果你们是在初创期，建议先专注做自己特色吧。测试计划、测试报告在不少互联网企业，可能一个 wiki 文档就可以满足了，没有那么强的需要。真有强需要的，也基本有自家模板，需要适配定制，对你们来说投入产出比也不高。更关键的是，如果购买方是测试团队，相比流程，需求更大的应该还是你前面提的技术、工具。流程这块一般是公司整个研发团队甚至全部工作项的管理，才会有采购需求。

不过我也只是互联网公司的经验，可能有的传统企业有这方面需求。这块还是要以你们受众的需求为准。

测试瓶颈确实很低，这是客观存在的现实，也是对于大部分测试人员而言，无论从薪资待遇还是发展机会，都会切身感受到的。这跟自我要求无关。
为了突破瓶颈，提高天花板，测试行业目前就是在尽量往开发技术上靠，尤其近几年测试门槛在逐渐提高。测试厉害的人，一般会认为他技术很厉害，而不会说他测试思维很不错，测试很细致。技术成为了测试进阶的主要渠道，所以会有那么多的工具和平台，反复造轮子也乐此不疲。
测试计划、测试报告等流程性的产品，一般就是使用禅道、Jira、Confluence、Trello 等来做，测试流程一般是依托于研发流程的，敏捷开发追求的是小步快走，相比于传统行业的项目交付物，没有那么正儿八经的规范，自然这块要求就变低了，甚至有些团队都不想写这类文档，比如 Jira 看板就是测试计划，一目了然，没有必要再去写个多余的 Excel。

了解了。谢谢～

我的看法就是面试与待遇和产出脱钩导致的自我方向与自我应用的冲突

测试计划如果来源于版本、迭代计划，按照测试、阶段类型自动创建呢？
计划中需要执行的 case 根据这个版本、迭代下的需求、任务关联的 case 自动加入，测试计划随版本、迭代计划内容的变更自动变更，这样测试报告如果是按照测试计划自动生成，到期自动发送呢？
还会有客户不愿意用吗，他们可能只是懒得花时间去操作吧，devops 工具链是要集成的，单纯的割裂测试管理的确不好用

“计划中需要执行的 case 根据这个版本、迭代下的需求、任务关联的 case 自动加入，测试计划随版本、迭代计划内容的变更自动变更” 这个其实已经在产品现在的版本实现了。奈何用户没有做计划的习惯。自动化创建，发送报告，倒是挺好的甜点功能。做上之后能不能再抢救一下。谢谢槽神

我负责的产品，恰恰就是流程化、标准化的工具，但是似乎领导并不认可，(领导认为) 垂直领域的测试工具比流程管理工具的价值更高。

我跟你们领导的前一半看法基本一致。测试团队用过别的流程化标准化产品，换成你负责的这个后，以前的某些个痛点瓶颈点还在，还会照样忽略某些个流程。
后一半呢，我不认为这些个痛点瓶颈点是靠一两个垂直领域的测试工具能解决的，但我认同这些测试工具的确不同程度地缓解了这些痛点瓶颈点。

低

内容和标题不太匹配
测试是门槛低 瓶颈高
我最开始入门 是唯技术论者 觉得技术 NB 就是王道
现在觉得技术就这些 会的都会 更 NB 钻研到极致的就那么几个大佬 大多是技术都是五五开 主流的大家都知道了 就看落地 和另外的东西 协调落地因地制宜 等等
待了不少公司
发现其实真的流程做得到好 常规手法基本验不到什么问题的 因为开发自测 覆盖率 主流功能都把握的很好了
这个时候要发现问题都是很刁钻的问题

但是大部分公司 都是流程一塌糊涂 自动化糊弄 开发自测不可能
导致测试做的都是很多无用功 还有大量冗余的沟通成本 部门壁垒 忙碌的不行 还没啥成就感

加入这样的甜点功能，恐怕依然改变不了瓶颈点对整体流程的制约，整体流程的效率取决于瓶颈点的效率。手机买票取代大厅窗口买票是甜点吧，刷身份证取代人工检票是甜点吧，铁路运输能力依然是瓶颈点。
但你仍然值得一试，说不定这样的甜点功能会成为同类产品中的亮点呢！

#19 .从业很长时间了</>
其实从现实可行性来看，自己坐上管理位来推动流程改善是最顺其自然的 -- 自负盈亏：改善投入的成本，带来的收益完全在自己团队内消化。
不然就要像现在这样到处找论据反复论证说服上级平级同事。

哈哈。标题党嘛，为了引起大家讨论，谅解一哈。

大佬的见解很独到。

我的理解。流程管理工具更多的是为了管控进度、风险跟交付的质量。效率提升可能会是第二位，很重要，但并非核心要素。

瓶颈底 和 能做好 是 2 回事，从业 10 多年，碰到的测试人员，个人觉得能胜任这份工作的不足一半