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

專業(yè)領(lǐng)域包括網(wǎng)站建設(shè)、成都做網(wǎng)站、商城建設(shè)、微信營銷、系統(tǒng)平臺開發(fā)， 與其他網(wǎng)站設(shè)計及系統(tǒng)開發(fā)公司不同，創(chuàng)新互聯(lián)建站的整合解決方案結(jié)合了幫做網(wǎng)絡(luò)品牌建設(shè)經(jīng)驗和互聯(lián)網(wǎng)整合營銷的理念，并將策略和執(zhí)行緊密結(jié)合，為客戶提供全網(wǎng)互聯(lián)網(wǎng)整合方案。

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

但是自動化測試是否足夠、有效，即使足夠、有效，就能說明產(chǎn)品質(zhì)量好嗎？測試結(jié)果只是一個指標(biāo)，這個指標(biāo)代表的只是在當(dāng)前的測試環(huán)境下，現(xiàn)有測試實例的運行結(jié)果，是我們保證質(zhì)量的下限。

軟件質(zhì)量不是測試出來的，而是在開發(fā)過程中建立起來的?？刂崎_發(fā)過程中的質(zhì)量有助于提高產(chǎn)品的質(zhì)量上限。

Shift Left Testing，通俗理解就是把位于傳統(tǒng)軟件開發(fā)流程中最后階段的測試往前提。提到哪一步呢？開發(fā)？設(shè)計？需求？我個人的理解是越往前越好。這意味著在整個開發(fā)周期內(nèi)需要持續(xù)測試，持續(xù)關(guān)注質(zhì)量，這一切都是為了提高質(zhì)量的上限。

這會帶來什么好處呢？

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

在軟件開發(fā)的整個過程中，越早發(fā)現(xiàn)問題，修復(fù)的成本越小。

試想在所謂的集成測試階段發(fā)現(xiàn)一個bug，花時間部署測試環(huán)境，準(zhǔn)備測試數(shù)據(jù)，執(zhí)行測試，重現(xiàn)bug，跟開發(fā)人員溝通，將bug分配給開發(fā)人員后，他/她們可能需要重新部署開發(fā)環(huán)境，重新開發(fā)，重新做代碼審查，最后再走一遍測試流程。如果能在代碼審查或者單元測試階段發(fā)現(xiàn)這個bug，得節(jié)省多少時間？

2. 提高測試效率

如果能在需求，設(shè)計階段能發(fā)現(xiàn)并阻止bug，可以節(jié)約很多開發(fā)生命周期的反復(fù)，同時在理解需求、代碼的基礎(chǔ)上進行測試，可以更有重點和針對性地面向業(yè)務(wù)和風(fēng)險測試，而不會陷入測試細(xì)節(jié)，有效提高測試效率。

3. 提高質(zhì)量

在需求層面保證并優(yōu)化需求以及需求傳遞的質(zhì)量，在代碼層面保證設(shè)計的靈活性，代碼的整潔性， 在開發(fā)過程中控制質(zhì)量，提高產(chǎn)品內(nèi)部質(zhì)量。

Shift Left Testing是需要整個敏捷開發(fā)團隊作為一個整體去遵循的。那么在一個敏捷開發(fā)團隊中，作為一位QE，在整個產(chǎn)品的開發(fā)生命周期中需要怎么和團隊合作呢？

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

QE要能做到?jīng)]有界限地提供質(zhì)量保證，需要自身做出兩個重要的改變：

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

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

(2) 深入到軟件開發(fā)生命周期的各個環(huán)節(jié)，緊跟團隊的開發(fā)節(jié)奏

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

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

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

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

QE的成就感不在于“我有多么重要，測出了多少重要的bug”，而是“沒有我，團隊的產(chǎn)出仍然是高質(zhì)量的”。要達到這個目標(biāo)，QE的任務(wù)就是挖掘團隊的質(zhì)量需求，培訓(xùn)團隊，讓QE變得越來越“多余”，使團隊成為一支“去QE化”的敏捷團隊。

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

那么質(zhì)量是不是越高越好呢？質(zhì)量是要付出代價的，需要控制成本和產(chǎn)出。舉個溫伯格提到的例子，MiniCozy公司的文字處理軟件，在對一整本書進行排版時，會出現(xiàn)漏詞的錯誤，而這個錯誤確實發(fā)生在一個作家的處女作上。但是MiniCozy公司的回應(yīng)是，在數(shù)以十萬計的用戶中，或許都找不到十個人會把這樣大規(guī)模的任務(wù)用單獨的一個文件來組織，修正這個錯誤可能會花很多時間和成本，并且還有可能引發(fā)更大的錯誤，從而影響到幾百甚至是幾千位用戶。MiniCozy認(rèn)為他們的取舍是正確的。所以質(zhì)量不是指毫無紕漏，而是有其相對性。

下面我列出了在軟件開發(fā)生命周期的各個環(huán)節(jié)里，QE能夠做的事情，但是QE不是一定需要參與，參與的目的是為了發(fā)現(xiàn)問題，最終是需要培訓(xùn)使得團隊能夠具備質(zhì)量和測試相關(guān)的知識和思維，通過改進流程，行為讓團隊自己保證質(zhì)量，并不斷改進。

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

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

Before coding - 開發(fā)開始前

1. Involve requirement discussion early

在做產(chǎn)品開發(fā)前，我們應(yīng)該理解需求背后的原因，客戶遇到什么問題，我們能夠幫客戶解決什么問題。我們測試的不僅僅是產(chǎn)品功能，更是業(yè)務(wù)價值。提前參與需求的討論對決定測試的重心，優(yōu)先級都有極大的幫助，避免陷入辛苦的測試細(xì)節(jié)中。這樣我們就可以有效的利用Pareto的20/80原則，提高測試效率。

2. Ask negative questions

每個人都可能受慣性思維影響，我們可以通過問負(fù)向問題來優(yōu)化功能性需求和非功能性需求的測試, 比如產(chǎn)品標(biāo)準(zhǔn)和GDPR(General Data Protection Regulation)等。

3. Collaborate with testable and executable acceptance criteria

Acceptance criteria主要關(guān)注的是業(yè)務(wù)價值，建立user story的功能范圍，并能指導(dǎo)開發(fā)。通過各個角色合作討論的方式列出acceptance criteria，能夠避免對需求范圍的誤解，同時參與的每個人都能很清楚的知道要測什么，要怎么測。

4. Work out test plan in sprint

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

5. Join estimation proactively

在sprint planning meeting中，基于制定的測試計劃，積極參與對任務(wù)的分解和時間估算，包含相關(guān)測試的開發(fā)、維護和執(zhí)行時間。

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

這些實際是傳統(tǒng)的瀑布開發(fā)模式需要的測試相關(guān)的專業(yè)知識，同樣也適用于敏捷開發(fā)模式。通過各種方法論的使用，設(shè)計出測試點，來指導(dǎo)、優(yōu)化測試執(zhí)行，提高測試效率。在敏捷開發(fā)模式下，QE需要讓所有成員都具備這種測試設(shè)計技能。

7. Define KPI/Dashboard

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

During coding - 開發(fā)過程中

1. Join or familiar with design

雖然敏捷開發(fā)模式并不像瀑布開發(fā)模式那樣具有專門的軟件設(shè)計階段，但是小的功能點設(shè)計在每個sprint確實存在。不同的設(shè)計有不同的測試考慮，比如通過事件來觸發(fā)訂單流程，或是通過后臺作業(yè)來觸發(fā)訂單流程，測試要驗證的點肯定是不一樣的。如果采取后臺作業(yè)方式，還需要驗證作業(yè)信息和計劃的執(zhí)行時間是否正確等等。

同時我們需要在設(shè)計時考慮可測試性。軟件的可測試性是指軟件發(fā)現(xiàn)故障并隔離、定位其故障的能力特性，以及在一定的時間和成本前提下，進行測試設(shè)計、測試執(zhí)行的能力。James Bach 這樣描述可測試性：軟件可測試性就是一個計算機程序能夠被測試的容易程度。

比如，為了測試一個類的方法，首先我們需要創(chuàng)建這個類的實例，需要引用必須的內(nèi)部依賴，同時還要隔離外部依賴。有的場景下做到這些并不是那么簡單，由于開發(fā)人員容易局限于考慮自己負(fù)責(zé)的功能的具體技術(shù)實現(xiàn)而忽略了設(shè)計的可測試性，而QE參與功能設(shè)計則可以提高開發(fā)人員對確保其設(shè)計的可測試性的意識。

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

可測試的代碼是寫測試代碼的前提條件。測試代碼的作用絕不僅僅是用來滿足測試覆蓋率的，測試代碼需要基于測試設(shè)計和測試數(shù)據(jù)來測試軟件的功能，所以需要QE能和開發(fā)人員一起保證測試代碼的有效性。一旦發(fā)現(xiàn)bug，除了修復(fù)bug本身，還需要評估是否需要改進現(xiàn)有的測試代碼來覆蓋這個bug。

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

以QE的角度檢查代碼，比如需求是否匹配，是否考慮了SAP產(chǎn)品標(biāo)準(zhǔn)等等，從這個角度檢查既有助于發(fā)現(xiàn)問題，同時可以提高測試效率。比如，代碼添加了新方法來獲取當(dāng)前時間，時間和格式是否做了本地化處理？這個新方法是否被調(diào)用了？如果都沒有符合，那還需要繼續(xù)功能測試嗎？在這些缺陷彌補之前，當(dāng)然沒有必要進行功能測試了。后面我們還會追溯為什么會有這種情況發(fā)生。

4. Safeguard DoD compliance

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

5. Utilize continuous integration environments

通過集成各種代碼掃描工具，利用持續(xù)集成來發(fā)現(xiàn)問題，提供質(zhì)量的快速反饋。

6. Test an uncompleted user story

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

7. Provide fast feedback

除了持續(xù)集成之外，QE需要對開發(fā)的bug提供及時快速的反饋，因為開發(fā)人員熟悉業(yè)務(wù)和代碼，能夠比較快速地解決問題。另一方面這也可以作為考慮如何提高質(zhì)量的on-job培訓(xùn)的一部分。

After coding - 開發(fā)結(jié)束后

1. Test user story based on business value and risk

在團隊還不夠成熟的情況下，QE還需要基于業(yè)務(wù)價值和風(fēng)險來測試user story，測試的粒度和范圍可以根據(jù)團隊的具體情況進行調(diào)整。

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

基于user story的KPI，重要性和風(fēng)險程度，我們需要決定是否再需要一輪測試。

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

QE發(fā)現(xiàn)了bug，報告給開發(fā)后，QE的任務(wù)就完成了嗎？QE可以通過現(xiàn)象，日志等分析問題，定位問題，提高問題的解決效率。

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

看完上述內(nèi)容，你們掌握Shift Left Testing和軟件質(zhì)量保證的思考是怎樣的的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！

當(dāng)前標(biāo)題：ShiftLeftTesting和軟件質(zhì)量保證的思考是怎樣的
標(biāo)題來源：http://jinyejixie.com/article24/gcecje.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供動態(tài)網(wǎng)站、面包屑導(dǎo)航、網(wǎng)站制作、靜態(tài)網(wǎng)站、網(wǎng)站導(dǎo)航、響應(yīng)式網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)