有的缺陷管理系统强制要求填写备注，怎么办？这种小伎俩哪能难住我这种资深开发工程师？只需要填写“已解决”三个字就可以了。什么，担心被测试投诉？我们这么多开发，大家都这样做，他们能投诉得过来？“法不责众”你了解吗？
— 5 —
测试人员
外因是变化的条件，内因才是变化的依据。要想迅速有效地搞垮测试团队，测试自身必须重点发力、加快进程。
12、测试就是开发的跟班
测试就是开发的跟班小弟，是负责给开发“打下手”的。具体案例包括：
- 开发让我测啥我就测啥、让我怎么测我就怎么测、让我测哪个版本我就测哪个版本；
- 性能优化同步给开发做验证，开发改一点、测试验一下，开发再改一点、测试再验一下……“结对编程”效率高；
- 刷机、抓包、导日志、跑数据，测试要像保姆一样贴心，全方位服务开发团队。
你问为啥刷机这样的事情不写个操作说明给开发？开发说了：这类事情，测试来做更专业（内心想法：我怎么会做这么low的事）！
13、测试不需要了解实现
测试是代表用户发声的，要完全站在用户角度验证需求。更何况我们做的是黑盒测试，什么是黑盒？就是不管技术实现原理，只看输入输出就行！
产品需求是定义“做什么”，开发实现是定义“怎么做”，测试要验证的应该是“做什么”、有没有做对。开发的实现逻辑，很容易把测试的思路带偏，甚至把测试带到坑里去。测试同学一定要看需求，不要看实现。
14、流程规范并不重要
流程规范虽然有些作用，但是并不那么重要。有的测试部门制定那么多的流程规范：缺陷提交规范、缺陷定级规范、测试用例设计/评审/执行规范……请问会有几个人认真看呢？
我也算是“老测试”了，随手就能列出一堆流程规范的常见问题：
- 拍脑袋定义，不符合实际情况；
- 描述太空泛，不具备可操作性；
- 不够全面，实际经常遇到未定义的情况；
- 更新不及时，没有随着业务变化而修改；
- 多个流程规范“打架”，自相矛盾，让人无所适从
- 细节太多，看了根本记不住……
流程规范有这么多问题，足以证明弊大于利。
15、自动化测试是核心能力
不要相信“测试设计能力才是测试的核心能力”这种话。你看看身边技术水平高、职位高、薪资高的，不都是自动化测试达人吗？只有代码能力强，你才能站在测试金字塔的塔尖上去。
开发工程师转岗做测试，人家立即就是资深的测试工程师，毕竟人家自动化能力杠杠的。
16、不需要读书学习
专家说过：“工程师的经验70%来自工作实践，20%来自同事经验传递。”这两项加起来就是90%！我们来算算这笔账，为了那10%的经验，点灯熬夜地去读书学习，是不是得不偿失？
更何况，大多数人都是读书时激动、读书后感动、读完后不动。读完了也记不住，用的时候还不如搜索引擎来得快（别看广告看功效）。有读书那工夫，刷刷短视频放松一下，劳逸结合，它不香吗？
— 6 —
组织文化
17、加班越多越好
这团队啊，必须要忙起来才行。人一闲下来，就会胡思乱想，搞小动作。刚听说兄弟团队最近两个月比较闲，结果离职了好多人，有一位报了算法学习班在工作期间刷题练手的，还有一位考了教师资格证准备转行的。
咱们团队要吸取教训，虽然我们没有加班文化，但务必要保证每个人的工作饱和度，每天时间排期要精确到小时。加班强度要作为考核和评优的参考依据，任务排期要把晚上和周六也排上。不多给团队一点压力，怎么能激发大家的潜力？
— 7 —
组织战略
18、去测试化
测试并不直接生产企业的产品，因此常被看做成本中心。你看几年前微软CEO的去测试化不是很成功吗？裁减大量测试人员同时保证了质量，不信的话可以某度搜索“win10 bug”看看。
实际上很多时候，用户根本不需要那么高的质量，公司花钱养这么多测试人员是不是浪费？去测试化还是要搞起来的。只不过，“去测试”不等于“没测试”，测试活动仍然存在，只不过从测试扔给开发了。各位开发兄弟们，测试的锅已经被砸，你们好自为之，做好自己背锅的准备吧。
源自公众号 测试启示录