(2)對《炮轟“測試左移”》之若干評論的整理與點(diǎn)評

繼續對《炮轟“測試左移”，向軟件測試領(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è)災難！

未完待續......