前些天在網(wǎng)站上看到一篇名為我們需要專職的QA嗎？讓我很讓震驚！
發(fā)這篇文章的目的，并不是對(duì)原作者的看法表示如何的批評(píng)，且說(shuō)出自己的想法（自認(rèn)為很中正的看法），希望各位網(wǎng)友能說(shuō)出你的看法，也希望我能解釋很多開發(fā)人員的疑惑。
文章鏈接：我們需要專職的QA嗎？
紫色的文字為引用原文，因?yàn)橐梦恼潞荛L(zhǎng)，請(qǐng)見諒
在開始今天的討論之前，先看幾個(gè)名詞解釋（參考）：
質(zhì)量保證（QA）：QA（QUALITY ASSURANCE，中文意思是“品質(zhì)保證”，通過(guò)過(guò)程的持續(xù)改進(jìn)來(lái)提高產(chǎn)品質(zhì)量，是軟件成熟度模型（CMMI/ISO）中的一個(gè)角色
QA可以對(duì)開發(fā)的具體技術(shù)不了解，但要對(duì)CMMI、ISO900等的流程要清楚
軟件配置管理（SCM）：配置管理（Configuration Management，CM）是通過(guò)技術(shù)或行政手段對(duì)軟件產(chǎn)品及其開發(fā)過(guò)程和生命周期進(jìn)行控制、規(guī)范的一系列措施。配置管理的目標(biāo)是記錄軟件產(chǎn)品的演化過(guò)程（其中涉及到基線的概念），確保軟件開發(fā)者在軟件生命周期中各個(gè)階段都能得到精確的產(chǎn)品配置；
配置管理包括六大任務(wù)：配置標(biāo)識(shí)、版本管理、變更管理、配置審核、狀態(tài)報(bào)告、發(fā)布管理，配置管理的最重要的是版本管理和發(fā)布管理；
配置管理往往是配置在質(zhì)量部統(tǒng)一進(jìn)行管理，現(xiàn)時(shí)還要為測(cè)試提供一個(gè)測(cè)試環(huán)境，即我們講的搭測(cè)試環(huán)境。
軟件測(cè)試（Tester）：使用人工或者自動(dòng)手段來(lái)運(yùn)行或測(cè)試某個(gè)系統(tǒng)的過(guò)程（他是一個(gè)驗(yàn)證的過(guò)程），其目的在于檢驗(yàn)它是否滿足規(guī)定的需求或弄清預(yù)期結(jié)果與實(shí)際結(jié)果之間的差別，通俗的說(shuō)是去驗(yàn)證兩個(gè)方面：是否做了正確的某事，是否正確的做了某事
QA通過(guò)對(duì)流程（過(guò)程）的持續(xù)改進(jìn)來(lái)提升產(chǎn)品的最終質(zhì)量；軟件測(cè)試通過(guò)技術(shù)來(lái)保證產(chǎn)品的最終質(zhì)量；配置管理是對(duì)過(guò)程產(chǎn)品及軟件生命周期進(jìn)行管理。
所以，到這里我們就可以看到，其實(shí)標(biāo)題中把測(cè)試和QA的概念混為一談，是錯(cuò)誤的！
“我們都同意，Dev 要懂測(cè)試，QA 要懂開發(fā)，只不過(guò)分工不同，既然你中有我，我中有你，那就不要分彼此了，一起攜手開發(fā)測(cè)試吧 （另外，我個(gè)人覺得不懂開發(fā)的測(cè)試人員不可能測(cè)試得好”）
對(duì)于上面的觀點(diǎn)我是認(rèn)同的。
至于園子中轉(zhuǎn)載的文章，我不知道作者是誰(shuí)，既然是分享，那么我們來(lái)看一下作者的故事：
我們暫且沿用作者的QA稱謂
“我再說(shuō)說(shuō)我最糟糕的 QA 經(jīng)歷吧，這個(gè)公司的 QA 部門只做測(cè)試，他們的 leader 覺得所有的 test design 和 test 的過(guò)程都不需要 Dev 參與，他們是獨(dú)立于 Dev 之外的部門，他們幾乎不關(guān)心 Dev 的設(shè)計(jì)和實(shí)現(xiàn)，他們只關(guān)心能跑通他們自己設(shè)計(jì)的 test case。但是去執(zhí)行 Test Case 的時(shí)候，又需要 Dev 的支持，尤其在環(huán)境設(shè)置，測(cè)試工具使用，確認(rèn)是否是 bug 方面，全都在消耗著 Dev 的資源，最扯的是，他們對(duì)任何線上的問(wèn)題不負(fù)責(zé)，反正出了問(wèn)題由 Dev 加班搞定。”
上面的文字包含了很多分享者公司的情況，不知是不是可以猜測(cè)如下：
把測(cè)試能獨(dú)立于開發(fā)之外（把需求視若無(wú)物）進(jìn)行，這首先是Tester或Leader認(rèn)知層面上的一個(gè)錯(cuò)誤（是否作者的理解有誤差暫且不論）；
或者可能從中看出來(lái)，分享者的公司中沒有測(cè)試總監(jiān)、測(cè)試組長(zhǎng)之類的Leader或者他們的資質(zhì)明顯不足以勝任他們的工作，才會(huì)出現(xiàn)前面所說(shuō)的將測(cè)試獨(dú)立于開發(fā)和其他部門而存在；
我們或者可以從Dev的抱怨中看到，公司的測(cè)試人員資質(zhì)不夠（不懂得基本測(cè)試工具的使用，不擅長(zhǎng)自我學(xué)習(xí)、自我突破），過(guò)分的依賴本身已有的知識(shí)及開發(fā)人員的協(xié)助；
公司對(duì)于需求的管理很粗或者根本沒有管理（或者還是測(cè)試人員的理解能力太差，無(wú)法理解需求的含義，無(wú)法分辨需求與實(shí)現(xiàn)之前的差異是否可以定義為Bug），如果有明確的需求管理，則不會(huì)出現(xiàn)經(jīng)常無(wú)法確認(rèn)是否Bug的情況；
我們可以從字里行間，感覺分享者的公司好像是為了測(cè)試而測(cè)試，要知道測(cè)試的目的是為了最終的質(zhì)量，這一點(diǎn)在整個(gè)公司上下的目的都是一致的，任何的工作都不能偏離這個(gè)目標(biāo)而存在
我認(rèn)為：
公司要做好測(cè)試工作保證質(zhì)量，公司從CEO到普通員工有質(zhì)量意識(shí)很重要，只有從意識(shí)上認(rèn)識(shí)到質(zhì)量的重要性，才能真正的做好質(zhì)量的管理，沒質(zhì)量的意識(shí)，其他就都是空中樓閣；
同時(shí)優(yōu)秀的測(cè)試總監(jiān)和測(cè)試組長(zhǎng)是保證測(cè)試工作質(zhì)量的前提 ，相信強(qiáng)將手下少弱兵；
不要認(rèn)為任何人都能做好測(cè)試，基層測(cè)試人員的素質(zhì)很重要（懂開發(fā)的測(cè)試人員或Dev最好，還要有專業(yè)系統(tǒng)的測(cè)試?yán)碚摚瑫r(shí)最好了解需求或業(yè)務(wù)），他們最終的測(cè)試執(zhí)行者，是質(zhì)量保證的第一關(guān)和最后一關(guān)；
需求管理與需求培訓(xùn)很重要，遇到需求問(wèn)題，溝通很重要；
質(zhì)量部不是擺設(shè)，測(cè)試人員也不是找茬的家伙，大家的目標(biāo)要一致的---質(zhì)量
“我有一次私自 review 他們的 test case 的時(shí)候，發(fā)現(xiàn)很多的 test case 這樣寫到 – “Expected Result：Make sure every thing is fine” ，WTF，什么叫“Every thing is fine”？！而在 test case design 的時(shí)候，沒有說(shuō)明 test environment/configuration 是什么？沒有說(shuō)明 test data 在哪里？Test Case、Test Data、Test Configuration 都沒有版本控制，還有很多 Test Case 設(shè)計(jì)得非常冗余（多個(gè) Test Case 只測(cè)試了一個(gè)功能），不懂得分析 Function Point 就做 Test Design。另外，我不知道他們?yōu)槭裁茨敲礋嶂杂谠O(shè)計(jì)一堆各式各樣的 Negative Test Case，而有很多 Positive 的 Test Case 沒有覆蓋到。為什么呢，因?yàn)樗麄儾恢篱_發(fā)和設(shè)計(jì)的細(xì)節(jié)，所以沒有辦法設(shè)計(jì)出 Effective 的 Test Case，只能從需求和表面上做黑盒。”
我很能理解這會(huì)Dev的感受，測(cè)試人員把預(yù)期結(jié)果寫成“Every thing is fine”，誰(shuí)他都受不了！
上面所說(shuō)到的測(cè)試人員存在兩個(gè)問(wèn)題：
①測(cè)試用例的基本構(gòu)成不完成，構(gòu)成元素過(guò)于模糊無(wú)法達(dá)到準(zhǔn)確測(cè)試的目的，無(wú)法實(shí)現(xiàn)測(cè)試用例的延續(xù)（他人無(wú)法看懂你的測(cè)試用例）
②測(cè)試人員對(duì)需求或測(cè)試?yán)碚摾斫獠粔颍瑢?dǎo)致很多的漏洞或重復(fù)測(cè)試
但是我要告訴你的是“這和測(cè)試沒有什么關(guān)系，這所有的一切都只能說(shuō)明，你們的測(cè)試人員很濫，他們的很濫直接影響到了你對(duì)整個(gè)測(cè)試的理解”；
同時(shí)，我要講的是是否了解需求與是否做黑盒測(cè)試沒有關(guān)系，下面是黑盒測(cè)試的概念可以參考一下：
黑盒測(cè)試：也稱功能測(cè)試，它是通過(guò)測(cè)試來(lái)檢測(cè)每個(gè)功能是否都能正常使用。在測(cè)試中，把程序看作一個(gè)不能打開的黑盒子，在完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下，在程序接口進(jìn)行測(cè)試，它只檢查程序功能是否按照需求規(guī)格說(shuō)明書的規(guī)定正常使用，程序是否能適當(dāng)?shù)亟邮蛰斎霐?shù)據(jù)而產(chǎn)生正確的輸出信息。
所以，如果遇到上面的情況，不應(yīng)該是說(shuō)對(duì)軟件測(cè)試失去信心（因?yàn)槲覀冃枰玫谋ＷC質(zhì)量），而應(yīng)該向你的上級(jí)反應(yīng)，我們需要更稱職的測(cè)試人員！！！
建議去51Testing上看一看有關(guān)軟件測(cè)試方面的信息
“在做性能測(cè)試的時(shí)候，需要 Dev 手把手的教怎么做性能測(cè)試，如何找到系統(tǒng)性能極限，如何測(cè)試系統(tǒng)的 latency，如何觀察系統(tǒng)的負(fù)載（CPU，內(nèi)存，網(wǎng)絡(luò)帶寬，磁盤和網(wǎng)卡I/O，內(nèi)存換頁(yè)……）如何做 Soak Test，如何觀察各個(gè)線程的資源使用情況，如何通過(guò)配置網(wǎng)絡(luò)交換機(jī)來(lái)模擬各種網(wǎng)絡(luò)錯(cuò)誤，等等，等等。”
這就是我上面說(shuō)的，測(cè)試人員的本身素質(zhì)太差，無(wú)法實(shí)現(xiàn)自我學(xué)習(xí)，自我提升與自我突破的情形
要知道在工作中要用到的東西并不是我們都會(huì)的，在這種情況下，我們就要積極主動(dòng)的去學(xué)習(xí)，個(gè)人認(rèn)為在有壓力的情況下學(xué)習(xí)，往往是事半功倍的！
“在項(xiàng)目快要上線前的一周，我又私自查看了一下他們的 Test Result，我看到 5 天的 Soak Test 的內(nèi)存使用一直往上漲，很明顯的內(nèi)存泄露，這個(gè)情況發(fā)生在 2 個(gè)月前，但是一直都沒有報(bào)告，我只好和我的程序員每天都加班到凌晨，趕在上線前解決了這個(gè)問(wèn)題。但是，QA 部門的同學(xué)們就像沒發(fā)生什么事似的，依然正常上下班。哎……”
首先要肯定的是測(cè)試人員沒有測(cè)試好，開發(fā)人員沒有開發(fā)好，所以誰(shuí)也不要說(shuō)誰(shuí)做得不好。人非圣賢，離孰能無(wú)過(guò)焉！
出現(xiàn)問(wèn)題時(shí)，先解決問(wèn)題，而不是先追究責(zé)任，在問(wèn)題解決之后，我們需要討論問(wèn)題產(chǎn)生的原因，如何避免下次再出現(xiàn)這樣的情況，同時(shí)如果可以追溯到相關(guān)的責(zé)任人，我們要進(jìn)行一定的處理，但處理不是重點(diǎn)。
出現(xiàn)一些緊急的情況，加班難免，要能扛得住！
“為什么會(huì)這樣？我覺得有這么幾點(diǎn)原因（和鄒欣的觀點(diǎn)一樣）
1、給了 QA 全部測(cè)試的權(quán)力，但是沒有給相應(yīng)的責(zé)任，
2、QA 沒有體會(huì)過(guò)軟件質(zhì)量出問(wèn)題后的痛苦（解決線上問(wèn)題的壓力），導(dǎo)致 QA 不會(huì)主動(dòng)思考和改進(jìn)。
3、QA 對(duì) Dev 的開發(fā)過(guò)程和技術(shù)完全不了解，增加了很多 QA 和 Dev 的溝通。
4、QA 對(duì)軟件項(xiàng)目的設(shè)計(jì)和實(shí)現(xiàn)要點(diǎn)不了解，導(dǎo)致了很多不有效的測(cè)試。”
1、質(zhì)量部的責(zé)任是很重的，一量出現(xiàn)漏測(cè)或出現(xiàn)線上事故，質(zhì)量部是要承擔(dān)一半或以上的責(zé)任的（但具體的也要看公司的情況，如果沒有系統(tǒng)的管理，這個(gè)很難說(shuō)）
2、軟件出現(xiàn)問(wèn)題，測(cè)試人員是不是要重新測(cè)試，甚至有時(shí)候要加班加點(diǎn)（至于分享者說(shuō)的他們測(cè)試人員不管什么時(shí)候按時(shí)下班，這還是歸結(jié)到測(cè)試人員的素質(zhì)問(wèn)題，就無(wú)關(guān)乎能力了）是常有的事；計(jì)算機(jī)行業(yè)是一個(gè)快速發(fā)展的行業(yè)，不思考不主動(dòng)學(xué)習(xí)，你很快就會(huì)被淘汰，如果你的公司的測(cè)試人員還抱著過(guò)去的知識(shí)、抑制學(xué)習(xí)、被動(dòng)思考，那么你可以讓他回家抱孩子，熱坑頭……
3、測(cè)試人員不了解軟件工程或開發(fā)語(yǔ)言的情況常有，但有時(shí)候我們也需要精通業(yè)務(wù)的人來(lái)進(jìn)行測(cè)試，這個(gè)是很重要的！
4、這個(gè)涉及到我前面講過(guò)的對(duì)需求的管理與測(cè)試人員對(duì)需求的理解，以及對(duì)基礎(chǔ)測(cè)試?yán)碚摰娜笔?br />
從以上的幾個(gè)觀點(diǎn)來(lái)看，可以看出來(lái)文章的作者對(duì)測(cè)試人員還是很存在一定的理解偏差的，他的問(wèn)題主要是把他們公司的測(cè)試一些人員當(dāng)成了整個(gè)軟件測(cè)試行業(yè)！
如果他可以跳出他們公司，去質(zhì)量管理規(guī)范的公司看一看，或許能有極大的改觀，不知道他本身是否認(rèn)可？
“我越來(lái)越覺得軟件開發(fā)，真的不需要專職的 QA，更不需要只寫代碼不懂做測(cè)試的專職的 Dev”
關(guān)于作者的這句話，我不敢完全茍同，我覺得更應(yīng)該這樣說(shuō)：
“我越來(lái)越覺得需要軟件測(cè)試人員，但不需要不專業(yè)的測(cè)試人員，更不需要只寫代碼不懂做測(cè)試的專職的 Dev”
我為什么我不說(shuō)“我們需要專業(yè)的測(cè)試人員”而不是說(shuō)“我們需要懂開發(fā)的測(cè)試人員”？
專業(yè)，包括懂需求、懂開發(fā)、懂測(cè)試?yán)碚摰娜藛T，也包括懂業(yè)務(wù)、懂需求、懂測(cè)試?yán)碚摰臏y(cè)試人員，這兩者都是我們需要的優(yōu)秀的測(cè)試人員！
“1） 開發(fā)人員做測(cè)試更有效
開發(fā)人員本來(lái)就要測(cè)試自己寫的軟件，如果開發(fā)人員不懂測(cè)試，或是對(duì)測(cè)試不專業(yè)，那么這就不是一個(gè)專業(yè)的開發(fā)人員。
開發(fā)人員了解整個(gè)軟件的設(shè)計(jì)和開發(fā)過(guò)程，開發(fā)人員是最清楚應(yīng)該怎么測(cè)試的，這包括單元測(cè)試，功能測(cè)試，性能測(cè)試，回歸測(cè)試，以及 Soak Test 等。
開發(fā)人員知道怎么測(cè)試是最有效的。開發(fā)人員知道所有的 function point，知道 fix 一個(gè) bug 后，哪些測(cè)試要做回歸和驗(yàn)證，哪些不需要。開發(fā)人員的技術(shù)能力知道怎么才能更好的做測(cè)試。
很多開發(fā)人員只喜歡寫代碼，不喜歡做測(cè)試，或是他們說(shuō)，開發(fā)人員應(yīng)該關(guān)注于開發(fā)，而不是測(cè)試。這個(gè)思路相當(dāng)?shù)腻e(cuò)誤。開發(fā)人員最應(yīng)該關(guān)注的是軟件質(zhì)量，需要證明自己的開發(fā)成果的質(zhì)量。開發(fā)人員如果都不知道怎么做測(cè)試，這個(gè)開發(fā)人員就是一個(gè)不合格的開發(fā)人員。
另外，我始終不明白，為什么不做開發(fā)的 QA 會(huì)比 Dev 在測(cè)試上更專業(yè)？ 這一點(diǎn)都說(shuō)不通啊。”
聞道有先后，術(shù)業(yè)有專攻！
首先我對(duì)寫下這段文字的Dev表示我的景仰，你能說(shuō)出這番話說(shuō)明你還是對(duì)軟件測(cè)試、對(duì)軟件質(zhì)量、對(duì)Dev本身的測(cè)試還是有一定的了解和意識(shí)的。
但是，要知道軟件測(cè)試也是一個(gè)系統(tǒng)的過(guò)程，和軟件開發(fā)一樣，他有一個(gè)長(zhǎng)期的過(guò)程，開發(fā)人員通經(jīng)系統(tǒng)、完善的培訓(xùn)或者可以成為一個(gè)優(yōu)秀的測(cè)試人員，這個(gè)不虛假；但是術(shù)業(yè)有專攻，開發(fā)人員專攻的是開發(fā)，測(cè)試人員專攻的是測(cè)試（最最好是彼此都有一些了解）。開發(fā)人員要進(jìn)行的測(cè)試是對(duì)基礎(chǔ)功能的粗略測(cè)試，因?yàn)樗懈匾拈_發(fā)工作要去完成，做不到詳細(xì)的完全測(cè)試；而測(cè)試人員一方面要詳細(xì)的對(duì)基礎(chǔ)功能進(jìn)行測(cè)試，還要對(duì)很多很多的細(xì)支末節(jié)進(jìn)行測(cè)試，尤其是平常經(jīng)常使用的或可能會(huì)出現(xiàn)，但一般人很少想到的，在測(cè)試中我們稱之為場(chǎng)景，測(cè)試人員要對(duì)各種可能出現(xiàn)的場(chǎng)景進(jìn)行測(cè)試，往往這種測(cè)試是很煩瑣的。
同時(shí)，專業(yè)的測(cè)試人員和專業(yè)的開發(fā)人員一樣，都是要經(jīng)常系統(tǒng)、完善的培訓(xùn)才能正式以一名合格的測(cè)試人員的身份上崗的，所以說(shuō)，不能單純的去懷疑Tester對(duì)測(cè)試的專業(yè)性……
“2）減少溝通，扯皮，和推諉
想想下面的這些情況你是否似曾相識(shí)？
QA 做的測(cè)試計(jì)劃，測(cè)試案例設(shè)計(jì)，測(cè)試結(jié)果，總是需要 Dev 來(lái)評(píng)審和檢查。（不是說(shuō)測(cè)試需要依賴開發(fā)，這是本身的一個(gè)溝通、交流，是保證質(zhì)量的一個(gè)流程需要，在CMMI\ISO中是有明文的規(guī)定的）
QA 在做測(cè)試的過(guò)程中，總是需要 Dev 對(duì)其測(cè)試的環(huán)境，配置，過(guò)程做指導(dǎo)。（這個(gè)是為了保證測(cè)試的正確性，要是因?yàn)榕渲貌徽_而導(dǎo)致誤報(bào)，當(dāng)如何？）
QA 總是會(huì)和 Dev 爭(zhēng)吵某個(gè)問(wèn)題是不是 BUG，爭(zhēng)吵要不要解決。（是不是缺陷需要相互溝通，需要判斷優(yōu)先級(jí)，需要參考需求，需要領(lǐng)導(dǎo)定奪，而不是開發(fā)和測(cè)試的吵，凡事要有依據(jù)）
無(wú)論發(fā)現(xiàn)什么樣的問(wèn)題，總是 Dev 去解決，QA 從不 fix 問(wèn)題。（Tester fix Bug？部分的缺陷是可以，如果他有開發(fā)的經(jīng)驗(yàn)，但你會(huì)放心么？項(xiàng)目經(jīng)理能放心么，術(shù)業(yè)有專攻）
我們總是能聽到，線上發(fā)生問(wèn)題的時(shí)候，Dev 的抱怨 QA 這樣的問(wèn)題居然沒測(cè)出來(lái)（出現(xiàn)漏測(cè)，是雙方的責(zé)任，不要想到推諉責(zé)任，這樣的人不僅人品存在問(wèn)題，連職業(yè)道德也值得重新審視）
QA 也總會(huì)抱怨 Dev 代碼太差，一點(diǎn)也不懂測(cè)試，沒怎么測(cè)就給 hand over 給 QA 了。（所以說(shuō)開發(fā)要懂測(cè)試，提高交付質(zhì)量，避免低級(jí)錯(cuò)誤，但有偶爾有也是可以理解的，人非圣賢嘛）
QA 總是會(huì) push Dev，這個(gè) bug 再不 fix，你就影響我的進(jìn)度了。（相互理解、支持）
等等，等等。
如果沒有 QA，那么就沒有這么多事了，DEV 自己的干出來(lái)的問(wèn)題，自己處理，沒什么好扯皮的。
而一方面，QA 說(shuō) Dev 不懂測(cè)試，另一方面 Dev 說(shuō) QA 不懂技術(shù)，而我們還要讓他們隔離開來(lái)，各干各的，這一點(diǎn)都不利于把 Dev 和 QA 的代溝給填平了。要讓 Dev 理解 QA，讓 QA 理解 Dev，減少公說(shuō)公有理，婆說(shuō)婆有理的只站在自己立場(chǎng)上的溝通，只有一個(gè)方法，那就是讓 Dev 來(lái)做測(cè)試，讓 QA 來(lái)做開發(fā)。這樣一樣，大家都是程序員了。”
（扯皮，多么俗的字眼，當(dāng)然不是說(shuō)這種情況沒有，但這種情況是不應(yīng)該的，還是那句：相互的溝通、相互的理解、統(tǒng)一的目標(biāo)很重要）
“3）吃自己的狗食
真的優(yōu)秀的開發(fā)團(tuán)隊(duì)都是要吃自己狗食的。這句話的意思是——如果你不能切身體會(huì)到自己干的爛事，自己的痛苦，你就不會(huì)有想要去改進(jìn)的動(dòng)機(jī)。沒有痛苦，就不會(huì)真正地去思考，沒有真正的思考，就沒有真正的進(jìn)步。
在我現(xiàn)在的公司，程序員要干幾乎有的事，從需求分析，設(shè)計(jì)，編碼，集成，測(cè)試，部署，運(yùn)維，OnCall，從頭到尾，因?yàn)椋?br />
只有了解了測(cè)試的難度，你才明白怎么寫出可測(cè)試的軟件，怎么去做測(cè)試的自動(dòng)化和測(cè)試系統(tǒng)。
只有自己真正去運(yùn)維自己的系統(tǒng)，你才知道怎么在程序里寫日志，做監(jiān)控，做統(tǒng)計(jì)……
只有自己去使用自己的系統(tǒng)，你才明白用戶的反饋，用戶的想法，和用戶的需求。
所以，真正的工程師是能真正明白軟件開發(fā)不單單只是 coding，還更要明白整個(gè)軟件工程。只明白或是只喜歡 coding 的，那只是碼農(nóng)，不能稱之為工程師。”
這段的理解，說(shuō)明文章作者對(duì)開發(fā)者自測(cè)還是有比較深的理解，比較重視的！
一個(gè)優(yōu)秀的程序員，不，應(yīng)該是工程師，要知道的、要做的還是很多的！
“關(guān)于 SDET。全稱是 Software Development Engineer on Test。像微軟，Google， Amazon 都有這樣的職位。但我不知道這樣的職位在微軟和 Google 的比例是多少，在 Amazon 是非常少的。那么像這樣的懂開發(fā)的專職測(cè)試可以有嗎？我的答案是可以有！但是，我在想，如果一個(gè)人懂開發(fā)，為什么只讓其專職做測(cè)試呢？這樣的程序員分工合理嗎？把程序分成兩等公民有意義嗎？試問(wèn)有多少懂開發(fā)的程序員愿意只做測(cè)試開發(fā)呢？所以，SDET 在實(shí)際的操作中，更多的還是對(duì)開發(fā)不熟的測(cè)試人員。還是哪句話，不懂開發(fā)的人是做不好測(cè)試的。”
雖然我對(duì)上面的“不懂開發(fā)是做不好測(cè)試的”這句話表示同意，但反過(guò)來(lái)我是不能同意的，是存在需求（業(yè)務(wù)）測(cè)試工程師，也就是說(shuō)他們不懂開發(fā)，但相當(dāng)?shù)木I(yè)務(wù)、需求
只要是對(duì)工作、對(duì)最終的目標(biāo)是合理的，那么怎樣的工作都是需要人去完成的，所以不要認(rèn)為做哪樣工作就不怎么的，這個(gè)可以做為你奮斗的動(dòng)力，但不能作為評(píng)價(jià)一個(gè)人的標(biāo)準(zhǔn)
“如果你說(shuō) Dev 對(duì)測(cè)試不專業(yè)，不細(xì)心，不認(rèn)真，那么我們同樣也無(wú)法保證 QA 的專業(yè)，細(xì)心和認(rèn)真。在 Dev 上可能出現(xiàn)的問(wèn)題，在 QA 也也會(huì)一樣出現(xiàn)。而出了問(wèn)題 QA 不會(huì)來(lái)加班解決，還是開發(fā)人員自己解決。所以，如果 QA 不用來(lái)解決問(wèn)題，那么，QA 怎么可能真正的細(xì)心和認(rèn)真呢？”
是的，都會(huì)出現(xiàn)問(wèn)題，開發(fā)人員開發(fā)代碼時(shí)會(huì)出現(xiàn)問(wèn)題，所以需要測(cè)試；測(cè)試人員測(cè)試會(huì)出現(xiàn)問(wèn)題，所以需要開發(fā)人加班加點(diǎn)解決問(wèn)題；而往往兩者都會(huì)出現(xiàn)問(wèn)題
在這個(gè)問(wèn)題上作者陷入了一個(gè)死循環(huán)中，記住“沒有成功個(gè)人，只有成功的團(tuán)隊(duì)”
“如果你說(shuō)不要 QA 的話，Dev 人手會(huì)不夠。你這樣想一下，如果把你團(tuán)隊(duì)中現(xiàn)有的 QA 全部變成 Dev，然后，大家一起開發(fā)，一起測(cè)試，親密無(wú)間，溝通方便，你會(huì)不會(huì)覺得這樣會(huì)更有效？你有沒有發(fā)現(xiàn)，在重大問(wèn)題上，Dev 可以幫上 QA 的忙，但是 QA 幫不上 Dev 的忙。”
首先肯定作者話，如果能從開發(fā)中轉(zhuǎn)過(guò)來(lái)部分專業(yè)的測(cè)試人員，這樣對(duì)于項(xiàng)目肯定是有幫助的，但我們?nèi)匀恍枰|(zhì)量管理體系來(lái)管理，通過(guò)流程來(lái)保證我們的產(chǎn)品/項(xiàng)目質(zhì)量
從文章作者的言語(yǔ)中可以看到他作為開發(fā)人員的優(yōu)越性，而這種優(yōu)越性容易造成的結(jié)果是：“我不應(yīng)該來(lái)做這個(gè)事，我可以做更高級(jí)、更有難度的事”
有人說(shuō)態(tài)度決定一切，雖然我不太贊成這句話，但我也明白一個(gè)人的能力重要，一個(gè)人的心態(tài)也很重要
最后，讓一個(gè)優(yōu)秀的開發(fā)人員做測(cè)試確實(shí)有些浪費(fèi)，公司損失不起
“第三方中立，你會(huì)說(shuō)人總是測(cè)不好自己寫的東西，因?yàn)橛兴季S定式。沒錯(cuò)，我同意。但是如果是 Dev 交叉測(cè)試呢？你可能會(huì)說(shuō)開發(fā)人員會(huì)有開發(fā)人員的思維定式。那這只能說(shuō)明開發(fā)人員還不成熟，他們還不合格。沒關(guān)系，只要吃自己的狗食，痛苦了，就會(huì)負(fù)責(zé)的。”
思維定式、個(gè)人習(xí)慣、自我保護(hù)意識(shí)是三個(gè)魔鬼
當(dāng)然測(cè)試人員也有這三個(gè)魔鬼，所以測(cè)試負(fù)責(zé)人在安排測(cè)試時(shí)，一般會(huì)交叉測(cè)試，具體的涉及到測(cè)試策略的問(wèn)題，就不在這里說(shuō)了
越多的測(cè)試越能保證產(chǎn)品的質(zhì)量，所以一般都會(huì)要求開發(fā)人員對(duì)自己的程序進(jìn)行測(cè)試，會(huì)有代碼評(píng)審，會(huì)有同行評(píng)審，其中的原因也就不言而喻
“磨刀不誤砍柴功。如果你開發(fā)的東西自己在用，那么自己就是自己天然的 QA，如果有別的團(tuán)隊(duì)也在用你開發(fā)的模塊，那么，別的團(tuán)隊(duì)也就很自然地在幫你做測(cè)試了，而且是最真實(shí)的測(cè)試。”
說(shuō)的沒有錯(cuò)，是測(cè)試，但是不完全的測(cè)試，對(duì)于質(zhì)量我們追求的是質(zhì)量的零缺陷，雖然那不可能實(shí)現(xiàn)，而實(shí)現(xiàn)的基礎(chǔ)是專業(yè)、系統(tǒng)、完整的測(cè)試
“關(guān)于自動(dòng)化測(cè)試。所謂自動(dòng)化的意思是，這是一個(gè)機(jī)械的重復(fù)勞動(dòng)，我想讓測(cè)試人員思考一下，你是否在干這樣的事？如果你正在干這樣的事，那么，你要思考一下你的價(jià)值了。但凡是重復(fù)性比較高的機(jī)械性的勞動(dòng)，總有一天都會(huì)被機(jī)器取代的。”
知道為什么人沒有被機(jī)器人替代么？
因?yàn)槿擞袩o(wú)窮無(wú)盡的思想
“關(guān)于線上測(cè)試。我們都知道，無(wú)論自己內(nèi)測(cè)的怎么樣，到了用戶那邊，總是會(huì)有一些測(cè)試不到的東西。所以，有些公司會(huì)整出個(gè) UAT，用戶驗(yàn)收測(cè)試。做產(chǎn)品的公司會(huì)叫 Beta 測(cè)試。無(wú)論怎么樣，你總是要上生產(chǎn)線做測(cè)試的。對(duì)于互聯(lián)網(wǎng)企業(yè)來(lái)說(shuō)，生產(chǎn)線上測(cè)試有的玩A/B測(cè)試，有的玩部分用戶測(cè)試，比如，新上線的功能只有 10% 的用戶可以訪問(wèn)得到，這樣不會(huì)因?yàn)槌鰡?wèn)題讓全部用戶受到影響。做這種測(cè)試的人必然是開發(fā)人員。”
UAT是用戶會(huì)要求進(jìn)行的，如果不做接收測(cè)試，客戶不滿意你的項(xiàng)目，后期的款項(xiàng)如何收回？
Beta測(cè)試一方面是通過(guò)線上的真實(shí)情況，檢查程序的功能、性能，同時(shí)也是對(duì)市場(chǎng)的試探、對(duì)用戶的試探，觀察市場(chǎng)、用戶對(duì)產(chǎn)品的響應(yīng)，為公司的后期決策做以參考。
寫在結(jié)尾：
對(duì)于你的耐心，Tester Chen很感謝，成文時(shí)間倉(cāng)促，如有不妥，希望留下你寶貴的意見、建議。