對任何一個專業(yè)崗位，我們都應(yīng)該保持一些敬畏，反智主義只適合開玩笑的時候，不能成為做事態(tài)度。

若干年前，我在知乎上看到一個很有趣的問題：
為什么互聯(lián)網(wǎng)公司不開除測試，轉(zhuǎn)而讓大眾來測，找到一個Bug給100元？

答：大家的討論很有意思，不少都是圍繞100塊夠不夠、給不給、怎么給來說的。我的角度是，測試是產(chǎn)品團隊里一個重要的角色（團隊早期可能由產(chǎn)品經(jīng)理來兼任這個角色），沒了他們還真的不行。

默認前提是，開發(fā)已經(jīng)做了單元測試和冒煙測試（原則上冒煙測試應(yīng)該測試來做，但人家都被你們開除了啊，只好讓開發(fā)來做了，至少要保證交給大眾的是一個能跑起來的產(chǎn)品），這兩項總不至于期望大眾來幫忙做吧。
很多Bug其實并不是非黑即白，也許產(chǎn)品就是這么設(shè)計的。這些內(nèi)部的測試知道，但外部的大眾不知道，他們用起來覺得不爽，當(dāng)Bug提了，這錢是給還是不給？哪怕公司內(nèi)部，當(dāng)測試發(fā)現(xiàn)此類問題（比如為了安全考慮，第二次輸入密碼的確認框不允許復(fù)制粘貼），開發(fā)說這是一個需求/特性，還得再把產(chǎn)品經(jīng)理叫過來一起討論，外部可做不到。
專業(yè)的測試需要測試用例（Test Case），但常見的測試用例（臨界值相關(guān)、內(nèi)存會不會泄露、特殊字符等……專業(yè)測試人員玩起來一套一套的，分分鐘把開發(fā)認為沒問題的程序掛掉）在大眾那里可做不到，更不要說TC評審了?；蛘哒f，大眾永遠是知其然不知其所以然，所以只能做黑盒測試，沒有辦法做白盒測試。

專業(yè)測試提的Bug是分級的（成熟的產(chǎn)品應(yīng)該有Bug分級標準和規(guī)范）。研發(fā)流程里應(yīng)該有相應(yīng)規(guī)定，幾級以上的Bug必須全部close才能發(fā)布；開發(fā)也會按照級別來確定修復(fù)順序，并不是所有的Bug都需要馬上修復(fù)。而大眾提交上來的Bug，還得額外安排人去做分級Review。
專業(yè)測試會把Bug指定給特定的開發(fā)或產(chǎn)品經(jīng)理，背后的邏輯是這些特定人員知道技術(shù)角度的模塊劃分，以及對應(yīng)的負責(zé)人，只有這樣才能方便流程向下執(zhí)行。而大眾提交上來的Bug，還得安排人去做assign to這個動作。
專業(yè)測試懂得用開發(fā)明白的語言描述Bug，能說清楚是什么機器、什么系統(tǒng)、什么版本，特別是能說清楚“如何重現(xiàn)”。而大眾提上來的Bug，出錯環(huán)境不明確，Bug重現(xiàn)不了，急死你。
內(nèi)部經(jīng)常有針對Bug的討論，部分Bug可以defer或reject。那么問題來了，誰來牽頭組織討論，以確定Bug狀態(tài)的流轉(zhuǎn)與控制？可不要指望大眾會“跟進”自己提交的Bug。
如果開發(fā)比較牛，能理解大眾提的Bug，但改完后誰來確認是否修復(fù)，誰來close這個Bug，整體的回歸測試誰來做？
以上還只說了狹義的功能測試，性能測試、壓力測試怎么辦？大眾沒法幫你模擬10萬人同時做某個操作。還有，自動化測試誰來做？
QA——質(zhì)量控制相關(guān)的事情還沒說呢。
其實，這個做法接近于UAT（用戶接受度測試），也有人叫驗收測試。經(jīng)常由產(chǎn)品經(jīng)理代表用戶做（當(dāng)然，有資源最好讓用戶親自來），不是找Bug，而是看產(chǎn)品是否滿足用戶需求、設(shè)計是否符合用戶認知，等等。
這事兒很好，有條件都做吧。但更多的目的是找個理由和用戶互動，而不是找Bug。
所以，測試還是很重要的吧，雖然在早期團隊中，經(jīng)?！叭駵y試”，但這個角色與產(chǎn)品經(jīng)理截然不同的思維方式（產(chǎn)品抓大放小，測試關(guān)注特例），對團隊是個很有必要的補充。