在經(jīng)歷了“七年之癢”后，藍鯨項目進入第八個年頭贯莺，項目的一切趨于穩(wěn)定风喇。團隊倡導持續(xù)改進，可大家的感覺是已經(jīng)盡力做到最好缕探，這個時候似乎沒有什么可以改進的了魂莫。為了突破這個局面，項目重新聚焦測試爹耗，從質(zhì)量和測試的角度對現(xiàn)狀進行了一次評估耙考。
評估采用的是基于軟件測試原則的模型秽誊，本文就是跟大家分享一下這個模型。
測試原則
2012年澳大利亞敏捷大會（Agile Australia）上ThoughtWorks的非常資深的測試實踐帶頭人Kristan Vingrys分享了如上測試原則琳骡，這些原則是ThoughtWorks的同事們在多年軟件測試經(jīng)驗基礎上總結(jié)出來的锅论。
1. 質(zhì)量內(nèi)建（Build quality in）
You cannot inspect quality into the product; it is already there.
-- W.Edwards Deming
著名的質(zhì)量管理專家戴明指出：產(chǎn)品質(zhì)量不是檢測出來的，從產(chǎn)品生產(chǎn)出來后質(zhì)量就已經(jīng)在那了楣号。這同樣適用于軟件產(chǎn)品最易。
缺陷發(fā)現(xiàn)的越晚，修復的成本就越高炫狱。質(zhì)量內(nèi)建要求我們做好軟件開發(fā)每個環(huán)節(jié)藻懒，盡早預防缺陷產(chǎn)生，以降低缺陷出現(xiàn)后的修復成本视译，要減少對創(chuàng)可貼式的補舵揖！（hotfix）的依賴。
推薦實踐： TDD酷含、ATDD等
2. 快速反饋（Fast feedback）
每個環(huán)節(jié)的任何變化都能最快的反饋給需要的人鄙早，從而可以基于當下最新信息做出明智的決定，降低風險椅亚。這要求我們對系統(tǒng)進行頻繁的測試限番，縮短回歸測試的周期。
推薦實踐：
- 符合測試金字塔結(jié)構(gòu)的自動化測試呀舔，讓每一層的測試都能發(fā)揮盡可能大的價值弥虐，給出最快速的反饋；
-
持續(xù)集成媚赖，盡早排查集成引起的問題霜瘪，降低集成所帶來的風險。
測試金字塔
3. 全員參與（Involve everyone）
-- 這次上線好多bug惧磺，QA是怎么測的颖对？！
-- 那個xxx組在上線前發(fā)現(xiàn)了很多的bug豺妓，他們的QA真給力惜互！
成也QA布讹，敗也QA…如果還是這樣的認識琳拭，那是極為片面的。測試不僅僅是QA的事情描验，團隊成員要一起為質(zhì)量負責白嘁，軟件開發(fā)生命周期的測試相關活動需要全員的參與。
全員參與的好處是利用不同角色的不同領域知識和不同的思維模式膘流，不僅可以使得測試的質(zhì)量更高絮缅，同時還能最優(yōu)化利用測試資源鲁沥，做到價值最大化。
推薦實踐：
- 自動化測試：QA和BA結(jié)對用DSL編寫測試用例耕魄，QA和Dev結(jié)對編碼實現(xiàn)測試画恰，生成業(yè)務人員可讀的測試報告；
- Bug bash（bug大掃除）：團隊不同角色一起參與的一個找bug的測試活動
4. 測試作為資產(chǎn)（Tests as asset）
自動化測試幫助我們驗證系統(tǒng)功能的正確性吸奴，好的自動化測試還有文檔的功能允扇，是寶貴的資產(chǎn)。如果每個項目都構(gòu)建自己獨立的自動化測試则奥，沒有跨項目共享考润，其浪費顯而易見。
這個原則要求把自動化測試的代碼跟產(chǎn)品開發(fā)的代碼一起读处，當做資產(chǎn)管理起來糊治，在不同項目間做到盡可能的復用。這筆寶貴的資產(chǎn)能幫助我們更好的統(tǒng)計跨項目的測試覆蓋率罚舱，更好的優(yōu)化測試井辜。
推薦實踐：利用版本控制管理工具把測試代碼和產(chǎn)品構(gòu)建代碼一起管理，都作為產(chǎn)品的一部分管闷。
5. 更快的交付（Faster delivery into production）
任何一個idea越快做成軟件產(chǎn)品交付給用戶抑胎，給企業(yè)帶來的價值越大。
該原則要求我們把測試活動融入軟件開發(fā)生命周期的每個環(huán)節(jié)渐北，不要在后期進行長時間的集中測試阿逃；同時測試人員的關注點不再是發(fā)現(xiàn)更多的bug以阻止不符合質(zhì)量要求的產(chǎn)品上線，而是把目標放在如何能夠幫助團隊盡快的讓產(chǎn)品上線赃蛛，讓企業(yè)投資回報更早恃锉，也就是更快的賺錢。
推薦實踐：自動化構(gòu)建流水線破托、關注平均恢復時間、發(fā)布與部署解耦等歧蒋。
6. 清晰一致的測試視圖（Clear and consistent view of testing）
可視化的報告給客戶和內(nèi)部團隊展示測試的狀態(tài)和產(chǎn)品內(nèi)外部的質(zhì)量，對項目的質(zhì)量和風險把控是非常有幫助的谜洽。不同項目各自采用五花八門的圖表樣式，將不利于項目間的信息共享和比較阐虚，無端增加復雜性序臂，帶來浪費。
因此实束，我們需要把狀態(tài)報告做的盡可能簡單奥秆、清晰逊彭，并且保持跨項目的指標一致性；同時构订，我們不應該為了讓某個指標變得好看而改變我們的行為侮叮，整個報告要誠實開放，這樣才能真實反映出項目的狀況悼瘾。
7. 優(yōu)化業(yè)務價值（Optimize business value）
開發(fā)軟件無疑是要給客戶的業(yè)務帶來價值签赃，軟件測試也需要為這個目標服務，測試要跟業(yè)務價值保持一致分尸，幫助客戶優(yōu)化業(yè)務價值锦聊。要求做到：
- 測試不僅是保險，不僅是保證軟件質(zhì)量的箩绍；
- 要有目的的關注變化的特性孔庭，不要盲目的散彈槍式的對任何特性進行測試，要有優(yōu)先級材蛛；
- 要能幫助企業(yè)驅(qū)動新的特性和功能圆到；
- 幫助客戶創(chuàng)造安全的嘗試新點子的環(huán)境，提供快速的反饋卑吭。
推薦實踐：
- 基于風險的測試芽淡，根據(jù)業(yè)務優(yōu)先級需要調(diào)整測試策略，在測試過程中盡可能規(guī)避給業(yè)務帶來的風險豆赏；
- 生產(chǎn)環(huán)境下的QA挣菲，通過收集生產(chǎn)環(huán)境的真實用戶行為和應用使用數(shù)據(jù)，對業(yè)務的優(yōu)化做出貢獻掷邦。
評估模型以及在項目中的應用
評估模型就是將上述七條原則的每一條細化白胀，列出該原則對應的實踐和行為，并給每個實踐或行為設定0-5分的不同評分標準抚岗，最后統(tǒng)計各個原則的總分或杠，形成類似下圖的結(jié)果報告：
在項目中的應用
以Cristan分享的模型為基礎，由Tech Lead和幾個DEV宣蔚、QA成立一個評估小組向抢。
第一步：分別根據(jù)各自的理解給項目打分，結(jié)果是很有意思的胚委，請看下圖：
根據(jù)這些結(jié)果挟鸠，可以看出大家的認識是不太一致的。
第二步：評估小組對模型中的每條細節(jié)進行review篷扩，做適當修改以更符合項目情況兄猩，并且在評估小組內(nèi)大家達成共識。其中鉴未，所做的修改包括修改原有的實踐評分指標、增加新的更適合項目和當前技術(shù)趨勢的實踐淹真、刪除過時的或者不符合項目特點的實踐连茧。
第三步：根據(jù)更新過后的模型指標對項目上的一個Team做評估試點，詳細分析該team對應到測試原則各個維度的well和less well部分啸驯，由評估小組成員一起打分，得到該team的評估結(jié)果圖徙鱼。
第四步：根據(jù)評估結(jié)果并結(jié)合項目目標排定需要改進的優(yōu)先級针姿，制定出改進action，并更新給試點team執(zhí)行距淫。
后續(xù)：試點一個周期后再次評估，并重新review評估模型蓬衡，再推行到整個項目彤枢。同時，周期性的進行新的評估和制定新的action家肯，以做到持續(xù)的改進和優(yōu)化盟猖。
總結(jié)
應用程序的質(zhì)量、測試的快速性反镇、以及上線后輕松自信的更新服務的能力娘汞，是幫助企業(yè)業(yè)務價值最大化的關鍵因素之一，一直是我們所追求的惊豺。
基于測試原則的評估模型，可以幫助我們在追求這個目標的道路上少走彎路揩页，幫助我們持續(xù)的改進烹俗，以驅(qū)動出更加卓越的軟件。
