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

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

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

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

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

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

這會(huì)帶來(lái)什么好處呢？

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

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

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

2. 提高測(cè)試效率

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

3. 提高質(zhì)量

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

為了圖表的簡(jiǎn)化，只列出了事情本身，下面會(huì)有簡(jiǎn)單說(shuō)明做這些事情的目的。

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

1. Involve requirement discussion early

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

2. Ask negative questions

每個(gè)人都可能受慣性思維影響，我們可以通過(guò)問(wèn)負(fù)向問(wèn)題來(lái)優(yōu)化功能性需求和非功能性需求的測(cè)試, 比如產(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ù)價(jià)值，建立user story的功能范圍，并能指導(dǎo)開發(fā)。通過(guò)各個(gè)角色合作討論的方式列出acceptance criteria，能夠避免對(duì)需求范圍的誤解，同時(shí)參與的每個(gè)人都能很清楚的知道要測(cè)什么，要怎么測(cè)。

4. Work out test plan in sprint

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

5. Join estimation proactively

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

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

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

7. Define KPI/Dashboard

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

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

1. Join or familiar with design

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

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

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

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

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

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

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

4. Safeguard DoD compliance

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

5. Utilize continuous integration environments

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

6. Test an uncompleted user story

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

7. Provide fast feedback

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

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

1. Test user story based on business value and risk

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

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

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

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

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

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

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