对任何一个专业岗位，我们都应该保持一些敬畏，反智主义只适合开玩笑的时候，不能成为做事态度。
若干年前，我在知乎上看到一个很有趣的问题：
为什么互联网公司不开除测试，转而让大众来测，找到一个Bug给100元？
答：大家的讨论很有意思，不少都是围绕100块够不够、给不给、怎么给来说的。我的角度是，测试是产品团队里一个重要的角色（团队早期可能由产品经理来兼任这个角色），没了他们还真的不行。
默认前提是，开发已经做了单元测试和冒烟测试（原则上冒烟测试应该测试来做，但人家都被你们开除了啊，只好让开发来做了，至少要保证交给大众的是一个能跑起来的产品），这两项总不至于期望大众来帮忙做吧。
很多Bug其实并不是非黑即白，也许产品就是这么设计的。这些内部的测试知道，但外部的大众不知道，他们用起来觉得不爽，当Bug提了，这钱是给还是不给？哪怕公司内部，当测试发现此类问题（比如为了安全考虑，第二次输入密码的确认框不允许复制粘贴），开发说这是一个需求/特性，还得再把产品经理叫过来一起讨论，外部可做不到。
专业的测试需要测试用例（Test Case），但常见的测试用例（临界值相关、内存会不会泄露、特殊字符等……专业测试人员玩起来一套一套的，分分钟把开发认为没问题的程序挂掉）在大众那里可做不到，更不要说TC评审了。或者说，大众永远是知其然不知其所以然，所以只能做黑盒测试，没有办法做白盒测试。
专业测试提的Bug是分级的（成熟的产品应该有Bug分级标准和规范）。研发流程里应该有相应规定，几级以上的Bug必须全部close才能发布；开发也会按照级别来确定修复顺序，并不是所有的Bug都需要马上修复。而大众提交上来的Bug，还得额外安排人去做分级Review。
专业测试会把Bug指定给特定的开发或产品经理，背后的逻辑是这些特定人员知道技术角度的模块划分，以及对应的负责人，只有这样才能方便流程向下执行。而大众提交上来的Bug，还得安排人去做assign to这个动作。
专业测试懂得用开发明白的语言描述Bug，能说清楚是什么机器、什么系统、什么版本，特别是能说清楚“如何重现”。而大众提上来的Bug，出错环境不明确，Bug重现不了，急死你。
内部经常有针对Bug的讨论，部分Bug可以defer或reject。那么问题来了，谁来牵头组织讨论，以确定Bug状态的流转与控制？可不要指望大众会“跟进”自己提交的Bug。
如果开发比较牛，能理解大众提的Bug，但改完后谁来确认是否修复，谁来close这个Bug，整体的回归测试谁来做？
以上还只说了狭义的功能测试，性能测试、压力测试怎么办？大众没法帮你模拟10万人同时做某个操作。还有，自动化测试谁来做？
QA——质量控制相关的事情还没说呢。
其实，这个做法接近于UAT（用户接受度测试），也有人叫验收测试。经常由产品经理代表用户做（当然，有资源最好让用户亲自来），不是找Bug，而是看产品是否满足用户需求、设计是否符合用户认知，等等。
这事儿很好，有条件都做吧。但更多的目的是找个理由和用户互动，而不是找Bug。
所以，测试还是很重要的吧，虽然在早期团队中，经常“全民测试”，但这个角色与产品经理截然不同的思维方式（产品抓大放小，测试关注特例），对团队是个很有必要的补充。
