ShiftLeftTesting和軟件質(zhì)量保證的思考是怎樣的-創(chuàng)新互聯(lián)

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

創(chuàng)新互聯(lián)堅持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：網(wǎng)站設(shè)計制作、成都網(wǎng)站設(shè)計、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時代的寧海網(wǎng)站設(shè)計、移動媒體設(shè)計的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！

在敏捷開發(fā)模式下，團(tuán)隊需要有持續(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ǔ)上進(jìn)行測試，可以更有重點和針對性地面向業(yè)務(wù)和風(fēng)險測試，而不會陷入測試細(xì)節(jié)，有效提高測試效率。

3. 提高質(zhì)量

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

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

1. QE作為敏捷開發(fā)團(tuán)隊的一員，可以做任何能幫助團(tuán)隊提高質(zhì)量的事情， 沒有界限，目的是為了幫助團(tuán)隊發(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é)，緊跟團(tuán)隊的開發(fā)節(jié)奏

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

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

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

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

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

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

那么質(zhì)量是不是越高越好呢？質(zhì)量是要付出代價的，需要控制成本和產(chǎn)出。舉個溫伯格提到的例子，MiniCozy公司的文字處理軟件，在對一整本書進(jìn)行排版時，會出現(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)使得團(tuán)隊能夠具備質(zhì)量和測試相關(guān)的知識和思維，通過改進(jìn)流程，行為讓團(tuán)隊自己保證質(zhì)量，并不斷改進(jìn)。

根據(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)制定測試計劃，包括哪些功能需要手動測試，哪些功能需要自動測試，哪些功能需要回歸測試，是否需要做性能測試/安全測試等。同時還需要計劃對之前的測試做維護(hù)。這個測試計劃會影響到sprint planning meeting對任務(wù)的分解和時間估算。

5. Join estimation proactively

在sprint planning meeting中，基于制定的測試計劃，積極參與對任務(wù)的分解和時間估算，包含相關(guān)測試的開發(fā)、維護(hù)和執(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

團(tuán)隊需要定義如何來度量質(zhì)量，KPI(Key Performance Indicator, 關(guān)鍵績效指標(biāo))的度量值能直接反饋出團(tuán)隊的外部質(zhì)量，并可以通過根源分析幫助團(tuán)隊認(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)故障并隔離、定位其故障的能力特性，以及在一定的時間和成本前提下，進(jì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本身，還需要評估是否需要改進(jìn)現(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)然沒有必要進(jìn)行功能測試了。后面我們還會追溯為什么會有這種情況發(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不會太大也不會太小，在團(tuán)隊還不夠成熟的時候，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

在團(tuán)隊還不夠成熟的情況下，QE還需要基于業(yè)務(wù)價值和風(fēng)險來測試user story，測試的粒度和范圍可以根據(jù)團(tuán)隊的具體情況進(jìn)行調(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)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道，感謝各位的閱讀！

分享文章：ShiftLeftTesting和軟件質(zhì)量保證的思考是怎樣的-創(chuàng)新互聯(lián)
網(wǎng)頁鏈接：http://muchs.cn/article10/ddpedo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供App開發(fā)、搜索引擎優(yōu)化、靜態(tài)網(wǎng)站、網(wǎng)站策劃、網(wǎng)站建設(shè)、自適應(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)