摘要:在軟件測試活動中,作為一名測試人員有沒有遇到過這樣的場景,在測試一個特性或者制定一份測試方案時,往往會想著進行簡單測試做簡單設計,認為這個場景出現(xiàn)的概率太低,幾乎不可能會存在,不測了實際應用時不可能會有這么大的用戶量,
在軟件測試活動中,作為一名測試人員有沒有遇到過這樣的場景,在測試一個特性或者制定一份測試方案時,往往會想著進行簡單測試、做簡單設計,認為
1、這個場景出現(xiàn)的概率太低,幾乎不可能會存在,不測了
2、實際應用時不可能會有這么大的用戶量,不用考慮
3、在這個時間段應該不可能會有這么大的業(yè)務量
4、同一時刻不可能會存在多種業(yè)務并發(fā)上來
但版本發(fā)布上線后,實際應用時之前認為的那些小概率事項,結果確往往就是會出現(xiàn),這是為什么呢?管理學中有一個定律——墨菲定律;這個定律指出,當事情有變壞的可能,不管可能性有多小,他總是會發(fā)生;
在具體的研發(fā)測試中,當測試過程、測試交付存在潛在風險導致出現(xiàn)不好的結果時,我們需要如何做好全方位的準備?積極的應對,避免不好事情造成的影響或把影響降到最低;結合當前項目運作,分享下當前項目過程中對于測試風險控制的實踐過程。
在項目活動中風險是指項目活動過程中的一種不確定的事件或條件,一旦發(fā)生會對具體的項目的單個或者多個目標產(chǎn)生影響,例如:
· 研發(fā)過程中,特性需求臨時變更,代碼修改,但測試時間不足,存在質(zhì)量風險
· 版本交付,存在外部依賴不滿足,交付受阻;
· 版本測試,測試工作量估算不合理,測試不充分
這些交付過程中存在的動態(tài)的、靜態(tài)的、已知的、未知的不確定性因素影響測試交付目標,無法滿足外部市場需要;那如何做呢?
在項目的測試活動過程中,我們通過一系列風險控制活動對不確定因素進行及時識別、有效評估、積極應對,以保證項目測試活動的正常進行,從而達到價值交付;
在風險識別階段通過樹立團隊整體的風險意識,大家一起討論制定風險識別維度、在對應的研發(fā)階段、利用一定的工具方法進行風險數(shù)據(jù)收集,從而進行有效識別。
根據(jù)項目的實際運作團隊討論,通過收集如下四個維度的信息作為風險識別的輸入,來進行識別
項目:項目的維度主要考慮:
·項目規(guī)劃需求的計劃:在項目迭代開始初期,規(guī)劃的需求內(nèi)容、提交的計劃點;如果在過程中發(fā)生需求加塞、提交計劃變更和一開始的計劃出現(xiàn)偏差,則作為風險進行及時上報;
·相關的制約因素:是否存在對外部依賴,比如對外圍的軟硬件版本存在依賴,需要提供后,集成完成才能滿足交付條件;
·里程碑時間點:時間點要求也是一個識別依據(jù),臨近里程碑時間點,現(xiàn)狀和目標存在較大偏差;
·工作量的估算;工作量估算的合理性,有些是項目強行壓下的,存在較大的工作量偏差;
·以及隱形因素項目內(nèi)各團隊之間的合作協(xié)作關系
資源:資源的維度主要考慮人力資源是否充分,設備環(huán)境資源是否能滿足相應的測試活動;比如組網(wǎng)場景、容量上對資源的要求,是否具備;
技術:技術的維度主要考慮當前是否存在新領域不熟悉、所需的技能存在盲區(qū)。
質(zhì)量:質(zhì)量維度主要是要了解確認對任務質(zhì)量的要求,是僅滿足預研穿刺基本測試,還是需要按交付標準的DOD嚴格執(zhí)行,以達到交付要求;
風險識別活動貫穿在整個測試活動的始終,從測試SE參與需求分析開始、編寫測試策略、跟蹤特性實現(xiàn)過程、交付系統(tǒng)測試以及其他(維護)各階段都需要識別;
·專家判斷:了解項目和業(yè)務各領域的人員,考慮單個風險的方方面面,以及整體項目風險的各來源;
·頭腦風暴:參考一定的風險識別維度,進行相關的腦暴;
·訪談:對領域專家、資深參與者訪談;
·會議討論:團隊成員對當前所承接的任務,觀察了解到的信息進行專門的會議討論,審查識別的風險;
·風險檢查單:各階段的風險點,用作提醒(堅持單及時審查,定期更新調(diào)整)
風險識別經(jīng)驗小結:
1、團隊樹立風險意識,鼓勵所有人相關人員參與風險識別
2、除了顯性可見風險,同時也要注意隱性的團隊協(xié)作,氛圍的風險
通過有效描述風險,明確風險類別后合理定義風險級別來評估風險,以確認風險影響以及為后續(xù)的風險應對措施提供依據(jù);
風險包含起因、時間、概率及影響四要素,在了解風險4要素后,使用結構化SQCA描述方法,把風險本身與風險愿意及風險影響區(qū)分開來,描述清楚;
S(Situation):背景起因
C(Complication):事件沖突
Q(Question):問題影響
A(Answer);答案
描述結構化方式:在某個背景(起因)之下,遇到了復雜(事件)情況,產(chǎn)生了什么樣的(問題)影響,然后我們?nèi)绾稳ソ鉀Q它(答案)
其中風險描述中風險影響和解決方案是關鍵,建議描述要領:
·Q(問題影響):描述清楚波及的范圍、問題的重要、緊迫程度
·A(解決方案):遵循3W原則,解決方案具體內(nèi)容,包含所需要的資源等(What)、具體的責任主體(Who),由誰負責解決、期望解決的具體時間點(When)
·風險描述案例:
·技術風險描述舉例:
隨著公司業(yè)務的快速發(fā)展(S),我們的IT系統(tǒng)無法滿足現(xiàn)狀產(chǎn)品的需求(C),這將導致我們無法滿足我們的客戶(Q),當務之急的應對措施是需要***立刻安排升級IT系統(tǒng)(A)
·質(zhì)量風險描述舉例:
臨近迭代交付(S),測試自動化無法穩(wěn)定運行(C),導致守護不完善,存在質(zhì)量風險影響發(fā)布(Q),當務之急***盡快在迭代交付前完成自動化執(zhí)行守護修復(A)
在有效的描述清楚風險后,進行風險分類,明確風險類別;這個過程主要是便于把注意力和精力集中到風險最大的領域,或者針對一組相關的風險制定通用的風險應對措施,從而更有效的開展應對;
·按風險來源分:技術風險、管理風險、外部風險、內(nèi)部風險等
·或者按受影響的項目工作分:方案設計、編碼實現(xiàn)、驗收測試等
目前我們項目運作過程中,風險分類主要還是以風險的來源來分,根據(jù)分類出的風險,發(fā)現(xiàn)外部依賴類風險占據(jù)比例較高,針對此類風險討論通用的應對措施,比如通過一開始的協(xié)作規(guī)劃項目計劃來約束、過程中每日的日報、周報來跟蹤外部依賴提供的進展等
在描述清楚風險、做好分類后,團隊根據(jù)具體的研發(fā)過程,對風險偏好和風險臨界討論制定風險影響和概率的定義,從而進行風險定級評估;
比如通過風險出現(xiàn)的概率情況、對測試目標的影響程度來綜合判斷風險級別。
根據(jù)定級結果,高以上風險:立即行動 ;中風險:立即關注;低風險:定期關注
在風險評估定級完成后,進行對應的風險應對;在實際的項目運作過程中根據(jù)不同的場景,采用不同的應對措施;
·風險上報:當超出個人或團隊處理的能力時,需要進行風險上報,一般風險級別為高以上類風險;比如涉及到外部依賴類風險,需要項目協(xié)調(diào),否則版本無法正常集成制作;通過面對面、電話溝通、或者日報周報的方式上報反饋;
·風險規(guī)避:發(fā)生的概率較高,具有嚴重負面影響的高優(yōu)先級風險;比如在臨近版本發(fā)布時,某些特性由于測試不充分,波及不明確,合入后存在對現(xiàn)有商用版本存在未知隱患,通過裁剪、調(diào)整特性合入周期來規(guī)避版本發(fā)布質(zhì)量風險;
·風險轉移:應對風險,把責任外包給第三方;比如在研發(fā)過程中,對于新領域不熟悉,但第三方存在成熟的技術,可以通過購買服務、簽約合同;和第三方達成合作,把風險轉移第三方;
·風險減輕:降低風險出現(xiàn)的概率和影響;比如在臨近版本發(fā)布時,合入了故障,但該故障的波及范圍交廣,測試又不充分;經(jīng)過分析故障影響,回退合入故障,來規(guī)避影響;
·風險接受:對于低優(yōu)先級的風險或者其他任何策略已無法加以應對;
最后的話:
1、測試過程中,當好測試“操盤手”,綜合進行風險控制,做好全方位準備,積極應對,避免或降低壞事出現(xiàn)后造成的影響;
2、加強團隊風險意識,風險管理控制需要全員參與
3、作為一名優(yōu)秀的測試人員養(yǎng)成風險數(shù)據(jù)收集、整理、分析習慣;
4、善于總結經(jīng)驗,練就一副識別風險的“火眼金睛”
5、作為測試人員,要“未雨綢繆”,從源頭控風險,不要當“救火隊員”
以上筆者的經(jīng)歷更像一張橫向的知識網(wǎng),創(chuàng)建了一個交流平臺 914172719 ,群內(nèi)有各種技術同行交流、學習資料、面試經(jīng)驗等。其中用到jenkins、docker、moutebank、python編程等,還需要花更多的精力去深入學習,當每項技能都能掌握到一定深度,才能稱為一個完整的知識體系。
最后: 可以關注公眾號:傷心的辣條 ! 進去有許多資料共享!資料都是面試時面試官必問的知識點,也包括了很多測試行業(yè)常見知識,其中包括了有基礎知識、Linux必備、Shell、互聯(lián)網(wǎng)程序原理、Mysql數(shù)據(jù)庫、抓包工具專題、接口測試工具、測試進階-Python編程、Web自動化測試、APP自動化測試、接口自動化測試、測試高級持續(xù)集成、測試架構開發(fā)測試框架、性能測試、安全測試等。
如果我的博客對你有幫助、如果你喜歡我的博客內(nèi)容,請 “點贊” “評論” “收藏” 一鍵三連哦!
轉行面試,跳槽面試,軟件測試人員都必須知道的這幾種面試技巧!
面試經(jīng):一線城市搬磚!又面軟件測試崗,5000就知足了…
文章版權歸作者所有,未經(jīng)允許請勿轉載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉載請注明本文地址:http://systransis.cn/yun/119350.html
摘要:測試驅動開發(fā)簡稱,是一種軟件開發(fā)過程中的應用方法,,由極限編程中倡導,以其倡導先寫測試程序,然后編碼實現(xiàn)其功能得名。測試驅動著整個開發(fā)過程首先,驅動代碼的設計和功能的實現(xiàn)其后,驅動代碼的再設計和重構。 showImg(https://segmentfault.com/img/remote/1460000017081716); 前言 一直都有聽到 TDD 測試驅動開發(fā)的開發(fā)方式,之前看...
摘要:對于專業(yè)的開發(fā)者來說,單元測試是一項必備的技能,多數(shù)的程序員卻不具備測試驅動開發(fā)的能力。對于工程來說,開源項目基本都嚴格遵守執(zhí)行單元測試,而很多商業(yè)的工程則在單元測試方面有所缺失。一個擁有單元測試的項目會變得更加容易維護和更改。 作為一名合格的Java程序員,日常工作除了上班擼代碼就是加班擼代碼。擼碼其實不難,無非詢問Google,StackOverflow,解決方法和demo一籮...
摘要:番茄工作法簡約而不簡單,本書亦然。在番茄工作法一個個短短的分鐘內(nèi),你收獲的不僅僅是效率,還會有意想不到的成就感。 @author ASCE1885的 Github 簡書 微博 CSDN 知乎本文由于潛在的商業(yè)目的,不開放全文轉載許可,謝謝! showImg(/img/remote/1460000007319503?w=728&h=792); 廣而告之時間:我的新書《Android 高...
閱讀 2721·2023-04-26 02:02
閱讀 2588·2023-04-25 20:38
閱讀 4122·2021-09-26 09:47
閱讀 3109·2021-09-10 10:50
閱讀 3774·2021-09-07 09:58
閱讀 3336·2019-08-30 15:54
閱讀 2703·2019-08-30 15:54
閱讀 1924·2019-08-29 17:03