我们公司有不少女性测试人员，几乎要占了 50% 了。
他们的特点是稳定性强（开发人员走了一批又一批，她们还在），相反技术能力可能并不特别好，但有好几个是业务专家，对业务特别熟悉（由于我们是面向企业的产品，业务逻辑特别复杂），比开发人员还熟悉，很多开发都会来请教测试某些模块应该怎么改...
所以对于女性测试人员来说，找家大公司，熬的久，就够了，尤其是拖家带口的。

好问题，来小道消息吧

个人觉得你要不是大公司背景工作经验丰富 or 技术大牛水平足够哦日一直得不到职位上的提升（特别是管理层的），不要轻易去创业公司（期权这东西能变现才有意义），风险还是比较大的。
对于新人，如果创业公司由大牛指导，自然也可以去跟着学习。但是这种不多吧，这年头大牛也是奔着 BAT 去的多啊。

我认为把 “测试任务” 和 “测试技术” 分开理解讨论就好了，本身测试技术就是要讨论解决测试效率和持续有效运作的流程和框架。

每个测试团队扛的是 “测试任务”：测试验证覆盖率，bug 产出，用户反馈 bug 回溯跟踪。

而服务于测试效率的是 “测试技术”：自动化 UI 功能验证相关框架，专项压力脚本方案，手工辅助性测试工具，服务测试流程的框架模板等。

统筹人员和任务流程的是 “测试管理”：协调各测试任务的人员配比，对接配合部门接口需求，控制用例覆盖程度，管理追述 bug 状态，推进集成 “测试技术” 提高效率，推进人员培训提高测试人员能力等。

我认为综合在一起才是 “测试团队”。每个部分都可以单独提出来讨论，如” 测试技术 “。至于是否适用就得放到 “测试团队” 中去考量。

#2 楼 @seveniruby 我离开上个东家就因为这个原因。所有人为 kpi 工作。搞了一年自动化。生产各种框架平台。结果连个持续集成都没有。测试环境里没有一条能重复执行的脚本

时间、质量、成本都是要考虑的 ，古老的事企业单位就是没有测试、UI、产品之类的，因为一个小项目周期都可以是一年或两年，延期也不会有任何影响，不影响工资 、绩效。 在这种环境下确实开发什么都搞定了。
但是在互联网这个环境下，开发敢说自己是全面手嘛？一般周期就是 2 周，需要多少开发才能保证如期完成，沟通成本会有多大？和测试配合不了，难道开发和开发配合就真的默契嘛......

估计是本来开发和测试关系不怎么好吧，要是出了问题让同时找开发和测试，让他们共同承担责任，那开发看到 bug 就不会那么烦了

里面的人目前水平不高不代表什么。随着项目中对技术要求的提高，水平不行的都会慢慢淘汰。
从招聘角度，既然我不愁招人，为何不直接招一个技术能力更高的？

令开发恶心的是拿鸡毛当令箭还什么都不懂再加 JJYY 的测试吧。当一个测试能看出你代码的问题给你指出来的时候，就已经比那些看见 404 就大呼小叫开发快过来结果发现多打了一个 1 的测试强多了。

最近接了好多金融公司的邀约，基本一水的 p2p 性质，待遇吹的老高，基本啥要求都满足你，不知道有没有进去过的朋友，eg:人人贷，聚爱财 .etc

代码没有 BUG 怎么会被测试恶心呢，时间充足需要建立在你的能力很强的基础上
等你到达那个层次，就不会在这里无聊吐槽了

严格意义上来说，就是因为开发水平不够，才需要测试。
假设开发水平逆天，什么问题都考虑到了，开发出的产品天衣无缝，那就根本不需要测试。

但是，有这种开发存在吗？
以前没有
以后也不可能会有

我倒是觉得现在有的开发水平太 low

福利那块说的贴贴切了。切身感受

真正会学习的人或者技术好的人，是不屑于加群的

都是 PM 惹的祸

你已经开启了走火入魔模式

说明搞测试的人太多了。

认为测试 low 的思想已经无可救药了。

因为在别人眼里，测试就是 low, 所以要说写别人不懂，或者看似高大上的东西。

其实记事本就可以写代码，用什么 IDE

特别讨厌说不上。。。因为做了太长时间的测试，可以理解测试的想法。但是有的时候确实很烦。。。
我最近才真正明白，测试和开发完全不对立等于痴人说梦。。。

这得要多少年的代码经验才说得出这种话
另外感觉需要介绍一下敏捷开发的定义。。

这个就和比较音响有些类似，你说这个音响怎么好怎么好应用了什么技术，听起来感觉如何如何，都是比较软性的，不懂行的人也听不懂。直接说音响 A 卖 1000 块，音响 B 卖 2000 块，啊！果然 B 比 A 好。不懂行的没法判断，缺乏安全感（对判断不懂的事物），想依赖那些能看得见的东西（2000 块>1000 块）。

开发兼测试是可行的，不过实施上有个天然的缺点。开发检查出来 bug，直接增加了任务。那么有意无意，很可能会忽略一些 bug。