拼命给技术部工具找各种问题，找到他们放弃

三年有这么多项目？技术已经超过大部分测试小伙伴了

不是吧，这简历是真的的话，一线可以拿 20k 了吧

有 BUG 啊，匿名的 仅数主可见，我自己都看不到

写的还算可以，深圳的话，这份简历 12k 以上

看你去面啥，我感觉非管理层的面试，一般不会面流程。更多的是面试你对业务的理解（我们普遍认为，对自己业务理解透彻的人，他肯定爱思考，爱钻研，爱学习的，这种人去哪儿都不会差。），性格（见过很厉害的测试，但性格太差，和谁都处不来）。技术的话有些公司会面，有些不会面（主要看未来用不用得上）

我看你做了很多自动化，覆盖率是多少，提升效率 37%，有没有可以量化的数据，效率提升，提升的点在哪里，还有没有优化的空间，是否实现了一套可复用的方案，如果再让你做一次，你能不能做的更好，从你的简历里面看，你做的事情谁都可以做，这件事情为什么是你来做？你做的事情和别人做的差异化在哪里？我希望看到你的沉淀和思考

无中生友

膜拜一下

看不懂

量化亏钱

只有一条

啥东西

还能咋地 自己卷起来，卷到那个技术部门受不了，你就能去这个技术部门了，你想要业务精通，你就继续钻你的业务

技术最大话事权的都这么不靠谱了，不是工资很有吸引力的话，建议赶紧跑

越来越好

稳重向好

个人观点

1. 这样做，只是为了方便管理，但是效率性，可能达不到理想状态
2. 业务部门自己开发测试工具，开发之后，会更符合业务需求，并且需求沟通，会比较顺利
3. 统一提交到技术部，可能会存在需求沟通障碍，毕竟，技术部，也不懂业务，只懂开发
4. 就好比，把家里的早餐，中餐，晚餐，全部外包出去，做成什么样，全凭外包良心，哈哈，谁也给你加了什么，谁也不知道会做什么菜色给你

模拟一时爽，实操火葬场。敢问大哥有几个底裤可赔

解不解决问题不知道，反正应该能解决一大堆制造问题的人

敏捷要依靠比较高的开发质量，不然的的确会出现这种问题！一是被测系统复杂度过高，牵一发而动全身，测试覆盖率的跟不上。第二开发质量跟不上，改一个问题，引出多个问题。敏捷要用有限的资源做到刚好的测试，那的确会存在上述的问题

说的质量问题,不只是测试的问题

产品要负责需求的质量
开发要负责提测的质量
测试要负责交付的质量

只有各司其职,每个环节都共同努力,这个迭代才是个合格的迭代

简化制度吧，看看哪些是意义不大又耗时的，可以去掉或者其他优化

这个大跨步了 这种容易出现多做多措的现象吧