無論是公司領導還是測試人員本身，現在普遍存在一個錯誤的直覺，就是認爲測試比開發簡單，上手快，技術和經驗要求低。很多公司將測試人員的工資開的比開發人員低，職業路線也沒有開發人員寬廣。測試人員自己也常常認爲，做測試就是敲命令，取log，把所有的難題都交給開發人員，不認爲自己對軟件的質量提高也有責任，對自己的要求也很低。我也有一些同事認爲，開發人員和架構師可以插手和質疑測試過程，可是測試人員不應該插手和質疑軟件的設計和需求分析，測試人員應該只管好測試就OK了。
其實，這樣的想法，對企業自身的發展是很不利的。要知道，一個產品的質量取決於這個產品鏈上最薄弱的環節。設計開發和測試是對等的，設計強而測試弱，產品的質量一樣上不去。
軟件是不可能不出錯的。記得以前看過一本書，有個原來做硬件開發的人後來轉去做軟件。他寫的代碼一個錯誤也沒有，大家都很奇怪，去問他是怎麼做到的。他更奇怪地反問大家，啊？難道可以出錯嗎？他原先是做硬件的，硬件對bug是很難容忍的，所以要求處處小心，嚴格把關。可是軟件就不同了，軟件的bug似乎是與生俱來的，原因有很多。軟件的應用發展很快，升級換代也快；軟件結構複雜，層次豐富，接口衆多；軟件開發人員門檻較低，素質參差不齊；人們對軟件bug的容忍度較高，等等。我們已經無法期望軟件零缺陷。儘管敏捷的鼓吹者曾經宣稱過敏捷環境可以避免傳統軟件開發帶來的問題，但事實證明他們只是在吹牛而已。
軟件的質量在多大程度上依賴測試人員，取決於測試人員的素質和管理者對測試的理解。
我比較欣賞米國的企業，把測試人員叫做QA，就是質量保證人員。這是在告訴測試人員，他們不僅僅要執行測試，而且要參與一切和產品質量有關的活動，是對產品質量負責的人。這樣，測試人員的責任和重要程度就會大大提升。
爲什麼呢？我們首先來看，軟件的錯誤有哪些？
軟件從需求分析開始，就會引入錯誤。而且越是前期的錯誤，造成的損失就越大。需求分析，就是將用戶的需求轉化成產品的需求。這是系統架構師需要做的事情。系統架構師需要明確這個產品該如何來滿足用戶的需求，有哪些use case，這些use case直接關係到V-mode中對應着的系統測試的test case。系統架構師需要來自系統測試人員的反饋，來判斷這個case的可測性和可用性。用戶是否真的需要這些case，系統測試人員往往會給出他們的意見。Use case的偏差，直接會導致用戶的不滿，而且有可能導致整個feature的失敗。我們有過不少這樣的經歷，就是系統架構師在需求階段容易求大求全，在系統的複雜性和新功能對系統的影響上，在客戶如何使用新feature上沒有經驗，在開發和測試階段，麻煩不斷，導致整個feature無法按期完成，最後不了了之，所有的努力都付之東流。系統測試人員在需求階段加入，可以從用戶的角度給架構師以反饋，告訴他什麼功能是用戶最需要的，什麼功能是可有可無的，用戶最關注的點在哪裏。這樣，架構師就可以有所取捨，將最能滿足用戶，且易實現和測試的部分規劃出來，進行優化，捨棄那些對用戶來說可有可無，卻佔到大量開發和測試時間的部分。一個公司的架構師往往是從軟件開發人員培養而來，他們過多地重視開發成本，而忽視測試成本，也忽視用戶的使用感受。記得有一個產品經理曾經告訴我，他們很難獲得用戶的真實感受，因爲和用戶開會的時間非常有限，一兩個小時的會議，要討論幾十個新feature，每個feature只能佔用5分鐘，很難在這5分鐘裏問清所有的問題，只能靠猜。其實，比猜更有效的方法，是培養優秀的系統測試人員。他們不但熟悉測試，也能通過驗證用戶報的bug瞭解用戶對feature的使用，也能夠體會用戶的感受。讓系統測試人員參與需求分析過程，避免系統架構師出現大的偏差，幫助系統架構師預測用戶對新feature的使用方式，是對產品質量提升的一個很重要的手段。
然後是軟件實現引入的錯誤。軟件實現包括軟件設計思想，軟件架構和代碼開發。對應的是功能測試。有些人認爲，功能測試應該是黑盒測試，只關注需求，不應該瞭解軟件的實現。我覺得這句話的意思是，不應該受軟件實現的困擾。但是，知己知彼，百戰不殆，這句話總是對的。有的時候，瞭解軟件的設計思想，就可以預見軟件實現是否滿足了需求，可以避免毫無意義的測試，浪費寶貴的時間。比如說，我們曾經有一個接口雙備份的feature，設計思想非常糟糕，邏輯混亂，只要看了設計文檔，就已經很清楚測試的結果了。根本沒有必要再去執行測試。正確的行爲應該是“發回重審”，讓軟件架構師重新考慮設計方法。可我們還是執行了測試，發現了很多問題，然後是開發人員修改bug，結果越改越亂，最後連開發人員自己都不知道什麼纔是正確的行爲。這個feature浪費了大家很多時間。還有一個IP QoS的例子，在瞭解軟件人員的解決方案之後，我們就已經知道測試的結果了。我們認爲這不能滿足用戶的需求，可是還是經過了測試，報錯，改錯的過程，也並沒有達到一個好的結果。軟件設計是否滿足需求，這是軟件架構師，有些公司是資深軟件開發人員的工作。如果軟件設計無法滿足需求，後面的工作都是白費力氣。測試人員參與軟件設計，不僅僅是審查需求的可測性，也是在以測試和使用者的眼光來看待這個設計是否符合產品的需求，預見測試的結果。這對開發人員來說是很重要的。
軟件架構引入的問題也很多。有經驗的軟件架構師知道如何優化系統，如何減少模塊和模塊之間的影響，接口如何定義清晰並具有可擴展性，數據如何共享和保護，消息如何傳遞，如何在減少系統開銷的同時增加系統的容量，內存如何分配，垃圾如何回收，在滿足這些條件的基礎上如何選擇最簡單的架構。這些說說容易，做起來很難。很多時候，糟糕的系統架構本身就會引入瓶頸。在瞭解系統架構的情況下，測試人員很容易就知道如何找出系統最嚴重的問題。我記得我到一個部門去做測試架構師的時候，測試人員經常向我提及這個系統的問題，他們已經在測試過程中有了很強烈的感受，可是軟件架構師們卻一直不知道，他們似乎聽不到測試人員的聲音。當我設計了幾個簡單的性能測試case，把最直接的測試結果擺在他們面前的時候，他們似乎是如夢初醒。但那個時候，已經進入系統測試階段，修改軟件架構是不可能的了。到了開發第二個版本的時候，架構師想修改軟件架構，可是要付出的代價實在太大，只好做一些有限的調整了。如果在軟件架構時讓有經驗的測試人員加入，讓測試人員幫助檢查系統的架構問題，而不是等到測試的時候才知道犯了錯誤，可以極大地提高軟件的質量。
也許大家會很奇怪，爲什麼開發人員不知道自己的產品有什麼問題？這個道理很簡單，因爲開發人員是製造者，而不是使用者。很多軟件人員除了編譯自己的軟件外，從來不使用自己寫的軟件。這樣，他們根本不知道自己寫出來的東西究竟好不好。我記得我剛開始做開發人員的時候，寫用戶界面。一開始我做得很花哨，功能很多，有些自鳴得意。但我喜歡做好了就讓旁邊的人來用用看，聽聽他們的意見。結果他們覺得我做得太花哨了，一點也不好用。我只好忍痛割愛，簡化設計。我不停地修改，不停地讓他們使用，反反覆覆很多次，最後在他們的抱怨聲中我把所有沒用的花哨的東西都去掉了，界面又清晰又好用，連自己都喜歡上了最後的風格。這也是爲什麼軟件人員無法同時做自己產品的測試人員的原因。生產者很難客觀地審查和評價自己辛苦創造的東西，所以他們對自己的產品不如使用者瞭解。測試人員在長時間的測試過程中，逐漸瞭解了軟件和系統存在的各種問題，對可能出現的問題更加敏銳。那些架構師們也許只需要花上半天時間，找測試人員聊聊，就知道自己設計出來的東西有多麼大的問題了。可惜的是，他們常常高高在上，不屑於去聆聽使用者的聲音。
說了這麼多，就是想強調，提高測試人員的責任感和素質，對於提升產品質量是很重要的。測試人員越早加入軟件開發流程，越是能提高軟件的質量。測試人員不僅僅是測試的執行者，更是理解需求，審查需求分析，討論軟件架構，尋找系統瓶頸的重要參與者，更是用戶的代言人。對於測試人員的要求是很高的，也應該更加重視測試人員的反饋和意見。
在很多公司，測試往往是最薄弱的一環。我們可以看到國內很多產品，花哨的功能很多，可是用起來很不爽，質量也不過關，這都是隻重視開發，不重視測試的結果。一個公司要想長遠地發展，必須重視測試，培養優秀的測試人員，給予測試人員更多的責任和權利，才能讓自己的產品更穩定，更好用，更加符合客戶的需求。