誰在軟件測試圈子里面販賣焦慮？
有兩周沒有整理相關評論了，應該是最后個話題了，也是糾結的一期。因為會有人看了不高興，琢磨了一下，還是不吐不快。
本期要“炮轟”的是所謂的“軟件測試工程師就業培訓”機構是如何在軟件測試領域“販賣焦慮”的。
炮轟的目標是：軟件測試工程師的培訓課程應該怎么設置？以及目前的軟件測試工程師培訓課程為什么以編程內容為主？
評論：伊之軒，朱秀杰
領測老賀回復：
我們先來看看如何“販賣焦慮”。
?????? “販賣焦慮”，本質上是把情緒極端化，進而商品化。從傳播角度看，這些做法都有一個清晰鏈條：極端案例一般化、復雜因果片面化、現實問題擴大化，瞄準大多數人情緒點，大肆造勢。博了眼球、傳遞情緒、販賣產品、收割流量，從炮制焦慮到“完成交易”，一個帶有產業性質的鏈條，環環相扣，躲之不及。面對“焦慮市場”，更多獲取信息與知識，更大程度培養獨立思考能力，是謹防在“焦慮鏈”上被套路的關鍵。
在軟件測試領域如何販賣焦慮是個大話題，也是個比較難談的話題。當時（2020年）我寫這篇文章時，就是由于軟件測試領域一直彌散著測試工程師終將被代碼測試代碼取代，似乎所有的地方都在向測試工程師販賣著焦慮。
?????? 為了展開說清楚這個問題，我把這個話題分為幾個部分進行闡述。
- 到底誰在軟件測試領域“販賣焦慮”？
- “代碼測試代碼”會不會成為軟件測試的未來？比重會有多大？
- 測試工程師應該不應該具備編碼技術？需要達到什么水平？
- 他們為什么要“販賣焦慮”？
下面領測老賀就花點時間仔細談談這個話題！
不知道從什么時間起，軟件測試領域就彌漫著一種的氛圍，簡單的描述一下就是：開發看不起測試，因為測試工程師不會編碼。自動化測試工程師看不起手工測試工程師，因為手工測試工程師不會編碼。
但是在我二三十年的培訓、演講經歷中，遇到過很多在各自領域很厲害的開發工程師，測試工程師，并沒有明顯的這類傾向。更多的是闡述在某個特定的領域內，具體用那種技術手段，解決哪類問題效率更高。
通過我的觀察，制造或者宣傳這類論點的主要是兩類人：
- 一類：初級的開發工程師，工作年限不高，職位不高，更多顯示的是一種優越感，帶有調侃性質。但是數量不多，粗略估算，言論的占比不到10%吧，可能更少。
- 二類：各式各樣的軟件測試就業培訓機構。在各個網絡平臺上進行課程宣傳，發帖，回帖。說的有理有據，制造著“手工（功能）測試工程師”明天就會被淘汰的輿論。占比90%以上。
??????? 當滿屏的都是第二類的觀點時，難免會讓軟件測試的從業者，尤其使用的是功能測試手段的測試工程師感到“焦慮”！? ? ?
在《炮轟“測試左移”，向軟件測試領域的“歪理邪說”宣戰》這篇文章中，其實已經詳細說了我的看法，在前面幾篇評論的整理中也談到了。在此我只想簡單的說一下，只要使用軟件的用戶還是人，那就一定需要人來做最終的驗證。所以“代碼測試代碼”絕不會成為唯一的軟件測試驗證手段。
??????? 那“代碼測試代碼”的方法，在整體軟件測試環節中的工作量會占比多大那？
??????? 很遺憾，這個沒有定論，不同的行業，不同的軟件會有非常大的區別。
??????? 其實我們可以參考上面的思路進行判斷，假定最終用戶或者使用者是普通客戶（不懂代碼），那距離使用者越遠的結構（如單元、集成）的測試越需要代碼測試代碼的手段進行輔助，距離使用者越近的結構或者界面（如系統，驗收，易用性等）的測試工作越需要手工測試進行評價，很多時候在這種情況下接近于100%的工作量。
我的答案是作為一個以軟件測試為職業的測試工程師，當你已經充分掌握了你所在行業的業務知識（即成為被測產品的業務專家）和手工測試方法后，就需要繼續學習編碼技術了。
請注意我這句話的前提：你首先要成為一個合格的手工測試工程師，清楚的知道軟件測試的各種手段，保證質量的基本框架和方法后，編碼技術才會成為你進一步提升測試效率的工具。
作為一個測試工程師，請一定記住，編碼技術只是你提升測試效率的工具。所以，自動化測試的前提是你知道如何測試，那些是重點，那些是非重點。那些區域需要大量的測試數據覆蓋。
沒有確定目標的、可納入到整體軟件測試體系的自動化測試一分錢都不值！
那作為測試工程師的編碼技術需要達到什么水平那？
這個沒有一定之規，需要看你需要解決的問題深淺了。還是要以測試工程師的視角看問題。以解決測試過程中的效率問題作為出發點。有的時候，困難的編碼問題可以提交給開發人員去解決，可能是個更優的選擇。整體效率最高才是目標！
經過以上的闡述，大家應該大致明白了領測老賀對于測試工程師對是否掌握編碼技能的看法了，對我的觀點總結一下：專業測試工程師最重要的技能是是完善的業務知識和手工測試技能，在上述兩項技能完備后，通過使用編碼技能來提升測試效率。
未完待續。。。。。。
下一篇我會主要談談所謂的“軟件測試工程師就業培訓機構”是如何在軟件測試領域販賣焦慮的
文章評論