品質保障
首先, 兩個公式
軟體 = 程式 + 軟體工程
軟體品質 = 程式品質 + 軟體工程品質
程式的品質:
程式的品質展現在軟體外在功能的品質。衡量軟體的功能,基本的判斷可以用“是|否”來判斷,例如,一個字處理軟體能否通過拷貝/粘貼與其他軟體傳遞資訊。進一步,可以用複雜的多元度特征的綜合名額來衡量,例如,衡量一個搜尋引擎的品質,業界通常用精準度和覆寫率的中和名額來表示。各種功能還有很多特征需要衡量,例如,網站顯示查詢結果的速度;訂票網站能并發處理業務的吞吐量;支援同時線上使用者的數量。程式的品質還有其他方面,例如使用者體驗的品質、國際化的品質和安全性的品質。
軟體工程的品質
軟體的開發過程由三個主要的特征:“好”、“便宜”、“快”。通俗的了解是“軟體在功能、成本、時間三方面滿足利益相關者的需求”。前面提到功能方面的品質與具體程式相關,那麼軟體工程的品質就與“快”、“便宜”比較相關。一個團隊也許可以靠一些特殊的方法來提高程式的品質,但軟體工程的品質需要長期的過程來提高。
在此,引用一篇書上的連結推薦的文章
本文的作者Sriram Krishnan是一名程式員,曾在Yahoo和微軟工作過,開發過很多軟體,曾被紐約時報報道,寫過一本書,本文是他的一篇部落格。
這些年來,我對測試工作、測試人員,以及整個軟體品質管理體系形成了一些明确的觀點。受一篇關于Facebook的測試的文章的啟發,我想把這些寫下來,用以拿給人看。有些觀點是有争議的。事實上,即使在交談中稍微表現出這樣的看法,都會招緻人們的鄙視。
大多數的開發團隊并不需要一個獨立的測試角色。即使有一個,他的所有的開發時間比上所有的測試時間應該
>20:1。證據嗎?光看看一些從古至今最成功的軟體開發團隊就知道了。不論是當今的Facebook,還是30年前最初的NT團隊,很多偉大的産
品都是出自沒有或很少測試人員的團隊。
- 開發人員應該測試自己的代碼。沒什麼可說的。背後的道理并不重要。這包括單元測試,全覆寫的自動化測試或手工測試或組合測試。如果你的開發人員不能/不願意或認為這“不歸我管”,那你需要更好的程式員。
我有一些政治上不正确的話要說。一些大型的軟體開發公司會從一些不能勝任開發工作的程式員中選擇測試人員。我經曆/聽說過很多在面試開發人員過程
中有人說“他/她做開發不行。也許可以做測試?”這導緻了一個被廣泛預設,但很少公開宣稱的認識:做測試的不如做開發的聰明。正是由于這普遍的偏見,少數
一些對品質和測試工作極具熱情和天賦的人受到了不公平的待遇。我知道他們,因為我曾經和一些這樣的人一起工作過。
追求代碼測試覆寫率是危險的。因為它很容易測量,它經常會變成真正目标的替代品——開發有品質的軟體。如果你的開發團隊把功夫都用在寫愚蠢的測
試,來覆寫每一個罕有能用到的代碼路徑——因為這些資料會出現在一些報告裡——你有問題了。測試覆寫率隻是我們用的的很多名額中的一個,你需要使用它,但
并不是因為它以自然的數字呈現,它就能壓倒其它名額。它成了古德哈特定律的犧牲品。
- 我也曾看到有些公司裡有獨立的測試人員,他們寫出非常好的測試代碼。不幸的是,這被人們當成了一種常識,即使是在根本不需要這樣的時候。
- 正像測試覆寫率被過度使用,有些品質名額是被忽略輕視了。比如:過程中産生了多少技術支援郵件?自己是否在任何時候都在真正的使用自己的産品,檢測裡面的問題?分析從生産環境和客戶安裝那裡産生的日志檔案。所有的這些政策都在上面的Facebook的文章裡有提到過。
技術上司的一個常見的減少測試隊伍的體積的辦法是做自動化測試。這是個巨大的錯誤。如果你有一個使用者直接接觸的産品,你絕對需要用人眼去測試它。
如果你和微軟Windows團隊的人坐下來一起和咖啡,你會聽到他們抱怨過度依賴自動化測試導緻了Windows
Vista大量的bug。這個錯誤說明的問題就是:你需要一個全職的測試人員來使用你的産品。
總結
分工是社會和行業進化的結果。開發和測試其實是軟體工程的兩個分支。不同的軟體和服務需要不同方式和程度的測試。獨立專業的測試角色等同于第三方代表隊産品品質進行測試和驗證。那麼一個團隊應該如何培養和安排每個角色呢?
- 在初始階段,每個團隊成員都要盡量打通每個環節,多負責,把所有事都搞懂,培養通才。
- 當項目/産業發展到一定階段,要大力提倡分工合作,培養專才。
- 做好自己項目發架構和流程,讓所有人都能比較輕松的開展品質保證工作。
- 培養“大家都要做QA,專人負責量化的測試,有條件多做測試的自動化”的文化。
- 弄清楚自己項目的特點,人員的特點,産業特點。避免簡單照搬别人的做法。不要聽說某某偉大的系統的開發/測試比例是多少,就哭着喊着也要同樣的比例。