運用 checklist 左移 思想有哪些好處?

2022-10-08 21:12:24 字數 1794 閱讀 1504

相信很多人都知道「測試左移」和「測試右移」這兩個詞,測試左移和右移指的是測試人員的關注重心在整個產品開發過程中的階段,如果比較關注測試階段之前的階段,比如需求評審和技術評審,那就稱之為測試左移,反之,如果比較關注測試階段之後的階段,比如上線驗收,線上監控等,那就稱之為測試右移。

如果你以為我要介紹這兩個概念,那你可就猜錯了。今天介紹的 checklist 左移(測試用例左移)是我自己定義的乙個概念。指的是把對 checklist 的思考前移到寫 checklist 階段之前,比如需求評審或者技術評審,這種方式我把它稱之為 「checklist 左移」或者「測試用例左移」。下面是這個新概念的詳細介紹:

用設計 checklist (測試用例)的眼光看待和思考需求評審會內容、技術評審會內容、ui 評審會等會議內容。一邊理解需求和理解實現方案,一邊思考當前正在被講解的需求點該怎麼測試,該設計哪些測試用例,測試資料怎麼來,需要把測試資料放到**去,有哪些驗證點,這些驗證點預期狀態應該是怎樣的,會產生和驗證哪些連帶影響。就假設你現在如果要開始測試,你會怎麼測,測試哪些case,這些case應該有怎麼樣的效果,目前的需求設計是否考慮的了這種情況的處理,是否考慮到了連帶影響的處理,測試資料可以從哪找,需要什麼樣的測試資料,什麼樣的測試環境等等。如果你發現有 case 在需求設計或者技術方案中沒有考慮到,或者解釋不清晰,那麼這個時候就可以開始提問了,你的 show time 開始了。

我把這種把思考 case 或者 checklist 前移到需求評審或者技術評審的方式叫 「checklist 左移」或者「測試用例左移」。

這也是 checklist 左移思想最重要的作用。「測試用例左移」可以帶動我們的思考,培養我們的思考習慣,引導和促進我們提問,慢慢的我們思考問題時就會越來越全面,一定程度上提公升自己的職能專業性,從而得到他人的認可。會議上如果僅僅是理解內容,不發出任何提問,這樣很容易會走神。提問是非常重要的,我在 「為什麼提倡會議上要多提問」 文章中詳細分析介紹了提問的好處。

有的時候,比如會議結束時,主持人問大家有啥想問的嗎?我們可能感覺確實得問點什麼,但是又感覺無處下手,找不到可問的點,最終只能選擇沉默不語。那麼運用「測試用例左移」的方式可以給你提供一種引導你思考和尋找問題的方式。

運用checklist 左移的方法可以讓你在開會的時候有很多問題,因為任何乙個設計點都可以從測試資料、測試用例、測試環境、驗證點、驗證點影響的驗證等方面和角度著眼思考,任何乙個部分不明白、有疑惑都可以提問。你會發現真的有很多可以問的點,這樣不會有那種需求評審或者技術評審會開完了,感覺自己沒有任何問題,但是又感覺自己對需求或者技術方案不是特別理解,懵懵懂懂的感覺。有這種感覺的原因就是因為我們沒有在會議上把我們想弄明白的點弄明白。如果運用了 checklist 左移的思想,可以極大減少這種感覺,也可以極大減少那種覺得自己需求評審聽明白了但是不知道怎麼開始測的情況的發生。

因為我們連每個需求點的測試方案都初步想好了,那需求設計和方案實現能不理解嗎。能毫不客氣的說,運用 checklist 左移的方式,乙個需求評審會或者技術評審會開完後,你絕對會是最理解需求或者技術設計的人員之一。

因為你的疑問可能也是別人的疑問,你問問題後疑問被解答,別人的疑問可能也得到了解答,所以也幫助其他同學更清楚各個需求點,降低減少各方理解上的的 gap,從而避免你後續的 checklist 評審會被當做二次需求評審會的情況的發生。

checklist 左移其實也可以說是測試左移思想的乙個分支,本質上都是對產品開發過程中測試前置階段的聚焦,但是區別是 「checklist 左移」更關注的是對測試人員個人的成長和收穫,測試左移更關注的是對整個產品質量的提公升。

源文:

遞迴 運用遞迴思想解題

標籤 c語言 遞迴 by 小威威 遞迴思想,就是通過不斷呼叫自己直到滿足某一條件為止。對於遞迴的定義,我在這裡就不在闡述了,書上都寫的很明白,最典型的例子就是 從前山上有乙個老和尚和乙個小和尚 下面我就直接上題目,通過題目來進一步了解遞迴,學習遞迴。典例1 給出乙個陣列,長度為n,編號為0 n 1 ...

單詞子集 特徵思想的運用

1 a.length,b.length 10000c 函式形式為 vector wordsubsets vector a,vector b 此題 於leetcode 查詢單詞問題,首選仿造的雜湊表,只需要對a的每個單詞,在b中遍歷所有的單詞,看是否滿足就行了。class solution for k...

演算法 有序序列中運用「壓縮」思想

我們經常遇到在乙個有序序列中進行一系列的操作,比如查詢某個元素,插入某個元素,刪除某個元素等,這裡的有序序列,可能是線性的一對一的序列,也可能是二叉樹的一對多序列,那麼在面對乙個海量的有序序列時,海量資料往往會壓迫到我們的神經,讓我們沉在資料大海浬。然後有沒有一種更好的方法,讓我們有針對性地分析這個...