七年前，我在寫《完美測試：軟件測試系列最佳實踐》時，列了十幾條測試原則，可以概括爲十大測試原則：
-
測試目標要明確，並建立合理的階段性目標
-
一切從客戶/用戶的角度出發，想客戶所想
-
測試儘早介入，一旦項目啓動，測試就要介入進去。
-
儘可能確保軟件的可測試性
-
持續地測試、持續地反饋，最大程度地降低研發成本，提高研發效率
-
測試時不能窮盡的，應設定合理的測試目標或測試終止的條件
-
基於項目的上下文來制定相應的測試策略
-
基於風險的測試策略總是有效的
-
測試計劃不僅是文檔，更是一個過程，應根據測試狀態不斷變化而進行調整
-
80/20原則，發現錯誤越多的地方，越要投入更多的測試資源或進行更深入的測試
這些原則並沒有考慮開發是傳統的還是敏捷的，而是具有良好的普適性，能有效地指導測試的工作。
前天本公衆號轉發了Christina Geng和Lisa Crispin 對話敏捷測試 文章，提到了Alan Page和Brent Jensen在其AB測試播客中提出的現代測試原則，今天就來說說這七項現代測試原則。
所謂現代測試原則，是適應敏捷開發模式的（人們往往把敏捷開發看成是現代開發模式），而不適合傳統開發模式的。從敏捷開發目標看，就是要做到快速交付、持續交付。作爲測試，就是如何助開發一臂之力，實現高質量的持續交付。Alan Page和Brent Jensen（簡稱：AB）認爲“在敏捷開發中，測試人員可以開始從質量所有者轉變爲可交付質量的大使，提供價值，並改善團隊的質量文化”。這種提法值得商榷：
-
在傳統開發中，測試人員也不應該是質量的所有者。質量一定是整個團隊和公司管理者共同擁有，而且測試人員也不是質量的管理者，因爲有質量管理人員或質量保證人員（QA），甚至不是質量改進的最主要的驅動者（團隊的每一個都應該是質量的驅動者），因爲還有工程過程組（SEPG）。雖然上線後漏掉缺陷，有些公司第一個責怪的人會是測試人員。即使在傳統的公司中，這樣做的公司也算是比較落後的公司，不能把落後的公司的實踐算在傳統測試的頭上。如果要問責，也是要把開發人員和測試人員一塊叫過來，看看問題究竟出在哪裏。
-
大使，有全權代表的含義，也有形象代言人的含義，這裏是指：敏捷測試人員作爲質量的代言人還是作爲全權代表？感覺都不對，這樣是不是回到老路上去，而且把測試的責任搞含糊了。測試人員就是不斷暴露軟件產品的質量風險，不斷髮現問題，及時反饋給團隊，幫助團隊持續提升質量。
感覺AB的出發點就錯了。那我們再看看這七項現代測試原則有什麼新東西？是不是真正能成爲敏捷測試的原則？
1. 我們的首要任務是改善業務
AB認爲：現代測試人員，熱衷於提高效率，並希望加快發佈流程，更快地爲客戶提供價值。強調爲團隊增添價值，應用於功能團隊的良好測試思維是增值，而非成本，因爲過去人們往往把測試看作是成本中心。這種價值可以通過數據來驅動，表示爲客戶所熟悉的一些指標。
點評：不僅是測試，開發也一樣，都是爲業務服務的，業務驅動開發、業務驅動測試，甚至我們說：不以業務敏捷的敏捷都是僞敏捷。從這一點看，這條原則沒錯。但是，這條原則適合傳統的開發，而不侷限於敏捷方法；也適合整個敏捷團隊，而不侷限於測試人員。其次，AB的解釋，並沒有真正觸及到“業務爲先的測試”、“業務驅動測試”的實質，即如何明確表達“業務驅動測試的準則”。
2. 我們加速團隊，並使用精益思維和約束理論等模型來幫助識別、排序和緩解系統的瓶頸。
AB認爲：測試人員做較少的測試，更多是驅動質量的提升，指導開發人員設計小規模的測試（這來自Google公司對測試的劃分：小規模、中等規模、大規模的測試，而不是我們通常說的單元測試、系統測試、驗收測試），讓開發人員做更多測試。測試人員負責那些大規模的測試。通過單項工作的結對體驗（如結對編程、結對測試），團隊可以在代碼中找到更多缺陷，並更快地培育質量。
點評：這裏更多是強調團隊對測試負責，測試人員是測試教練，更多是做那種貫穿業務流程、端到端的測試，單元測試或單個功能測試應該讓開發人員自己做。提升開發的測試能力，或整個團隊做測試，是解決“測試作爲敏捷研發一大瓶頸”這樣的問題。但應用精益思想、約束理論來識別、排序、緩解系統的瓶頸，也是這個團隊的工作，沒有測試的特殊性。雖然我們承認，許多時候，測試是敏捷開發的最大瓶頸，這種提法也挺好的，讓我們時時關注“測試是不是處在瓶頸狀態”，不斷尋找有效的策略，加速測試。
（不急，先了解兩個知識點）
|
補充知識點：精益思想（正好也是7項原則） 1) 尊重一線人員。工作在一線的人最瞭解實際情況，能制定更好的應對措施，更有能力提出正確的改進意見； 2) 消除浪費。任何不能爲客戶增加價值的行爲即是浪費，爲了消除浪費，必須以價值流來識別浪費，並指出浪費的根源並消除它，識別和消除浪費的過程是持續不斷的； 3) 增強學習。軟件開發是持續學習的過程，從而能夠面對各種挑戰； 4) 儘量延遲決定。直到能夠基於事實而非不確定的假定和預測來做出決定，因爲系統越來越複雜，軟件開發中存在更多的不確定性； 5) 構建質量。如果從研發的各個階段（需求、設計、編程等）都能保證產出物的質量，我們就能以最低的成本達到產品的質量目標，即最大程度地減少浪費； 6) 快速交付。只有將產品交付給用戶，才產生價值。交付越快，產生價值越早； 7) 整體優化。局部的優化，若不能帶來整體的改善，將是沒有價值的。 |
|
補充知識點： 約束理論 約束即阻礙企業有效擴大產出能力、降低庫存和運行成本的環節，即任何一個多階段生產系統，如果其中一個階段的產出取決於前面一個或幾個階段的產出，那麼產出率最低的階段決定着整個系統的生產能力。約束理論是企業識別並消除在實現目標過程中存在的制約因素(即約束）的管理理念和原則，主要操作過程是： 1) 找出系統中存在哪些約束（來自原料、能力、流程、市場等方面的約束）； 2) 最大限度利用瓶頸，即提高瓶頸利用率； 3) 使企業的所有其他活動服從第二步中提出的各種措施； 4) 打破瓶頸，即設法解決第一步中找出的瓶頸； 5) 重返第一步，持續改善。 |
3. 測試人員是持續改進的力量，幫助團隊適應和優化以獲得成功，而不是提供安全網來捕捉失效。
AB認爲：隨着逐步將更多代碼密集型測試任務轉移給開發人員，並讓測試人員指導和領導測試工作，團隊項目的質量得到提高。測試人員不再被視爲最後一道質量防線，而成爲“設法留住客戶、讓客戶使用應用程序”的第一道攻擊線。
點評：讓測試人員變被動爲主動，幫助團隊持續改進，從而不斷提升構建的質量，這挺好。從本質上講，這種任務是真正SQA人員或管理人員所承擔的責任，只是許多公司SQA人員是缺失的，管理人員也不夠關注質量，結果就讓測試人員來承擔了。但這種原則更應歸爲質量文化建設、質量管理的原則，而不能算測試原則。就像前面說的，AB把測試人員當作質量大使，所以讓測試人員更關注質量文化建設的建設，從這個角度看，也沒錯。
4. 非常關注團隊的質量文化，我們指導、領導和培養團隊，以建立更成熟的質量文化。
AB認爲：創建代替孤立的測試人員的社區，這對於發展成熟的質量文化很重要。藉助協作和創新，社區成員與其他成員建立共鳴，並能推進項目的成長和新想法。
點評：這也是質量文化，不是測試，但具體的實踐——“在企業內部創建社區”挺好。我之前演講或企業內訓中也提過，當實實在在的測試部門不存在時，我們可以建立虛擬的測試部門——測試社區。這在一些公司（如Cisco）都有類似的實踐。
5. 相信：唯一能夠判斷和評估我們產品質量是客戶。
AB認爲：現代測試實踐中，客戶的反饋是非常重要的。收集客戶反饋，直接或間接地從客戶那裏收集數據，使團隊能夠最好地判斷客戶是如何響應功能的。
點評：因爲研發人員，包括產品經理、業務人員，都不能真正代表客戶或用戶，只有真正的用戶才能給出真實的產品使用體驗。要讓用戶更喜歡我們的產品或向客戶交付更多的價值，我們自然要關注用戶的反饋。這正如前面所說的傳統測試原則：一切從客戶的角度出發，想客戶所想。測試人員要能夠扮演用戶角色，設身處地去針對產品進行測試，這樣也就能挖掘更多的應用場景，發現更多的問題或提出更好的產品設計建議。
6. 廣泛使用數據來深入瞭解客戶使用情況，然後縮小產品假設和業務影響之間的差距。
AB認爲：數據是現代測試的關鍵。如果沒有數據，我們只能猜測客戶正在做什麼、真正喜歡什麼。提供無人使用或被迫使用的功能並不能長期給客戶提過價值，而數據可以提供持續和預測性的反饋、縮小產品假設和業務影響之間的差距，幫助團隊採取正確的行動。
點評：這是第1原則、第5原則的延伸，要客觀地獲得用戶的反饋，客戶使用產品的數據是關鍵的信息來源。如何基於這些數據，構建測試模型或幫助我們建立Test Oracle，需要具體的方法和工具來支持。
7. 擴展整個團隊的測試能力和專業知識;瞭解這可能會減少（或消除）對專業測試專家的需求。
AB認爲：“我是否需要辭掉工作併成爲開發人員？”不，專注於自己的測試使命，如引領質量文化、尋找改進、投入到測試工具的使用並獲取知識以更好地幫助業務等。
點評：當測試人員指導開發人員做測試，可能會擔心革了自己的命，所以纔有開頭那一問。如果對測試有信心、對自己有信心，就沒有這種擔心，否則做一些改變，“成爲開發人員”也不失爲明智的選擇。一個工程師，能做開發工作也能做測試工作，自然在職場上更具競爭力，只是在“開發”和“測試”中，我們還是有自己更擅長的一面。