為什么會(huì)有這么一個(gè)話題呢？很長(zhǎng)一段時(shí)間，在軟件測(cè)試領(lǐng)域，一直彌漫著一種悲觀的氛圍！比如說(shuō)測(cè)試無(wú)用論，我們需要全職的QA嗎，人工智能將取代測(cè)試工程師，測(cè)試工程師并沒(méi)有辦法為企業(yè)創(chuàng)造利益等等。

?

由于一些人或組織有心或者無(wú)心的制造一些焦慮，讓軟件測(cè)試的從業(yè)者尤其是剛?cè)胄械能浖y(cè)試工程師，對(duì)軟件測(cè)試本身的意義，以及軟件測(cè)試職業(yè)的發(fā)展、技術(shù)路徑、充滿了疑慮！在此，作為一個(gè)從業(yè)20年以上的軟件測(cè)試工程師，一個(gè)ISTQB國(guó)際軟件測(cè)試工程師認(rèn)證的專家級(jí)證書(shū)獲得者。我想談?wù)勛约旱恼J(rèn)識(shí)和看法，希望能給軟件測(cè)試從業(yè)者一些我覺(jué)得正確的軟件測(cè)試?yán)砟詈陀^點(diǎn)。

?

?????? 第一炮我們先從“測(cè)試左移”入手，談一談我對(duì)“測(cè)試左移”的看法。

?

所謂的“測(cè)試左移”是什么？

通過(guò)百度的搜索，國(guó)內(nèi)查到“測(cè)試左移”最早的描述起始于2016年年底到2017年年初。換句話說(shuō)，“測(cè)試左移”是一個(gè)新概念。

?

最初在談到“測(cè)試左移”這個(gè)概念時(shí)候，更多是指軟件研發(fā)過(guò)程中的測(cè)試活動(dòng)應(yīng)盡早介入。

圖一 ?測(cè)試左移

?

?????? 上面這張圖描述了測(cè)試左移的基本原理。即軟件研發(fā)生命周期中的缺陷大部分是在編碼過(guò)程中引入的，但是發(fā)現(xiàn)這些缺陷通常是在編碼之后才逐步的發(fā)現(xiàn)出來(lái)。如果在編碼過(guò)程中發(fā)現(xiàn)和修復(fù)缺陷的成本是1X，那發(fā)布給用戶后，則發(fā)現(xiàn)缺陷和修復(fù)的成本會(huì)增長(zhǎng)為640X。這也就引出了，如果我們提早做測(cè)試工作即“測(cè)試左移”，則發(fā)現(xiàn)或修復(fù)缺陷的成本會(huì)顯著的降低。這也就是“測(cè)試左移”的理論基礎(chǔ)。

?????? 如果你足夠細(xì)心，這張網(wǎng)絡(luò)流傳的圖還有個(gè)問(wèn)題，即它默認(rèn)缺陷的注入是從編碼開(kāi)始的，不過(guò)真實(shí)的情況只要有人開(kāi)始參與了研發(fā)工作（如需求分析，設(shè)計(jì)等），就勢(shì)必會(huì)開(kāi)始注入缺陷，在這里我們就不累述了。

?????? 需要注意的是，最早開(kāi)始說(shuō)的“測(cè)試左移”這個(gè)概念是指測(cè)試工作要提前做，而不是特指測(cè)試工程師“左移”即全職測(cè)試工程師從編碼階段介入，這兩者是有區(qū)別的!區(qū)別我們放到后面再闡述。

?

“測(cè)試左移”雖然提出時(shí)間不長(zhǎng)，但這是個(gè)新概念嗎？

軟件工程領(lǐng)域最著名的模型毫無(wú)疑問(wèn)是瀑布模型：

?????? 大家所熟悉的軟件工程瀑布模型（waterfall model）概念，起源于 Winston Royce 發(fā)表于 1970 年的著名文章 "Managing the Developmentof Large Software Systems" (Proc. Westcon, IEEE CS Press, 1970, pp.328-339)。

?

圖二：瀑布模型

?

?????? 在我看來(lái)，所謂的“測(cè)試左移”正是在彌補(bǔ)瀑布模型的不足，即不要讓測(cè)試工作只成為交付前的最后且唯一的質(zhì)量保障手段，應(yīng)該往前提，需要貫穿于整個(gè)軟件研發(fā)生命周期中。

?????? 但是請(qǐng)注意，瀑布模型是1970年提出的，距今已經(jīng)有50多年了，這么大的一個(gè)問(wèn)題，怎么會(huì)幾年前才給出個(gè)答案？

?

經(jīng)典的V模型早把這件事情說(shuō)完了！

V模型是由Paul Rook在1980年率先提出的，在1990年出現(xiàn)在英國(guó)國(guó)家計(jì)算中心的出版物中，它是對(duì)瀑布模型的一種改進(jìn)。

圖三：V模型

在這里我不想解釋V模型，有興趣可以在網(wǎng)絡(luò)上自行查詢。

我想說(shuō)的是，測(cè)試工作從需求開(kāi)始，貫穿于整個(gè)軟件研發(fā)周期是40年前就提出來(lái)的，這壓根就不是啥新概念，如果你最近才知道那是你的問(wèn)題！

?

那為什么近期換了個(gè)說(shuō)法，又提出了“測(cè)試左移” ？

測(cè)試左移一詞（shift-left testing）最早出現(xiàn)在Arthur Hicken的博客里，在他的博客中提到了對(duì)測(cè)試左移的看法。

?

圖三：最早談到“測(cè)試左移”

?

原文可以訪問(wèn)這個(gè)地址：https://www.stickyminds.com/article/shift-left-approach-software-testing

但是這篇文章發(fā)布時(shí)間“測(cè)試左移”在2018年，比國(guó)內(nèi)開(kāi)始談?wù)摰臅r(shí)間晚，有可能這個(gè)地址并不是首發(fā)地址，但并不影響我們的討論。

??????

從字面意義上看，“測(cè)試左移”更多的是強(qiáng)調(diào)開(kāi)發(fā)工程師應(yīng)該在軟件研發(fā)生命周期內(nèi)盡早的驗(yàn)證自己代碼的正確性。注意是開(kāi)發(fā)工程師自己測(cè)試自己的代碼。

?????? 在敏捷和持續(xù)交付的場(chǎng)景下，這個(gè)說(shuō)法一點(diǎn)問(wèn)題都沒(méi)有，任何一個(gè)工程化的軟件研發(fā)模型都在強(qiáng)調(diào)盡早驗(yàn)證和確認(rèn)（這就是著名的V&V模型），最早可以追溯到40年前的V模型。

?

那為什么又開(kāi)始強(qiáng)調(diào)“測(cè)試左移”那？很簡(jiǎn)單，一直沒(méi)做唄！沒(méi)做什么那？比如：?jiǎn)卧獪y(cè)試，持續(xù)集成，單功能點(diǎn)驗(yàn)證等。注意以上這些測(cè)試，最合適的執(zhí)行的人員是開(kāi)發(fā)工程師本人。

?

為什么一直不按照要求做那？除了怕麻煩，對(duì)交付質(zhì)量要求低，后續(xù)還可以讓測(cè)試工程師代勞還能有什么原因？這也是在敏捷活動(dòng)中，一直在推動(dòng)開(kāi)發(fā)人員自測(cè)，對(duì)自己代碼質(zhì)量負(fù)責(zé)，進(jìn)行TDD實(shí)踐等的核心原因！

?

綜上所述，最開(kāi)始提出“測(cè)試左移”的本意只是再次強(qiáng)調(diào)開(kāi)發(fā)工程師應(yīng)該自己做單元測(cè)試，對(duì)自己的代碼負(fù)責(zé)，這是個(gè)老生常談的話題。新的名詞的出現(xiàn)，只是為了讓開(kāi)發(fā)工程師再次重視起來(lái)！

那炮轟“測(cè)試左移”，到底炮轟的是什么？

截止到現(xiàn)在，我們并沒(méi)有發(fā)現(xiàn)“測(cè)試左移”的提法有什么問(wèn)題，雖然“測(cè)試左移”本質(zhì)上只不過(guò)重新發(fā)明了個(gè)名詞，換湯不換藥 。

?

可事實(shí)上并沒(méi)有這么簡(jiǎn)單。

“測(cè)試左移”這個(gè)提法朗朗上口，隨著時(shí)間的推移，“測(cè)試左移”被曲解成“測(cè)試工程師左移”，即測(cè)試工程師應(yīng)該全部變?yōu)闇y(cè)試開(kāi)發(fā)工程師，需要具備優(yōu)異的開(kāi)發(fā)技能，參與到單元測(cè)試，集成測(cè)試的環(huán)節(jié)中，或者說(shuō)直接取代開(kāi)發(fā)工程師來(lái)進(jìn)行代碼邏輯和接口的測(cè)試，通過(guò)編寫代碼測(cè)試代碼。

更有甚者甚至鼓吹，今后將不再需要不懂代碼的測(cè)試工程師，不會(huì)編碼的測(cè)試工程師將全部失業(yè)，不會(huì)有未來(lái)，手工測(cè)試終將被代碼測(cè)試代碼取代。媒體廣告中充斥著測(cè)試開(kāi)發(fā)工程師，全棧測(cè)試工程師的宣傳，這一氛圍讓手工測(cè)試工程師感覺(jué)低人一等，逐步的被邊緣化，一夜之間仿佛軟件測(cè)試工作不談代碼，不談自動(dòng)化就是政治不正確，就是被行業(yè)拋棄的角色。

在我的微信公眾號(hào):領(lǐng)測(cè)軟件測(cè)試網(wǎng) 后臺(tái)，和領(lǐng)測(cè)老賀聊測(cè)試的QQ群中總能看到這樣的言論，以上的提法在軟件測(cè)試工程師圈子內(nèi)持續(xù)的蔓延，人云亦云的結(jié)果就是制造焦慮，對(duì)自己技能的不信任，對(duì)基于功能測(cè)試，基于手工測(cè)試工作的質(zhì)疑！面對(duì)開(kāi)發(fā)人員不夠硬氣，總覺(jué)得低人一等，由此進(jìn)入惡性循環(huán)！

?

?

為了說(shuō)明這個(gè)問(wèn)題，我嘗試從以下幾個(gè)方面加以分析

?

1.?????開(kāi)發(fā)工程師和測(cè)試工程師的工作目標(biāo)存在巨大差異

開(kāi)發(fā)工程師的工作目標(biāo)是實(shí)現(xiàn)功能，目標(biāo)相對(duì)明確，判定成功的標(biāo)準(zhǔn)也明確即目標(biāo)功能實(shí)現(xiàn)正確。

但測(cè)試工程師的工作目標(biāo)是高效的尋找軟件缺陷，需要的是風(fēng)險(xiǎn)思維和概率思維，判定測(cè)試成功的標(biāo)準(zhǔn)也不算明確，發(fā)布后的評(píng)估才是終極審判。注意這里評(píng)價(jià)測(cè)試工作的兩個(gè)維度，一個(gè)是高效，一個(gè)是缺陷。

?

2.?????同樣的事情，從組織的角度考慮誰(shuí)做更劃算

做每件事情都有成本，標(biāo)準(zhǔn)的思考模型應(yīng)該是兩利相權(quán)取其大，兩害相權(quán)取其輕。針對(duì)代碼邏輯的單元測(cè)試誰(shuí)做成本最低？收效最高？當(dāng)然是編寫代碼的本尊了！企業(yè)必須用最有效率的方案去獲取目標(biāo)。

?

3.?????單功能點(diǎn)驗(yàn)證不是測(cè)試工程師眼中的軟件測(cè)試

如果你細(xì)心觀察，你會(huì)發(fā)現(xiàn)大多數(shù)具有開(kāi)發(fā)背景的工程師口中的軟件測(cè)試基本上都是單功能點(diǎn)驗(yàn)證，并且他們堅(jiān)持認(rèn)為這就是測(cè)試的全部。作為一個(gè)有20年軟件測(cè)試經(jīng)驗(yàn)的測(cè)試工程師，我可以很負(fù)責(zé)任的告訴你，單功能點(diǎn)驗(yàn)證通過(guò)只是系統(tǒng)化軟件測(cè)試的入口條件，絕不是測(cè)試的全部，或者在嚴(yán)格意義上來(lái)說(shuō)這根本就不是軟件測(cè)試。專業(yè)的軟件測(cè)試工作研究的是功能的組合，在無(wú)窮無(wú)盡的功能組合中尋找當(dāng)前場(chǎng)景下的最優(yōu)解才是你應(yīng)該追尋的目標(biāo)。什么是最優(yōu)解那？就是在平衡各方利益的情況下，如何最有效率的滿足既定的質(zhì)量目標(biāo)！

理想情況下，我們拿到的軟件就應(yīng)該是一個(gè)單功能點(diǎn)驗(yàn)證通過(guò)的產(chǎn)品。換句話說(shuō)，單功能點(diǎn)驗(yàn)證應(yīng)該是開(kāi)發(fā)工程師的職責(zé)！只有這樣，專業(yè)的測(cè)試工程師才能發(fā)揮最大的效用。

如果你的公司只做單功能點(diǎn)驗(yàn)證，或者說(shuō)絕大多數(shù)工作都是單功能點(diǎn)驗(yàn)證，我可以明確地跟你說(shuō)，你做的不是專業(yè)測(cè)試工作。你測(cè)試的產(chǎn)品質(zhì)量一定很差！你需要系統(tǒng)的學(xué)習(xí)一下軟件測(cè)試到底怎么做。

?

?

?????? 綜上所述，開(kāi)發(fā)的測(cè)試和測(cè)試的測(cè)試根本就是兩個(gè)概念，單元測(cè)試本就應(yīng)該由開(kāi)發(fā)工程師完成，單功能點(diǎn)的驗(yàn)證不能是測(cè)試的全部，專業(yè)的測(cè)試工程師要具備風(fēng)險(xiǎn)思維，要做基于風(fēng)險(xiǎn)的測(cè)試覆蓋。

?

讓功能測(cè)試工程師集體轉(zhuǎn)型做單元測(cè)試，并稱為“測(cè)試左移”：“不是傻就是壞”！

?

測(cè)試工程師不需要了解代碼嗎？

?????? 軟件測(cè)試是一個(gè)行業(yè)，里面有若干工種，隨著職位的不同，對(duì)掌握代碼的技能要求是完全不一樣的。例如：同樣是廚師，但是面點(diǎn)，西餐廚師，對(duì)刀工的要求就遠(yuǎn)遠(yuǎn)弱于中餐廚師。

?

?????? 當(dāng)然，當(dāng)你掌握了代碼后，對(duì)測(cè)試的效果肯定是有正向加分的，但是我要提醒你一句，你的價(jià)值來(lái)源于你與團(tuán)隊(duì)的技能互補(bǔ)，而不來(lái)源于你和團(tuán)隊(duì)的技能相同點(diǎn)。

?

?????? 也就是說(shuō)，你的團(tuán)隊(duì)到底是需要一個(gè)專業(yè)測(cè)試工程師做基于風(fēng)險(xiǎn)的測(cè)試評(píng)估，還是需要一個(gè)懂開(kāi)發(fā)的測(cè)試工程師，用代碼測(cè)試代碼，從而提高做單功能點(diǎn)驗(yàn)證的效率？這是你或者說(shuō)你的團(tuán)隊(duì)需要考慮的問(wèn)題！

?

?????? 以國(guó)內(nèi)目前的氛圍來(lái)講，現(xiàn)在談測(cè)試工程師需要掌握代碼的論調(diào)不是太少，而是太多了。而討論具體如何構(gòu)建測(cè)試體系，讓測(cè)試工程師掌握專業(yè)的基于風(fēng)險(xiǎn)，基于覆蓋的測(cè)試思維不是太多了，而是太少了。

?

?????? 測(cè)試工程師掌握代碼本身并沒(méi)有錯(cuò)，相反還有很大的好處，這會(huì)極大的豐富你的測(cè)試手段，提高測(cè)試效率。但是請(qǐng)注意，和整個(gè)測(cè)試體系的構(gòu)建來(lái)比較，這還只是停留在“術(shù)”的層面，作為測(cè)試管理者必須清醒的意識(shí)到軟件測(cè)試本身到底解決什么問(wèn)題，效率是錦上添花，科學(xué)的覆蓋率策略才是根本！沒(méi)有覆蓋率保證前提下的效率帶來(lái)的只有懷疑和混亂！

??????

???? 基于代碼測(cè)試代碼的自動(dòng)化測(cè)試可以取代專業(yè)的功能組合測(cè)試嗎？

很遺憾，至少目前不行。

?

???? 目前的自動(dòng)化測(cè)試技術(shù)是將手工測(cè)試用例中，適合重復(fù)執(zhí)行或數(shù)據(jù)驅(qū)動(dòng)的用例抽取出來(lái)，并將其自動(dòng)化執(zhí)行?；谶@個(gè)原理，所以自動(dòng)化測(cè)試通常是手工測(cè)試的最小用例集，是用來(lái)做質(zhì)量的最低防火墻的。

?????? 出于成本考慮，在很多場(chǎng)景下，手工測(cè)試的成本也會(huì)遠(yuǎn)遠(yuǎn)小于自動(dòng)化的成本。所以也沒(méi)有道理將所有的手工測(cè)試自動(dòng)化。

?????? 再有，例如發(fā)現(xiàn)Bug能力超強(qiáng)的探索性測(cè)試技術(shù)，本身就不需要提前規(guī)劃測(cè)試路徑，從原理上說(shuō)自動(dòng)化測(cè)試是不可能替代探索性測(cè)試的。

?

?????? MBT基于模型的測(cè)試技術(shù)，至少目前看還不可能建模后做全遍歷覆蓋，這樣會(huì)造成用例爆炸。

基于AI進(jìn)行自主學(xué)習(xí)的測(cè)試，現(xiàn)在并沒(méi)有看到可以實(shí)用的解決方案。還處于探索，研究階段，對(duì)此我也保持謹(jǐn)慎樂(lè)觀。

?

?????? 說(shuō)了這么多，無(wú)非是想說(shuō)明，依靠代碼測(cè)試代碼，測(cè)試開(kāi)發(fā)工程師能解決的問(wèn)題有限，不可能完全取代手工測(cè)試工程師。

?

如果你的企業(yè)真的是這么做的，我想請(qǐng)你思考一下，目前你的企業(yè)軟件產(chǎn)品的質(zhì)量高嗎？是不是對(duì)發(fā)布質(zhì)量要求比較低？后期主要依賴用戶發(fā)現(xiàn)？如果是的話，這是個(gè)特例，并不是普遍情況，而且以互聯(lián)網(wǎng)應(yīng)用為主，客戶對(duì)發(fā)布質(zhì)量不敏感。

?

為什么說(shuō)“測(cè)試左移”是個(gè)偽概念

首先，最前面已經(jīng)提及“測(cè)試左移”不是新概念，只是對(duì)幾十年前原有理論的一個(gè)重新命名而已！

?

其次，“測(cè)試左移”與“測(cè)試工程師左移”是完全不同的。

?

第三點(diǎn)，與其現(xiàn)在持續(xù)強(qiáng)調(diào)“測(cè)試左移”帶來(lái)的誤解，為什么不強(qiáng)調(diào)“開(kāi)發(fā)右移”。讓開(kāi)發(fā)工程師意識(shí)到單元測(cè)試，單功能點(diǎn)測(cè)試是開(kāi)發(fā)工作的一部分，不能，也不應(yīng)該讓測(cè)試工程師替你來(lái)完成。因?yàn)橹挥腥绱?，測(cè)試工程師才能將精力集中在真正的測(cè)試工作上面來(lái)。當(dāng)開(kāi)發(fā)抱怨測(cè)試技術(shù)含量低，測(cè)試效果不好的時(shí)候，測(cè)試工程師沒(méi)有將工作重點(diǎn)放到真正的測(cè)試工作上來(lái)才是癥結(jié)所在！

?

第四點(diǎn)，具體到應(yīng)該“測(cè)試左移”還是“測(cè)試右移”，我想分歧無(wú)非是“單元測(cè)試”和“單功能點(diǎn)測(cè)試”誰(shuí)來(lái)測(cè)？也可能很多企業(yè)還上升不到這個(gè)高度，因?yàn)閴焊筒粶y(cè)！我的觀點(diǎn)是：當(dāng)然測(cè)比不測(cè)強(qiáng)，但是如果現(xiàn)在是測(cè)試工程師進(jìn)行的單功能點(diǎn)測(cè)試，我想請(qǐng)你意識(shí)到，這不是測(cè)試工作，或者說(shuō)這不是測(cè)試工作的全部。如果你的企業(yè)想讓軟件質(zhì)量上一個(gè)臺(tái)階，請(qǐng)你們有體系，有步驟的將這項(xiàng)工作轉(zhuǎn)移到研發(fā)部門。也就是開(kāi)始強(qiáng)調(diào)“開(kāi)發(fā)右移”！

?

第五點(diǎn)，請(qǐng)別跟我談敏捷，就這件事情上來(lái)說(shuō)沒(méi)什么區(qū)別。開(kāi)發(fā)人員必須完成自己的測(cè)試工作，請(qǐng)“開(kāi)發(fā)右移”。

?

?????? 第六點(diǎn)，所謂的測(cè)試工程師的“測(cè)試左移”是提高了質(zhì)量還是降低了質(zhì)量？

短期看似提高（因?yàn)橐郧皼](méi)人做的事情有人做了），但長(zhǎng)期穩(wěn)步下降（因?yàn)橘|(zhì)量的第一責(zé)任人開(kāi)發(fā)工程師放棄了這部分工作）。

誰(shuí)的職責(zé)就是誰(shuí)的職責(zé)！可以協(xié)助、教，但是絕不能替代！（所謂的教就是敏捷中的測(cè)試教練的工作）。

貫穿于全生命周期的軟件測(cè)試，不意味著全生命周期的軟件測(cè)試工作均由全職測(cè)試工程師完成，不同角色應(yīng)該完成各自意義上的測(cè)試工作。

請(qǐng)諸位測(cè)試工程師充分的意識(shí)到：軟件測(cè)試工程師是為質(zhì)量服務(wù)，不是為軟件開(kāi)發(fā)工程師服務(wù)，具體的任何一項(xiàng)測(cè)試工作都是手段，你的目標(biāo)是建立一個(gè)集合所有角色的質(zhì)量保證或者說(shuō)測(cè)試體系。所有角色分工協(xié)作，才能共同有效的保證質(zhì)量。

?

?

醒醒吧：軟件測(cè)試和軟件開(kāi)發(fā)處理的問(wèn)題不一樣，不要自怨自艾！到底是測(cè)試做的不好，水平太低，還是你理解的測(cè)試壓根就不對(duì)？

?

用正確測(cè)試?yán)砟钗溲b起來(lái)的，硬氣的測(cè)試工程師對(duì)企業(yè)才有價(jià)值！

?

放棄能效比談質(zhì)量都是耍流氓

我們前面分析了大量開(kāi)發(fā)工程師應(yīng)該保證自己代碼質(zhì)量的原因?？赡苡腥藭?huì)問(wèn)，你說(shuō)開(kāi)發(fā)人員自測(cè)自己的代碼，保證單功能點(diǎn)的正確性姑且算你正確。但是“測(cè)試左移”說(shuō)的是提早測(cè)試，這個(gè)提早測(cè)試并不唯一指單元測(cè)試、集成測(cè)試，還包括對(duì)需求的測(cè)試?。　皽y(cè)試左移”泛指專業(yè)的測(cè)試工程師應(yīng)該從需求階段開(kāi)始介入，這總不會(huì)有問(wèn)題吧？如果沒(méi)有問(wèn)題，怎么能說(shuō)“測(cè)試左移”或者說(shuō)“測(cè)試工程師左移”是偽概念那？

?

這個(gè)問(wèn)題很好，所以我放到最后討論這個(gè)話題。先說(shuō)一下我的結(jié)論，全職測(cè)試工程師從需求開(kāi)始介入，可以認(rèn)為是測(cè)試工程師左移的一個(gè)好的實(shí)踐，但是不是一個(gè)所有企業(yè)都普遍適用的最佳實(shí)踐那？我看未必！

?

為了說(shuō)清楚這個(gè)話題，我們從如下幾點(diǎn)加以說(shuō)明：

?

?????? 首先，我們要區(qū)分測(cè)試工作和全職測(cè)試工程師的工作，測(cè)試工作廣義上指驗(yàn)證和確認(rèn)工作，可能由專職的測(cè)試工程師完成，也可能由團(tuán)隊(duì)中更合適的角色來(lái)完成。具體由誰(shuí)來(lái)完成，需要組織綜合考慮：技能適配性、溝通成本、職業(yè)發(fā)展、效率最優(yōu)、成本最低等制約要素。

?

下面我們來(lái)討論“測(cè)試工程師從需求階段介入”是不是一個(gè)好的實(shí)踐。

?

如果測(cè)試工程師從需求階段介入，對(duì)測(cè)試工程師的技能有沒(méi)有特殊要求那？答案是肯定的，當(dāng)然有！

第一，??在需求階段介入的測(cè)試工程師要對(duì)業(yè)務(wù)非常熟悉，至少是個(gè)業(yè)務(wù)專家，對(duì)業(yè)務(wù)的理解不能弱于需求分析師，否則根本沒(méi)有辦法進(jìn)行對(duì)等的交流。

第二，??在需求階段介入的測(cè)試工程師要對(duì)需求文檔的書(shū)寫技能和語(yǔ)言邏輯很清楚，這樣才能參與到需求的獲取和評(píng)審工作中來(lái)。

第三，??在需求階段介入的測(cè)試工程師要有很強(qiáng)的溝通技能，這個(gè)階段的工作很多是從溝通交流中切入的。

第四，??在需求階段介入的測(cè)試工程師要有很強(qiáng)的測(cè)試分析和設(shè)計(jì)能力，因?yàn)檫@就是他此時(shí)介入的分內(nèi)工作。

?

綜上所述，在需求階段介入的測(cè)試工程師是整個(gè)測(cè)試團(tuán)隊(duì)中核心中的核心！

?

那在需求階段介入的測(cè)試工程師在這個(gè)階段具體的產(chǎn)出物是什么那？

??????

如果在需求評(píng)審之前介入的話，老實(shí)說(shuō)，沒(méi)有什么硬性的產(chǎn)出物，更多的是提前對(duì)系統(tǒng)需求進(jìn)行了解。提出后續(xù)測(cè)試工作要點(diǎn)和組織方式的規(guī)劃，由于需求文檔也沒(méi)有完全定稿，所以當(dāng)前所有的工作都存在被推翻的可能性。

?

如果在需求評(píng)審中或需求評(píng)審?fù)ㄟ^(guò)后介入的話，更多的是作為需求評(píng)審人員參與需求評(píng)審工作，綜合需求和其它文檔等，進(jìn)行測(cè)試的分析和設(shè)計(jì)，這里是有明確產(chǎn)出物的。但是請(qǐng)一定注意，測(cè)試人員如果參與需求評(píng)審工作，你首先是個(gè)業(yè)務(wù)專家，可以為需求評(píng)審貢獻(xiàn)一份綿薄之力，其次你才是測(cè)試工程師，從系統(tǒng)的可測(cè)試性思考需求的問(wèn)題。千萬(wàn)不要搞反了！需求工作的第一責(zé)任人是需求分析師，切記！

?

綜上所述，如果作為質(zhì)量的負(fù)責(zé)人，你應(yīng)該如何選擇？讓測(cè)試工程師從需求評(píng)審前，評(píng)審中，評(píng)審后那個(gè)階段介入更合理那？

這里并沒(méi)有唯一或者最佳實(shí)踐，你要綜合考慮成本，環(huán)境，技術(shù)，風(fēng)險(xiǎn)，投入產(chǎn)出比等制約條件，綜合考慮。

?

我的建議是：最早評(píng)審?fù)瓿珊蠼槿耄蛘咄七t到系統(tǒng)測(cè)試開(kāi)始之前介入，主要是從投入產(chǎn)出比的角度考慮。當(dāng)然，每個(gè)組織對(duì)質(zhì)量的期望是不同的，需要按照自己的實(shí)際質(zhì)量目標(biāo)進(jìn)行綜合考慮。

?

就這個(gè)話題來(lái)說(shuō)，我們談?wù)摰姆秶](méi)有超過(guò)幾十年前V模型涵蓋的內(nèi)容，如果說(shuō)這就是最“先進(jìn)”的“測(cè)試左移”理念，我表示不服！

?

總結(jié)一下：放棄成本談質(zhì)量，就是耍流氓！合理的團(tuán)隊(duì)協(xié)作模型，讓組織效率整體提升，過(guò)程質(zhì)量、產(chǎn)品質(zhì)量雙提高才應(yīng)該是追求的目標(biāo)！

?

對(duì)在軟件測(cè)試圈內(nèi)“販賣焦慮”說(shuō)不！

?????? 軟件測(cè)試領(lǐng)域是個(gè)專業(yè)的領(lǐng)域，作為這個(gè)行業(yè)的從業(yè)者，我們應(yīng)該系統(tǒng)化我們的測(cè)試體系，用正確的測(cè)試?yán)砟钗溲b自己。

?????? 我們構(gòu)建的是一個(gè)基于風(fēng)險(xiǎn)，基于概率思維的質(zhì)量評(píng)估體系，技術(shù)手段是為測(cè)試目標(biāo)服務(wù)的。

?????? 專業(yè)的軟件測(cè)試不能脫離整體的覆蓋率談測(cè)試技術(shù)。