繼續對《炮轟“測試左移”,向軟件測試領(lǐng)域的“歪理邪說(shuō)”宣戰》的評論進(jìn)行整理,評論的第一部分請看(1)對《炮轟“測試左移”》之若干評論的整理與點(diǎn)評
評論內容請見(jiàn)下文:
評論4:萌萌噠
領(lǐng)測老賀回復:
?????? 按照“萌萌噠”的這個(gè)表述,沒(méi)有問(wèn)題。但是領(lǐng)測老賀這里要多說(shuō)一句,組織里面通常有兩類(lèi)人:一類(lèi)非常關(guān)注一線(xiàn)人員是否嚴格遵照流程做事,另一類(lèi)人是對公司流程規范嗤之以鼻。其實(shí)兩種做法都不可取。
?????? 我們需要對公司的流程規范有個(gè)正確的認識。在管理中我們通常會(huì )將“復雜的事情簡(jiǎn)單化,簡(jiǎn)單的事情標準化,標準的事情流程化,流程的事情自動(dòng)化。”
?????? 上面的總體概述解釋了流程規范的作用。所以,作為管理者應該清楚的知道什么工作應該標準化,什么應該流程化,什么應該自動(dòng)化。如果選擇錯誤,那給組織帶來(lái)的就是一團糟!
評論5:Sancery
領(lǐng)測老賀回復:
?????? 實(shí)際上評論所述的工作方式就是“測試左移”的最左邊了,在文章中我也闡述了要實(shí)施這種模式,對參與的測試工程師和需求工程師都會(huì )有更嚴格的要求,如果不是團隊中相對有經(jīng)驗的人員進(jìn)行這樣的工作,對人力資源使用來(lái)說(shuō)是個(gè)巨大的浪費。
?????? 具體到如何進(jìn)行度量,大家可以參看ISTQB高級測試經(jīng)理模塊的度量章節。簡(jiǎn)單的說(shuō)應該進(jìn)行兩個(gè)層次的度量,一個(gè)是作為研發(fā)方角色對測試角色的主觀(guān)評價(jià),用以判斷作為項目干系人是否認可測試方的工作成效。另一類(lèi)應該是在需求階段發(fā)現的缺陷,如需求具有二義性,不可測試性,邏輯錯誤,功能描述錯誤等。通過(guò)量化這些缺陷的重要性,通過(guò)歷史數據是能夠計算價(jià)值的!這又是一個(gè)巨大的話(huà)題。
評論6:Ruink
領(lǐng)測老賀回復:
?????? 最近十年,軟件測試領(lǐng)域爆火的一個(gè)崗位就是“軟件測試開(kāi)發(fā)工程師”,起源于微軟。具體崗位描述我就不說(shuō)明了。
?????? 我想在這里表述我的一個(gè)觀(guān)點(diǎn),可能也是最容易引起很多人不適的觀(guān)點(diǎn)!
?????? 軟件測試開(kāi)發(fā)工程師是為整個(gè)測試目標服務(wù)的,代碼測試代碼絕不可能解決所有軟件測試的問(wèn)題,最典型的就是易用性測試。
?????? 那在領(lǐng)測老賀眼里測試開(kāi)發(fā)工程師解決什么問(wèn)題那?他應該在一個(gè)設計良好的測試體系中承擔將手工測試效率低的測試用例,轉化成可以高效執行的自動(dòng)化的測試用例!
?????? 請注意,這里有兩個(gè)關(guān)鍵點(diǎn):
- 一定要有個(gè)設計良好的測試體系,在這個(gè)體系中,不同的測試類(lèi)型都被考慮到了,是基于覆蓋率思維和風(fēng)險概率思維構建的,
- 自動(dòng)化的測試用例解決的是效率的問(wèn)題,而不是被設計用來(lái)發(fā)現缺陷的。
這里我就不展開(kāi)講了,所以在我看來(lái),只有沒(méi)有體系的組織才會(huì )無(wú)限放大自動(dòng)化測試的效果,才會(huì )認為自動(dòng)化測試是銀彈,無(wú)限拔高測試開(kāi)發(fā)的價(jià)值。我不是認為測試開(kāi)發(fā)沒(méi)有價(jià)值,反而認為對提升效率具有無(wú)可取代的優(yōu)勢,但是如果沒(méi)有完善的測試體系支撐,那自動(dòng)化測試絕對是個(gè)災難!
未完待續......
文章評論