今天的文章來自Jerry的同事，曾經的搭檔鄭曉霞(Zheng Kate)。鄭曉霞是在Jerry心中是一位很有實力的程式媛，2011年從西安某軟體公司跳槽到SAP成都研究院。當時，成都研究院的CRM團隊剛剛成立，Jerry和鄭曉霞都在一個大組。

2012年夏天，我們接到任務，要把SAP Customer Briefing這款已經發布的iOS應用移植到Android平臺。因為只有1年的期限，老闆組建了一隻特殊的開發團隊，由Jerry, 鄭曉霞和另外兩位男同事組成。是的，因為需求很清楚，就是把iOS版本上的功能移植到Android平臺，所以這隻團隊沒有產品經理，沒有架構師，鄭曉霞擔任了開發人員和Scrum Master的雙重身份， UX也是專案中後期從上海找了一位同事遠端加入專案組。由於我們4位以前都沒接觸過Android開發，因此也是邊學習邊幹活。這個微型團隊的學習氣氛非常好，一個人遇到困難，其他三位都會積極熱心參與討論和提供幫助。

SAP成都研究院鄭曉霞：Shift Left Testing和軟體質量保證的一些思考

Jerry印象最深的一件事是，當時我負責實現一個company profile的功能，即客戶可以從一個下拉選單裡選擇一個企業，從而進入該企業明細頁面，顯示該企業的概述，包含文字簡介，企業人數，財政收入等等。概述資訊透過消費wikipedia提供的Restful API，傳入企業名稱，返回響應，其中需要顯示在明細頁面裡的關鍵資訊得透過程式設計人員自己寫正規表示式提取出來。

Jerry當時的想法是，把iOS版本里解析正規表示式的Object C程式碼直接改成Java程式碼，因為不同程式語言裡使用的正規表示式，其語法雖然稍有差異，但語意是相同的。但當我閱讀了一段時間iOS程式碼那些操作正規表示式的Object C程式碼後，已經頭昏腦脹了，我的Java程式碼寫好後進行測試，發現並不能保證對所有測試輸入的company, 都能夠用正規表示式正確地解析出關鍵資訊。

然後Jerry說，算了，我不參考iOS程式碼，我直接自己從頭寫吧。寫完後測試，發現仍然不能保證對於所有的測試資料都能正常工作。

看到Jerry陷入進退兩難的境地後，曉霞同學像女神一般出現在我面前，說：“我來試試”。一個下午過去，曉霞同學提交了一段程式碼到perforce上，那是一段結構清晰，並且能夠完美使用正規表示式完成關鍵資訊解析的Java程式碼。我使用了一百多個company進行測試，全部工作正常。實際上，直到最後發版，曉霞同學這段程式碼也沒有發現任何bug。

當時曉霞同學在Jerry心中的形象和這位瀟灑的警察一樣：

SAP成都研究院鄭曉霞：Shift Left Testing和軟體質量保證的一些思考

這件事讓Jerry從此對曉霞同學刮目相看，一直到現在。

下面是曉霞同學的正文。

大家好，我是鄭曉霞，現在是SAP成都研究院Hybris Enterprise Commerce Platform開發團隊的質量工程師(Quality Engineer, 下文簡稱QE)。今天我想和大家聊聊我在這個崗位上工作一段時間之後的一些心得和體會。

在敏捷開發模式下，團隊需要有持續快速的交付能力。那麼在持續交付過程中，如何保證產品質量呢？大家的答案可能是自動化測試。

但是自動化測試是否足夠、有效，即使足夠、有效，就能說明產品質量好嗎？測試結果只是一個指標，這個指標代表的只是在當前的測試環境下，現有測試例項的執行結果，是我們保證質量的下限。

軟體質量不是測試出來的，而是在開發過程中建立起來的。控制開發過程中的質量有助於提高產品的質量上限。

Shift Left Testing ，通俗理解就是把位於傳統軟體開發流程中最後階段的測試往前提。提到哪一步呢？開發？設計？需求？我個人的理解是越往前越好。這意味著在整個開發週期內需要持續測試，持續關注質量，這一切都是為了提高質量的上限。

SAP成都研究院鄭曉霞：Shift Left Testing和軟體質量保證的一些思考

這會帶來什麼好處呢？

SAP成都研究院鄭曉霞：Shift Left Testing和軟體質量保證的一些思考

1. 減少測試和開發的成本, 提高投入產出比ROI(Return On Investment)

在軟體開發的整個過程中，越早發現問題，修復的成本越小。

SAP成都研究院鄭曉霞：Shift Left Testing和軟體質量保證的一些思考

試想在所謂的整合測試階段發現一個bug，花時間部署測試環境，準備測試資料，執行測試，重現bug，跟開發人員溝通，將bug分配給開發人員後，他/她們可能需要重新部署開發環境，重新開發，重新做程式碼審查，最後再走一遍測試流程。如果能在程式碼審查或者單元測試階段發現這個bug，得節省多少時間？

2. 提高測試效率

如果能在需求，設計階段能發現並阻止bug，可以節約很多開發生命週期的反覆，同時在理解需求、程式碼的基礎上進行測試，可以更有重點和針對性地面向業務和風險測試，而不會陷入測試細節，有效提高測試效率。

3. 提高質量

在需求層面保證並最佳化需求以及需求傳遞的質量，在程式碼層面保證設計的靈活性，程式碼的整潔性，在開發過程中控制質量，提高產品內部質量。

Shift Left Testing是需要整個敏捷開發團隊作為一個整體去遵循的。那麼在一個敏捷開發團隊中，作為一位QE，在整個產品的開發生命週期中需要怎麼和團隊合作呢？

1. QE作為敏捷開發團隊的一員，可以做任何能幫助團隊提高質量的事情，沒有界限，目的是為了幫助團隊發現問題，解決問題，提高產品交付質量。

QE要能做到沒有界限地提供質量保證，需要自身做出兩個重要的改變：

(1) 全方面地提高自己的技能

如果缺乏相關的技能，比如業務能力和一定的程式碼能力，很難想象QE能夠高效地參與到各個開發環節的討論中，更談不上能給出建議和意見。當然這不意味著必須讓QE成為一名全棧工程師。QE需要去找到學習的平衡點。有些技能可能不是必須的，但是如果具備這些技能，會讓QE以更加高效的方式做事。

(2) 深入到軟體開發生命週期的各個環節，緊跟團隊的開發節奏

如果不深入到開發的各個環節，有些質量問題的根源沒法找到，那麼提前阻止bug也就無從談起。只帶著耳朵聽，是沒法深入的。需要思考，從質量的角度去思考，但是如果技能差距太大，能勉強跟上節奏也就不錯了，談不上思考。所以深入軟體開發週期各個環節需要QE自身技能的支撐。

同時，QE在參與的過程中，需要把握好平衡，能發現問題，也需要讓團隊各個角色能夠各司其責，維持健康的團隊工作模式。

2. QE需要培訓團隊，讓團隊能夠擁有測試技能和質量意識，並能夠自己解決問題，同時不斷提高質量。

產品質量由敏捷開發團隊來保證，經常聽到有同事說，”我們的QE還挺厲害的，測出了不少問題”。在一個敏捷開發團隊中，只有一個QE，靠一個人的英雄主義，測這麼多問題，如果QE休假了怎麼辦？能對團隊的質量放心？

QE的成就感不在於“ 我有多麼重要，測出了多少重要的bug ”，而是“ 沒有我，團隊的產出仍然是高質量的 ”。要達到這個目標，QE的任務就是挖掘團隊的質量需求，培訓團隊，讓QE變得越來越“多餘”，使團隊成為一支“去QE化”的敏捷團隊。

這兩點看似矛盾，實則第一點(幫助團隊發現問題)是為了有方向性地支援第二點(如何培訓團隊自己解決問題)。隨著團隊越來越成熟，這兩點也就慢慢地越做越少。

那麼質量是不是越高越好呢？質量是要付出代價的，需要控制成本和產出。舉個溫伯格提到的例子，MiniCozy公司的文書處理軟體，在對一整本書進行排版時，會出現漏詞的錯誤，而這個錯誤確實發生在一個作家的處女作上。但是MiniCozy公司的回應是，在數以十萬計的使用者中，或許都找不到十個人會把這樣大規模的任務用單獨的一個檔案來組織，修正這個錯誤可能會花很多時間和成本，並且還有可能引發更大的錯誤，從而影響到幾百甚至是幾千位使用者。MiniCozy認為他們的取捨是正確的。所以質量不是指毫無紕漏，而是有其相對性。

下面我列出了在軟體開發生命週期的各個環節裡，QE能夠做的事情，但是QE不是一定需要參與，參與的目的是為了發現問題，最終是需要培訓使得團隊能夠具備質量和測試相關的知識和思維，透過改進流程，行為讓團隊自己保證質量，並不斷改進。

根據每個組不同的成熟度和QE技能的高低，事情可能會有所不同。

為了圖表的簡化，只列出了事情本身，下面會有簡單說明做這些事情的目的。

SAP成都研究院鄭曉霞：Shift Left Testing和軟體質量保證的一些思考

Before coding - 開發開始前

1. Involve requirement discussion early

在做產品開發前，我們應該理解需求背後的原因，客戶遇到什麼問題，我們能夠幫客戶解決什麼問題。我們測試的不僅僅是產品功能，更是業務價值。提前參與需求的討論對決定測試的重心，優先順序都有極大的幫助，避免陷入辛苦的測試細節中。這樣我們就可以有效的利用Pareto的20/80原則，提高測試效率。

2. Ask negative questions

每個人都可能受慣性思維影響，我們可以透過問負向問題來最佳化功能性需求和非功能性需求的測試, 比如產品標準和GDPR(General Data Protection Regulation)等。

3. Collaborate with testable and executable acceptance criteria

Acceptance criteria主要關注的是業務價值，建立user story的功能範圍，並能指導開發。透過各個角色合作討論的方式列出acceptance criteria，能夠避免對需求範圍的誤解，同時參與的每個人都能很清楚的知道要測什麼，要怎麼測。

4. Work out test plan in sprint

在敏捷開發的每一個sprint內，我們也需要基於sprint目標制定測試計劃，包括哪些功能需要手動測試，哪些功能需要自動測試，哪些功能需要回歸測試，是否需要做效能測試/安全測試等。同時還需要計劃對之前的測試做維護。這個測試計劃會影響到sprint planning meeting對任務的分解和時間估算。

5. Join estimation proactively

在sprint planning meeting中，基於制定的測試計劃，積極參與對任務的分解和時間估算，包含相關測試的開發、維護和執行時間。

6. Design and prepare test points with good test data including automation test

這些實際是傳統的瀑布開發模式需要的測試相關的專業知識，同樣也適用於敏捷開發模式。透過各種方法論的使用，設計出測試點，來指導、最佳化測試執行，提高測試效率。在敏捷開發模式下，QE需要讓所有成員都具備這種測試設計技能。

7. Define KPI/Dashboard

團隊需要定義如何來度量質量，KPI(Key Performance Indicator, 關鍵績效指標)的度量值能直接反饋出團隊的外部質量，並可以透過根源分析幫助團隊認識問題，解決問題。

During coding - 開發過程中

1. Join or familiar with design

雖然敏捷開發模式並不像瀑布開發模式那樣具有專門的軟體設計階段，但是小的功能點設計在每個sprint確實存在。不同的設計有不同的測試考慮，比如透過事件來觸發訂單流程，或是透過後臺作業來觸發訂單流程，測試要驗證的點肯定是不一樣的。如果採取後臺作業方式，還需要驗證作業資訊和計劃的執行時間是否正確等等。

同時我們需要在設計時考慮可測試性。軟體的可測試性是指軟體發現故障並隔離、定位其故障的能力特性，以及在一定的時間和成本前提下，進行測試設計、測試執行的能力。James Bach 這樣描述可測試性：軟體可測試性就是一個計算機程式能夠被測試的容易程度。

比如，為了測試一個類的方法，首先我們需要建立這個類的例項，需要引用必須的內部依賴，同時還要隔離外部依賴。有的場景下做到這些並不是那麼簡單，由於開發人員容易侷限於考慮自己負責的功能的具體技術實現而忽略了設計的可測試性，而QE參與功能設計則可以提高開發人員對確保其設計的可測試性的意識。

2. Guide/coach/pair to develop testable code and effective test code

可測試的程式碼是寫測試程式碼的前提條件。測試程式碼的作用絕不僅僅是用來滿足測試覆蓋率的，測試程式碼需要基於測試設計和測試資料來測試軟體的功能，所以需要QE能和開發人員一起保證測試程式碼的有效性。一旦發現bug，除了修復bug本身，還需要評估是否需要改進現有的測試程式碼來覆蓋這個bug。

3. Go through code for both functional code and testing code

以QE的角度檢查程式碼，比如需求是否匹配，是否考慮了SAP產品標準等等，從這個角度檢查既有助於發現問題，同時可以提高測試效率。比如，程式碼新增了新方法來獲取當前時間，時間和格式是否做了本地化處理？這個新方法是否被呼叫了？如果都沒有符合，那還需要繼續功能測試嗎？在這些缺陷彌補之前，當然沒有必要進行功能測試了。後面我們還會追溯為什麼會有這種情況發生。

4. Safeguard DoD compliance

因為我們是做產品，只有滿足了DoD(Definition of Done, 完成的定義，敏捷開發裡的一個術語，表示工作是否完成)，user story才能算完成。我們必須要嚴格遵循，這樣才能持續交付，並且避免技術債務。

5. Utilize continuous integration environments

透過整合各種程式碼掃描工具，利用持續整合來發現問題，提供質量的快速反饋。

6. Test an uncompleted user story

通常一個user story不會太大也不會太小，在團隊還不夠成熟的時候，QE還是需要測試user story。為了不在sprint末期出現測試的“驚喜”和大量測試任務的湧現，我們可以和開發商量，討論出哪部分功能可以先開發。等這部分功能開發結束後就可以開始測試，即使這個user story還沒有完成。

7. Provide fast feedback

除了持續整合之外，QE需要對開發的bug提供及時快速的反饋，因為開發人員熟悉業務和程式碼，能夠比較快速地解決問題。另一方面這也可以作為考慮如何提高質量的on-job培訓的一部分。

After coding - 開發結束後

1. Test user story based on business value and risk

在團隊還不夠成熟的情況下，QE還需要基於業務價值和風險來測試user story，測試的粒度和範圍可以根據團隊的具體情況進行調整。

2. Hold another bug hunt or other manual exploratory testing session

基於user story的KPI，重要性和風險程度，我們需要決定是否再需要一輪測試。

3. As problem solver to analyze issue and find how to resolve issue

QE發現了bug，報告給開發後，QE的任務就完成了嗎？QE可以透過現象，日誌等分析問題，定位問題，提高問題的解決效率。

4. Reflect AC/DoD/Test plan/test case/test data

回顧之前做的一切和測試相關的活動，從中總結經驗教訓，做到持續改進。比如上個sprint的test plan實際執行情況如何？設計的test case覆蓋到了所有場景嗎？準備的測試資料質量如何？測試活動中有哪些方面下個sprint可以做得更好？

以上僅僅是個人觀點，歡迎共同探討學習。

下面是我在思考自己作為一個QE在團隊中定位過程中參考的一些網站和部落格。

SAP成都研究院鄭曉霞：Shift Left Testing和軟體質量保證的一些思考

相關文章