Shift Left Testing和軟件質量保證的思考是怎樣的

Shift Left Testing和軟件質量保證的思考是怎樣的，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

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

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

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

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

看完上述內容，你們掌握Shift Left Testing和軟件質量保證的思考是怎樣的的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！