質量很重要，毋庸置疑的。但是進入新時代-- service -based software 的大量普及，軟件測試所處的環境發生變化，是值得軟件測試人員思考， 認真思考一下。
“測試之死” 並不僅僅是一個噱頭。
首先看看軟件測試所在的環境變化：
1. "fix defect " 的成本變越來越低成本。
傳統的軟件發布是基於一個軟件包（package），有時很大，需要四五張光盤才能安裝。軟件發布出去后，如果有嚴重問題，需要修復，那是個很頭疼的事。想想豐田汽車如何被召回的。現在軟件運行在瀏覽器，有問題只需要改一下服務器，甚至不需要重啟就直接修復了。 比較一下二者的成本，就這到為什么傳統的軟件測試人員千方百計的在軟件發布前找到盡可能多的缺陷。而現在，主要矛盾已經由軟件質量本身的擔憂轉移為對軟件發布的速度上面。
2. 軟件持續發布。
持續發布，跟傳統軟件一年一發布策略有着天然的優勢：反饋快速快，應對需求變化快，更好讓用戶參與，提高交付滿意度等等。 比如現在用的chrome，3年多發布17個版本。然而這些對軟件測試提出了新的挑戰，測試要快，至少不能拖慢開發節奏。如果測試影響軟件發布的時間，這是不可接受的。傳統軟件測試，耗時耗力。盡管自動化測試的呼聲，以及對應的想法，工具，數不勝數，但是面對如此短的發布周期，軟件測試人員已經有點吃力。
3. 軟件的測試理論沒有什么重大突破。
幾十年來軟件測試連最基本的問題都解決： 比如軟件質量的定義？ 軟件測試的充分性？ 軟件質量的評估？ 如何保證測試用例本身的質量的衡量？
4. 軟件測試回報率低。
傳統的軟件測試需要專職人員，並且軟件測試成本高：需要買系統，搭環境，寫用例，自動化，分析及報告，以及最終的維護。這是一個大投入，回報率卻不見得都是那么高。更何況現在，系統，測試環境，用例實現，分析報告，這些都可以統統自動化起來（continous integration or continous deliver). 軟件人員的依賴還需要那么多嗎？
5. 測試只驗證軟件的正確性。
測試，很大程度只是測試軟件本身是否滿足需求。但是對於軟件需求本身對不對，軟件測試卻很少覆蓋到。 Tseting just verify the thing right， but can't verify the right thing. 這本身不僅僅是軟件測試者的問題，比如測試人員基本很難和最終客戶交流。 然而總正確的事比把事情作對，重要的多。這需要測試人員向領域專家靠攏，但是現階段這樣的測試人員很難具備這樣的技能。
6. 敏捷鼓勵更多的開發人員嘗試一些測試。
敏捷里面的軟件質量是有整個團隊負責，並提出一些方法鼓勵開發人員去做測試：Unit Test，TDD，甚至希望開發拿出20%的時間來做軟件測試。甚至開發人員交互測試。
7. 結果導致市場上對測試職位越來越少，或者外包出去給utest 去做。 自己僅此感覺。
軟件測試的從業者，何去何從？
1. 轉化為開發人員。
不少測試人員本來就是開發人員，對於他們而言不是難事但是他們還會轉回去嗎？而對於那些手動測試者而言這條路難度有點大。
2. 轉化為領域專家。
這個需要積累，不是一撮而就的。熟悉自己產品，到熟悉整個行業，最后變成領域專家。
3. 轉化為軟件運營人員。
熟悉自己的軟件架構，部署，很容易去運營和維護這個產品。但是需要提高這方面的技能。
4. 增強人間技能，自動化測試。
畢竟軟件測試還是需要的人來做的，可以做測試方面的專家，自動化測試是一個不錯的方向。
5. 其他...（培訓，咨詢，軟件項目中的其他任何角色...)
歡迎大家分享自己對軟件測試未來的看法：）