新年伊始，又想吐槽一番。
背景；我在一個做自動化的持續集成測試的組。
我們隔壁有一個做測試工具的組。半年前我們隔壁組做了一個工具，具有代碼分支管理、靜態分析、不同級別的單元測試、集成測試等功能，
這個工具被老板看中，強制讓所有部門使用這個工具來提交代碼。不用這個工具提交的代碼將不能合入產品代碼的主分支。使用這個工具提交的代碼會自動去編譯、打包、進行各層測試。
大家使用之后，發現這個工具爛透了。有無數的嚴重BUG。（比如提交上去的代碼不能打包成功，等等。）
我每次提交代碼使用這個工具需要浪費大約8小時時間來解決他的bug導致的問題，才能最終把我們要提交的代碼提交上去。
接着，隔壁組對這個工具的開發陷入了泥潭。
工具質量極差，被用戶（各個其他需要提交代碼的部門）提了很多BUG。
不得不停止開發新功能，去改BUG。改BUG時又引入新BUG，導致用戶提交了更多的BUG。
這個時候，工具組的人和上頭的老板才意識到這個東西這樣做下去不行。
這工具需要測試。
於是找了個自動化測試架構師，帶了一群實習生來做自動化測試。
他們把該工具的API拿出來，封裝了一套自動化測試關鍵字。寫了一些自動化測試腳本。
希望建立一套持續集成測試系統來對這個系統做自動化回歸接口測試。
這時我們組的老板有意向把這個系統的測試工具接過來 （就因為我們組是專門做持續集成測試的？），於是來咨詢我們的意見。
我想說，錯了，這個方向完全錯了。
這個項目注定會在泥潭里越陷越深。
這個項目中有很多錯誤：
1. 開發之初毫無測試意識。作為一個測試工具開發組，好歹算半個測試人員，居然沒有一點測試的意識。不配備任何測試人員地去寫一個影響很大的工具。
2. 沒有單元測試。值得一提的是我們的所有產品代碼都有或多或少的單元測試。所以沒有單元測試，在我們這里肯定是一個錯誤。
3. 沒有分析過這個系統的風險和各種外部依賴之間的關系。結果開發出的測試工具依賴多個不穩定的外部系統或服務。導致本來質量就差的工具顯得質量更垃圾了。
4. 當發現需要測試時錯誤地選擇了自動化測試。你們需要的是一個熟悉產品，熟悉需求的，合格的手工測試人員。
以手工回歸測試執行的慢為理由拒絕手工測試。這正是這個組最大的錯誤。
合格的測試人員，掌握快速測試的思想，使用合適的工具，完全可以把任何復雜系統的測試時間降下來。在最短時間內發現最嚴重問題。
5. 他們最終也沒有意識到測試人員需要了解需求。找了完全不了解需求的實習生來做自動化測試。當然了，這個工具也壓根沒有需求文檔。
這時如果是一個合格的測試人員，我們會先去學習、了解這個系統，然后自己整理出這個系統的需求。以此為依據來進行測試。
但是，顯然，由於我們公司全部都是自動化測試人員，並沒有一個合格的手工測試人員。
即使我可以做，我也不願意去加入這個爛攤子。
6. 自動化測試來不及解決這個系統的質量問題。
諷刺的是，他這個工具本身是一個持續集成測試工具。他們想要我們來搭一個持續集成測試工具的持續集成測試系統。真是一個笑話。到時候我們這個持續集成系統搭好了又一堆BUG誰再搭一個來測我們的系統？
而且這個時間線也拉得太長了，這套自動化API測試即使搭起來也是很久以后了，寫腳本的人又不懂用戶需求，根本不能寫出有實際意義的腳本。也就是說，即使測試全PASS，也不代表系統真的沒問題。
7. 測試人員不是救火隊員。你的系統質量已經爛成一坨了，請不要妄想此時引入一兩個測試人員來背黑鍋。所以這種情況下，我是絕對不願意接這個活的。
而且手工測試人員的地位之低真是令人驚訝。
能改善這種垃圾系統的質量的測試人員都是真正的高手，他們卻想把這種高人當作打下手的人放進項目組，做夢呢。
我就只能不屑地笑笑，然后告訴他們，這個系統病入膏肓沒救了。
最后這一切又印證了我對測試工具/自動胡測試的看法：測試工具和自動化測試腳本本身的質量是最需要保證的。
請把三流開發人員從這個做自動化和做工具的隊伍中踢出去，最起碼也找一些二流的開發來做。另外，請找一個一流的架構，從一開始就減少這個系統的BUG產生可能性。
而不是找三流的架構加三流的開發，作出一堆垃圾再去找測試背鍋。