左耳朵耗子發表了《我們需要全職的qa嗎？》後，一石激起千重浪，贊成者有之，激烈反對者有之；有人說文中對qa的定義不對，還有人說以偏概全…… 的確，在需不需要專職的qa角色這個問題上，很難用乙個簡單的「需要」或「不需要」來回答。前兩天我寫了一篇對該文的回應文章，但由於文章寫就得比較倉促，很多觀點來不及完整表述，因此，在「真理越辯越明」的原則下，在這篇文章中，我準備就「我們需要什麼樣的測試」這個問題說說我自己的看法。
首先要說明的是，這篇文章完全不是討論「我們是否需要專職qa」這個問題的，也不是討論「各種情況下qa或測試工程需要做什麼」，而是從我自身對測試的認知和個人經驗出發，說一說我對不同特點的產品需要的測試的看法。
本文討論的前提是：「不同的產品需要不同的測試」。當我提到「產品」時，除了產品本身所對外展現的特性外，還會隱含地包含了該產品開發團隊的狀況。這篇文章沒有把行業作為乙個劃分的維度，是因為我相信，即使在同乙個行業中，也存在各種截然不同的產品。
測試是為質量服務的，測試活動圍繞質量進行。這個定義是我們今天討論的出發點。iso 9126模型給出了乙個多層次的質量模型定義，該定義包括了各個正交維度的質量屬性，這些質量屬性中既有面向使用者的，也有面向開發的。但在實際的測試工作中，一旦提到產品質量，大部分人更容易將其理解成「使用者質量」，也就是「終端使用者所能感受到的軟體的質量（例如，軟體的功能性、效能、安全性等等）」。「使用者質量」是使用者所能夠直接感受到的產品的「好壞」，也是使用者是否願意為產品付錢的主要原因。因此，在測試中重視「使用者質量」是必然的。設想一下，如果a公司要為b客戶開發乙個軟體，只要該軟體最終能夠達到b使用者的要求，a公司就能拿到錢，通常這也就意味著a公司「成功的完成了該軟體的開發」。從這個角度來說，「使用者質量」就是軟體開發是否成功的標準。
然而，如果深入看待整個軟體開發過程，事情就沒有這麼簡單了。a公司為客戶b開發的軟體並非是一錘子買賣，而是需要不斷的維護和公升級的，b使用者不斷提出新的需求，而這些新的需求都要被加入到軟體中去。在這種情況下，從效益出發，a公司就不能僅僅考慮最終的產出是否能夠滿足b客戶的要求了，而是必須想辦法保證產品在持續演進的過程中始終保持好的可維護性和可測試性，這樣a公司才能以較低的成本讓這個產品持續成功。因此，如果不把軟體開發看成一錘子買賣，而將該軟體的生命週期的維護過程考慮進去，我們就不得不關注「使用者質量」之外的「開發質量」，這裡的「開發質量」就是指產品內在的，是否容易被修改、是否容易被移植、是否容易被驗證的特點。
1.「使用者質量」和「開發質量」就是我通常用來分析乙個產品究竟需要什麼樣的測試的第乙個因素。
2.另乙個直接決定了產品需要什麼樣的測試的緯度是「產品對缺陷的容忍程度」。
測試工程師有時候喜歡把「零缺陷」作為標榜測試工作的口號（我在很長一段時間內也是如此），但，仔細想想，如果發現乙個缺陷的成本比讓這個缺陷留在產品中帶來的損失更大，那是否還值得去發現這個缺陷？我想，從專案的角度來說，答案是不言而喻的。測試是乙個資源權衡的活動，也是乙個基於風險的活動，因此，產品的缺陷帶來的影響越小，影響越容易被消除（修復），這個缺陷的價值就越小，值得投入用來發現缺陷的資源也就越少。
拿網際網路產品和傳統的桌面產品來比較，對桌面型產品來說，缺陷的修復成本足夠高（只能通過軟體召回或是發布補丁的方式），因此對缺陷的容忍度就低；而對於網際網路產品來說，由於其產品的修復成本足夠低（對乙個已知的缺陷，可能只需要花上幾分鐘到幾十分鐘就能完全修復了），因此相對而言，其對缺陷的容忍程度更高（當然，對於那些會導致使用者資料損失或是帶來其他不可逆破壞的缺陷，那又另當別論了），對網際網路產品開發來說，及時識別缺陷（發現那些使用者已經遇到的缺陷），快速定位缺陷和快速修復缺陷的能力往往要比在系統測試階段發現缺陷的能力更重要。而要能有強大的識別缺陷和定位缺陷的能力，就必須依靠產品內建的「開發質量」了。
再以醫療行業的某些軟體為例，對涉及到醫療器械的控制軟體（如自動注射器，心臟起搏器等），其對缺陷的容忍程度就非常低，原因很簡單，因為這類缺陷可能帶來的後果太嚴重。
3.第三個因素是「有效的測試方式」。
對網際網路產品來說，最有效的測試方式也許並不是找一堆專職的測試工程師在公司內部盡可能地覆蓋每乙個功能細節，讓真正的使用者來對產品進行測試在很多情況下也許是更好的選擇。無論是fb，google等公司提倡的dog food（讓全部員工來進行測試），還是在實際產品上進行的a/b testing, 或是遊戲公司通常喜歡採用的內測方式，都是典型的讓使用者參與測試的方法。另外，根據產品不同的特性，適合採用手工測試還是自動化測試的方式來進行測試也是乙個值得考慮的點。
4.第四個因素則是「產品的開發團隊所處的狀況」，因此，對同乙個組織來說，在組織發展的不同階段，所需要的測試也是不同的。
「苦逼的團隊是做不出有愛的產品的」，自然，「苦逼」的團隊也不可能達成好的測試。因為讓每個人疲於奔命的是總也無法完成的任務和無止境的加班，恐怕都沒有停下來思考如何改進的機會。
以上就是我對「什麼樣的產品需要什麼樣的測試」這個問題的理解。在這四個因素的指導下，再回頭來考慮不同軟體產品的測試，就很容易理解為何不同的產品，不同的企業會採用很不相同的測試方式。例如，fb沒有專職的測試工程師，因為通常意義上關注「使用者質量」的測試工程師並不能在這個組織中發揮大的價值，只有對開發有深入了解的開發工程師才能真正的在提高「開發質量」方面發揮作用。而對於許多國內的以「做專案」為主的軟體企業來說，也就很好理解為什麼他們只需要「能像客戶一樣發現產品中的缺陷的」的測試了。
我們需要什麼樣的計算
本文選自 讓雲觸手可及 微軟雲計算實踐指南 一書 我們需要什麼樣的計算 我認為全球電腦市場的規模大約為5臺。ibm創始人托馬斯 j 沃森 thomas j.watson 1943 當我們站在微軟美國芝加哥資料中心一層的時候，資料中心管理人員告訴我這一層有好幾萬臺計算機，但是我們一台也沒看到。這是我見...
我們需要什麼樣的自由軟體？
不久之前，美國 自由軟體 會 提出了 10個自由軟體應該優先發展的專案 high priority free software projects 並且宣稱這是當前世界最需要的開發專案。對此，有人贊成，有人反對。而 ubuntu 8.10 的發布，引發的卻是一場實實在在的 頭腦風暴 flurry 2,...
我們需要什麼樣的應急手冊 佐岸
一架處於高速飛行狀態的飛機，如果突然發生了故障，飛行員將採取什麼對策呢？結果可能出乎你的意料，因為飛行員給出的答案可能是 先看書，再排險。為什麼會如此呢？因為當高速飛行的飛機遇險時，飛行員往往沒有足夠的時間進行思考，進而找到最佳的解決辦法，因此，最明智的辦法反而是照著飛行手冊所說，判明故障，然後排除...