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

時間 2019-11-19

標籤 sap 研究院 shift left testing 軟件質量保證一些思考欄目 SQL 简体版

原文原文鏈接

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

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

Jerry印象最深的一件事是，當時我負責實現一個company profile的功能，即客戶能夠從一個下拉列表裏選擇一個企業，從而進入該企業明細頁面，顯示該企業的概述，包含文字簡介，企業人數，財政收入等等。概述信息經過消費wikipedia提供的Restful API，傳入企業名稱，返回響應，其中須要顯示在明細頁面裏的關鍵信息得經過編程人員本身寫正則表達式提取出來。安全

Jerry當時的想法是，把iOS版本里解析正則表達式的Object C代碼直接改爲Java代碼，由於不一樣編程語言裏使用的正則表達式，其語法雖然稍有差別，但語意是相同的。但當我閱讀了一段時間iOS代碼那些操做正則表達式的Object C代碼後，已經頭昏腦脹了，個人Java代碼寫好後進行測試，發現並不能保證對全部測試輸入的company, 都可以用正則表達式正確地解析出關鍵信息。session

而後Jerry說，算了，我不參考iOS代碼，我直接本身從頭寫吧。寫完後測試，發現仍然不能保證對於全部的測試數據都能正常工做。架構

看到Jerry陷入進退兩難的境地後，曉霞同窗像女神通常出如今我面前，說：「我來試試」。一個下午過去，曉霞同窗提交了一段代碼到perforce上，那是一段結構清晰，而且可以完美使用正則表達式完成關鍵信息解析的Java代碼。我使用了一百多個company進行測試，所有工做正常。實際上，直到最後發版，曉霞同窗這段代碼也沒有發現任何bug。編程語言

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

這件事讓Jerry今後對曉霞同窗另眼相看，一直到如今。工具

下面是曉霞同窗的正文。性能

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

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

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

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

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

這會帶來什麼好處呢？

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

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

試想在所謂的集成測試階段發現一個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技能的高低，事情可能會有所不一樣。

爲了圖表的簡化，只列出了事情自己，下面會有簡單說明作這些事情的目的。

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能夠作得更好？

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