如题，我们团队遇到了一些困扰，主要体现在如下方面，希望大家都建言献策，如何提升测试效率，并最大化发挥测试人员的价值。
1、开发质量差，提测的功能，冒烟测试通过率通常只有 50% 左右，此问题一直在研发团队强调，但属于那种一拳打在棉花上，说的时候大家都知道提测知道差，但就是没有多大改善。（与开发负责人也进行过多次沟通，但都没有多大本质上的改善）
2、项目界面、易用性问题比较严重，每个项目测试、开发花费在这块的时间成本，基本可以占到 20%-30%，这块如果能够做好，项目成本也可以直接下降，但也是属于那种一说都知道，但就是一直没改善的状况。
3、基于问题 1、2，测试人员每天花费太多的精力在一些基本功能、界面问题上，而没有较多的精力在测试技术提升、深度问题发掘上，长此以往，会让测试人员有种专业价值没得到体现的感觉，不利于团队的长久发展。
4、这些问题，与开发负责人、CEO 都有过沟通交流，但最后都仍然没有多大改善，有一种感觉就是，测试团队自己着急，其他人都不着急。
在此想问大家，此种情况如何破局，真正的提升研发质量、测试效率，让开发、测试都能在工作中有所收获。
看你描述了一波，大概总结一下你们团队的难处和症结。
1、整个团队乃至公司考核制度不完善（这些问题，与开发负责人、CEO 都有过沟通交流，但最后都仍然没有多大改善），同时领导想看到的是即时效益，可能是你们公司规模和老板思想直接导致；
2、开发人员测试观念薄弱，同时技术能力也一般（开发质量差，提测的功能，冒烟测试通过率通常只有 50% 左右）；
3、产品需求设计来回改，产品能力也不强（项目界面、易用性问题比较严重）
针对以上问题其实绝大多数公司都会存在这种情况，尤其是小公司表现更为突出。
提供几点意见给你参考：
1、找 CEO、开发直接 leader、HR 直接沟通考核制度定制改善，你可以提前列出关于团队配合相关的开发测试考核指标，表达自己的意见，当然考核制度并不能很直接的解决问题，可以尝试去推动完成，公司的制度就是在工作中不断完善，作为测试领导这是你能为公司做的一些分外事。
2、作为测试 leader，首先你要分析一波你自己团队成员的能力，哪些测试主导能力强的（测试驱动方面，沟通方面等）、哪些具备测开能力的，这一步很关键。
1）对于测试主导能力强的，让他多执行测试 PM 职责（涉及发布前、发布中、发布后各个节点的职责点，这个作为 leader 你那边可以具体到点列清楚，然后让测试 PM 去执行推动），可以一定程度提高成员的执行力、测试管理能力以及成就感。
2）对于具备测开能力的组员，建议前期直接接入单元测试和接口测试，配合开发完成接口方面测试。另外建议部署一套 mock 接口平台，网上有开源的，这样提前编写 mock 数据（包括正常数据和部分关键异常数据）供前端自测使用。以上两点一定程度可以提高冒烟通过率，更能提升团队技能。
综述，两个点的执行也就是我们测试人员的两个大方向，管理发展方向和技术方向
3、界面问题多：针对过往 bug 分析一下为什么界面问题很多。我大概的提几点常见的，你可以做更详细的分析（开发粗心导致、需求变动频繁导致、需求不明确导致、前端异常情况考虑不充分导致、服务端逻辑缺陷导致等等），
1）我想强调的是开发粗心导致的问题，首先你要和这位开发经常聊聊这方面问题，多发发这些数据，提供一下技能提升的意见，作为朋友的方式沟通，我想想没人不愿意去听。其次，多次沟通无效果的情况，直接和开发 leader 报数据说明开发者能力方面问题，通常情况下开发 leader 也会去找他谈，最终效果还是不明显的情况，就是找 HR 和主要领导沟通这个成员的问题。如果再大家努力下还是没效果，结果自知，为公司筛选员工，你也尽了一份力。
2）另外就是需求的影响导致，前期尽量安排需求测试，这个测试团队最好在需求出来后就去做，另外写用例的时候也去关注。把问题尽量的往前处理。当然这并不是万能的，不可能想的面面俱到。
3）关于服务端逻辑问题和前端页面部分问题，在上面我提到过接口测试和 mock 测试，都是可以提前一定程度发现并解决。
作为 leader 我们需从问题本身分析找出策略去处理这些问题，这也是 leader 应该完成和必须去做的事。
补充两点：
1、需求测试一定要做（需求评审前和测试用例编写过程发现的问题）；2、发布前的 checklist 团队成员核对，小会模式完成。
这两点很重要，很大程度避免一些不必要问题发生（环境问题、代码分支问题、数据问题等），如果还是发生落实到个人，多次发生 leader 需发起谈话。
另外以上讲的情况只是针对你所发起的问题给出的相关意见，但不一定就完全可以照搬，需要你根据团队情况逐步实现，或丰富更多手段去实现。总之作为 leader 我们不能只去反应和沟通问题，本质我们要尽量去行动改进问题，这才高层和老板希望看到的，尤其是小公司，你反馈再多基本上效果都是很低的。另外想说的就是很多情况项目是紧急的状态，是不是都必须去做，答案是肯定的，尤其是测试方，除非上面大老板拍板说不用关注质量，我们可以精简一些流程尽量在提供的时间范围内完成必要的工作，这种都会涉及到测试策略的规范等等。
希望有所帮助吧！
另外如果你都做了很多策略和行动，很长时间还是没改变，建议别在这家待着，这公司不值得，这里的同事也不值得。没灵魂！！！
看你描述了一波，大概总结一下你们团队的难处和症结。
1、整个团队乃至公司考核制度不完善（这些问题，与开发负责人、CEO 都有过沟通交流，但最后都仍然没有多大改善），同时领导想看到的是即时效益，可能是你们公司规模和老板思想直接导致；
2、开发人员测试观念薄弱，同时技术能力也一般（开发质量差，提测的功能，冒烟测试通过率通常只有 50% 左右）；
3、产品需求设计来回改，产品能力也不强（项目界面、易用性问题比较严重）
针对以上问题其实绝大多数公司都会存在这种情况，尤其是小公司表现更为突出。
提供几点意见给你参考：
1、找 CEO、开发直接 leader、HR 直接沟通考核制度定制改善，你可以提前列出关于团队配合相关的开发测试考核指标，表达自己的意见，当然考核制度并不能很直接的解决问题，可以尝试去推动完成，公司的制度就是在工作中不断完善，作为测试领导这是你能为公司做的一些分外事。
2、作为测试 leader，首先你要分析一波你自己团队成员的能力，哪些测试主导能力强的（测试驱动方面，沟通方面等）、哪些具备测开能力的，这一步很关键。
1）对于测试主导能力强的，让他多执行测试 PM 职责（涉及发布前、发布中、发布后各个节点的职责点，这个作为 leader 你那边可以具体到点列清楚，然后让测试 PM 去执行推动），可以一定程度提高成员的执行力、测试管理能力以及成就感。
2）对于具备测开能力的组员，建议前期直接接入单元测试和接口测试，配合开发完成接口方面测试。另外建议部署一套 mock 接口平台，网上有开源的，这样提前编写 mock 数据（包括正常数据和部分关键异常数据）供前端自测使用。以上两点一定程度可以提高冒烟通过率，更能提升团队技能。
综述，两个点的执行也就是我们测试人员的两个大方向，管理发展方向和技术方向
3、界面问题多：针对过往 bug 分析一下为什么界面问题很多。我大概的提几点常见的，你可以做更详细的分析（开发粗心导致、需求变动频繁导致、需求不明确导致、前端异常情况考虑不充分导致、服务端逻辑缺陷导致等等），
1）我想强调的是开发粗心导致的问题，首先你要和这位开发经常聊聊这方面问题，多发发这些数据，提供一下技能提升的意见，作为朋友的方式沟通，我想想没人不愿意去听。其次，多次沟通无效果的情况，直接和开发 leader 报数据说明开发者能力方面问题，通常情况下开发 leader 也会去找他谈，最终效果还是不明显的情况，就是找 HR 和主要领导沟通这个成员的问题。如果再大家努力下还是没效果，结果自知，为公司筛选员工，你也尽了一份力。
2）另外就是需求的影响导致，前期尽量安排需求测试，这个测试团队最好在需求出来后就去做，另外写用例的时候也去关注。把问题尽量的往前处理。当然这并不是万能的，不可能想的面面俱到。
3）关于服务端逻辑问题和前端页面部分问题，在上面我提到过接口测试和 mock 测试，都是可以提前一定程度发现并解决。
作为 leader 我们需从问题本身分析找出策略去处理这些问题，这也是 leader 应该完成和必须去做的事。
补充两点：
1、需求测试一定要做（需求评审前和测试用例编写过程发现的问题）；2、发布前的 checklist 团队成员核对，小会模式完成。
这两点很重要，很大程度避免一些不必要问题发生（环境问题、代码分支问题、数据问题等），如果还是发生落实到个人，多次发生 leader 需发起谈话。
另外以上讲的情况只是针对你所发起的问题给出的相关意见，但不一定就完全可以照搬，需要你根据团队情况逐步实现，或丰富更多手段去实现。总之作为 leader 我们不能只去反应和沟通问题，本质我们要尽量去行动改进问题，这才高层和老板希望看到的，尤其是小公司，你反馈再多基本上效果都是很低的。另外想说的就是很多情况项目是紧急的状态，是不是都必须去做，答案是肯定的，尤其是测试方，除非上面大老板拍板说不用关注质量，我们可以精简一些流程尽量在提供的时间范围内完成必要的工作，这种都会涉及到测试策略的规范等等。
希望有所帮助吧！
另外如果你都做了很多策略和行动，很长时间还是没改变，建议别在这家待着，这公司不值得，这里的同事也不值得。没灵魂！！！
这些问题还是需要数据支持的。描述中在强调：“大家都知道，大家都不做”，因为大部分情况，研发都是感官上觉得重要，身体很诚实。
所以第一个问题，针对研发质量差的建议是：
①：需测试 leader 和研发 leader 约定，冒烟不通过 90%，直接打回，直到提测通过。有些时候需要研发对质量差的有体感上的感同身受，不然大部分研发是不重视。测试需要做好 a:收集好打回的次数数据，做好数据的趋势图统计。b：测试本身技术能力，测试技能要过硬，不然无法说服研发和得到他们重视。
②：和研发沟通商量，对于【核心功能】，须经过研发小组长或者是资深研发工程师的 code review，测试建议也参与，能学到很多。
③：最核心的还是，测试把数据收集好，例如每个月打回的需求次数，占比。因为冒烟不通过导致延期的项目总数，占比。每个研发人员被打回需求的数据统计【这个还是私自发给研发 leader 为好，不要太公开】等等数据。
把这些数据，在月底的时候。如果你是测试 leader，找到研发 leader 一起过下【拉上越高级的人，越多的人越好】一起 check。多灌输一个观念：“质量出现问题，大家一荣俱荣，一损俱损的观念”。反正我每次和研发沟通，只要有机会就抛出这个观点。质量差，加班一起加，辛苦一起辛苦，还不如大家一起努力做好自己本职工作内容如何？
这个话题有点意思，我也来说说我的观点：质量不是测出来的，是设计出来的。
1.既然开发没有这个意识，测试应该参与设计（前提是你作为测试 leader 懂开发设计，你能指出来他们目前架构上、流程以及工作上还需要优化的地方），如果测试不参与设计，那么总是会在整个交付流程最后一环擦屁股，必然会遇到你提到的：开发交付质量差、反复返工问题。
2.系统易用性、体验面的问题较多，那说明开发交付的门禁规则没有定出来，和开发团队沟通，双方达成共识，某些质量不达标直接打回去重新开发。
3.前面 2 个问题如果解决，问题 3 其实不会那么容易显现出来，到时候你还会遇到新的问题，但至少可以解决测试团队目前的痛点。
4.不要总是向领导抛问题，解决方案呢？楼上的哥们已经讲的很透了，你可以试试。
额外说几句：
你这些情况我之前我当年也碰到过，当时有不懂行的领导说：你可以试试自动化测试，应该能解决你的问题。。。。。。我当时心里一万个曹尼玛。
0x7C00
回复
感谢你的建议，我们有在做数据统计与分析，并拉上开发负责人和项目经理一起看过，但数据于他们，似乎就只是数据，观念意识上的改变真的还是挺困难。很感谢你的建议，你说的这几点我好好想想，结合我们的数据统计一起搞。
正常现象，研发体系都是皇帝不急太监急，既然做了测试，就要学会淡定。
好丽友
回复
老板和各个领导都说测试很重要——这就不好办了呀，我基本都会尽量选择避开与持 “测试很重要，测试保障质量” 观点的开发团队甚至老板共事——除非我有信心能改变他们的想法
我觉得只有老板和各个领导都说 质量 很重要，而 质量是全流程的质量 的时候才有希望
既然都与大老板讨论过了，大老板也不认可测试，那只能要么改变自己（跳槽），要么大家一起浑浑噩噩下去。就好比你去追一个不爱你的女孩，要么你只能换一个女孩。要么就心甘情愿做备胎
不要去抱怨工作以及工作的合作者。想想如何帮助开发提高冒烟成功率，开发的痛点在哪？而不是不断升级 “汇报”，最后谁都不开心。
Allen.liu
回复
性能有在做，这个对着 2 个问题解决没有什么实质性的帮助，自动化前期做了一个子系统 UI 层的自动化，结果修改太频繁，搞得测试维护脚本很累，并且体现不出来价值，目前在启动接口层的自动化，效果如何还待考究。但我们目前基本是交付类的项目，项目周期都不长，花较多时间在自动化上也不是我想推行的，毕竟项目成本在那里，老板也不会愿意花太多成本来做自动化。目前想的是先把接口自动化搞起来，希望能在效率上有所提升。
先让用户重视,没有用户,你们开发的终极目标就失去动力
正常， 这个是你统计不到位，开发提测有数据吗？为什么导致呢
“3、基于问题 1、2，测试人员每天花费太多的精力在一些基本功能、界面问题上，而没有较多的精力在测试技术提升、深度问题发掘上，长此以往，会让测试人员有种专业价值没得到体现的感觉，不利于团队的长久发展。”
这个问题其实是双向的，假如一个测试，懂的比较少技术弱，然后功能界面问题很少，那么他很容易没有存在感，或者绩效沟通没有说服力。那么这样问题的关键就会转移到，有了精力之后，到底测试技术能提升多少，能给他带来多少存在感或者安全感。这个是很难体现的。
再思考一下，其实这个问题有一些误区，因为技术提升&深度问题的发掘，靠的是个人的主观能动性，靠的不是公司提供的种种便利（就算大厂背景，也得能有能力进大厂是吧），或者直白一些，安于现状的，更需要的是工作量来实现的职场安全感。
我觉得，这个问题，应该着重于工作分工的科学化，工作协作的安排，让整体的工作节奏是一直处于可控的状态。而 leader 要做的，是发现那么真正主动提升自己能力的同事，然后安排他到适合的岗位上去，帮助他的学习成长。
还有，leader 的技术不能水，尤其是在创业公司。leader 能提出这种问题，本身就必须是一个主动的提升技术的人，要不然真没说服力。
必须说服老板重视。但如何说服呢？
用数字说话，先建立度量系统。让他们知道这样错误的实践是烧公司的钱。站在对方的角度才能说服对方。
相信我，好的度量系统将是你最大，最有效的抓手。
针对第一点，目前我们的方案是提测前与开发同学确定好自测用例，提测的时候需要通过率 80% 以上（一开始先定 80%），测试同学冒烟测试发现通过率不达标打回重测
先让老板和开发老大重视。否则都很难。
老板和各个领导都说测试很重要，也在一些办公会上也都明确提过，但就是效果始终差强人意，开发团队负责人推行不到位，我们测试团队就很被动。
你们公司付 1 块钱的成本，还想找个 5 块钱的开发，怎么可能？
这哪是测试能三两句呼吁能解决的问题，这是体系级问题，即使领导呼吁可能都没用！
换句话说，这公司的测试就是在额外给开发搽屁股
bug 多，提交修稿又带出一堆，测试验证后开发继续修改，测试再验证，无止尽的陪他们玩
如果下面的人有意见，只能看看能不能多招人，平分到每一个测试身上的人物少了，大家有时间学习些其它的技术 进步
困难是客观普遍存在的，搞不定的是普通众生，很正常，能搞定的就是大佬
解题思路就是一系列自动化的手段，有没有测试提速的工具，帮助开发自测的工具等等
1.测试为何如此没有话语权？2.二中的问题是否是需求优先级最高，为何不设定一系统的规则约定？3.自动化，性能为何不研究下？再不济开发小脚步提升安装效率也可以啊。4.测试没有方向，就自己给自己定个方向，路是死的，人难道不是活的吗？
建议从小开始改善：
1、冒烟通过率很低：把冒烟测试自动化，如果冒烟不通过，直接在流程上打回去，不浪费测试时间；
2、项目界面、易用性问题比较严重：这种问题应该产品或交互背锅？或者在需求评审阶段增加工作量，避免返工导致的浪费；