讓我們思考幾個常見的問題：
軟件測試的目的是什么？
開發人員能否構建出沒有Bug的完美軟件？
測人人員和開發人員是什么關系？
軟件測試能否保證軟件質量？
先閉目冥想五分鐘吧，然后可以嘗試著回答上面的問題。
計算機先驅 Maurice Wikes 回憶起 1949 年他在英國劍橋工作的情形，在拖著打孔紙帶上樓給雛形計算機 EDASC 裝載程序時，他看到了自己的未來：
我強烈的意識到，生命中剩下的好日子，都將耗費在給自己的程序找錯誤上頭。
Maurice Wikes告訴我們，沒有完美的軟件。
我曾經寫過一篇薦書文，推薦了溫伯格技術思想三部曲中的《顛覆完美軟件：軟件測試必須知道的幾件事》。在這本書里，溫伯格也告訴我們，沒有完美的軟件。所有的開發和測試人員都應該讀讀那本書。
溫伯格在《顛覆完美軟件》中幾乎討論所有常見的與軟件測試相關的概念、問題和指導思想，所以，在這篇文章里，我只能來吐槽啦，我將從以下幾方面列一些常見的現象，希望能引起大家的思考。
測試和開發的關系
測試和開發是對立的嗎？
從處理Bug的角度看，似乎可以這么說。開發人員既生產代碼，也生產Bug。因為開發人員不可避免地會生產Bug，所以測試人員必須存在，以便在軟件交付之前盡可能多地檢出Bug，保證交付給客戶的軟件質量更好一些。一個產Bug，一個挑Bug，看起來似乎是對立的。
在現實中，很多測試團隊和開發團隊也正是因為這一點而搞得關系不和，甚至真的對立起來。請回想一下你周圍發生的與開發和測試相關的事兒，看看有沒有遇到過下面的情景：
開發說，測試凈找麻煩，客戶跟本不可能像他們那樣使用軟件
測試說，問題總是會在看似極端的條件下產生，用戶總是會不經意觸碰到看似極端的不可能出現的條件
開發說，測試花在異常情況下的精力比測試主流程還多，不知道輕重緩急
測試說，開發從來不考慮測試的感受，連測都不測就扔給我們
開發說，我都測了，還要測試人員干什么
測試說，這么明顯的問題你們都不測一下，把我們測試當垃圾桶啊
……
許許多多類似的問題，讓開發和測試的關系從撲朔迷離、相愛相殺走向對立。我見過開發和測試搞冷戰某人遇見某人側臉而過，也見過測試經理和開發經理打架，還見過高層領導故意讓測試團隊和開發團隊關系緊張以為這樣可以提高測試效率也能給開發壓力最終會產出更高質量的軟件……
實際上，測試和開發擁有同一個目的：讓軟件更完美。測試和開發的關系，是一個問題的兩面，應該是相輔相成和平共處的。測試不是為了挑刺兒，他提出的問題也不針對生產軟件的開發人員，而僅僅是在努力想讓開發人員的產出物看起來更好用。只要開發不將測試提Bug這個行為看成針對個人的行為，一切就有了美好的前提。
否定軟件，并不是否定開發軟件的人。這是開發和測試都需要明確的一個原則和前提。
還有的人認為開發和測試之關系類似皮與毛，皮之不存毛將焉附？所以有的開發也會因此而有優越感：沒我們寫軟件，你們測試早下崗了！可是，開發不寫軟件，開發也下崗了耶！
感謝開發的不完美，讓測試可以有事可做并練就慧眼。
感謝測試的認真細致和耐心體貼，讓開發可以發現自己的不完美并有機會提升自己——那些說我軟件不好的，都是為了我好。
資源
別動我們測試的服務器，你們自己搭一個！
我們沒環境，不用你們的用誰的？
誰把我們的測試手機拿走了？你們申請一個嘛，老來占我們設備。
誰在用我們的賬號？招呼都不打！我要用，趕緊退出來！
有時開發和測試之間也會有資源上的沖突，要有努力的有創造性的解決（我可以負責任地說，裝黑蘋果不是好辦法），不要讓大家伙的工作卡在環境上，這是管理者要解決的基本問題。我見過很多非常棒的一線經理，在現實制約下，主動把自己的手機、iPad都貢獻出來當做測試設備。這也是解決資源問題的一種辦法哦。
流程與標準
你身邊的人員會這么抱怨嗎：
開發根本不看我們的測試用例，評審郵件從來就不回復
我們一報Bug，開發就說用戶根本不可能這么用，還說不知道我們怎么會這么測
送測單里根本不寫測試范圍或者寥寥幾句跟沒寫一樣
開發調整設計從來也不告訴我們
為什么產品經理和UI只和開發討論需求變更？
為什么發布計劃里不給測試預留測試時間？
為什么開發寫完代碼測都不測就扔給我們？
為什么客戶那里發現了問題老問是誰測的、為什么沒測出來？
測試老是一聲不吭就把Bug優先級設置為Major
測試總是把大量時間花在用戶根本不可能用到的功能上
測試分不清哪些什么是重點，你給他說他還老是一堆道理這了那了
測試提的Bug，現象描述也不準確，重現步驟也沒有，有的根本就知道是不是誤操作
測試老來打斷我，一會兒叫一下一會兒叫一下，根本沒辦法專注開發
jira上的Bug重復率太高，一個問題提N遍，難道就不能合并一下？
測試發現Bug，一聲招呼都不打就直接告訴老板了，搞得我很被動
測試就是專門挑刺兒的，有勁不往正地兒使，你倒是測測用戶常用的功能啊
那么簡單的Bug都能流出到用戶那里，真不知道測試怎么測的
開發老嫌測試報告數據不漂亮，逼著我們調整
Ok，如果你身邊的開發和測試從來沒有過類似的問題，那很好，恭喜你，看來你們的團隊人nice協作也很順暢，棒棒噠。
假如你身邊充斥著這樣嘈雜的抱怨，那說明什么呢？開發、測試、發布這一套流程有問題？還是團隊缺乏明確的指向來引導大家向積極、有效的行為靠近？
流程和標準總是有待解釋的，再好的規則，歪嘴和尚也能把它念斜……
我們隨便挑一個問題吧：為什么開發寫完代碼測都不測就扔給我們？這個問題普遍存在，它反映出的是程序員和測試人員的工作邊界難以界定的矛盾。
程序員會說，我都測一遍，還要你們測試做什么？
測試會說，你測都不測，冒煙都過不了，有沒有責任心？
程序員說，要我寫測試用例，搭各種環境，遍歷各種正常、異常邏輯，我還有沒有時間寫代碼了？
測試會說，我們測試是垃圾桶嗎，什么爛玩意兒都直接扔給我們，我們的時間就那么不值錢？
開發會說，測試本來就是干這個的，你不測誰測？
……
像這樣的問題，能制定一個標準，說明什么樣的邏輯開發要自測覆蓋什么樣的邏輯可以交給測試來測？能畫一條三八線嗎？
不能。所以，這個時候，靠譜的一線管理者就顯得很重要。如何創造性的發現適合團隊的方法來讓大家順暢地協同工作，比標準、制度更重要，這往往依賴于技術管理者的能力和團隊成員的意識。沒有普適的方法，只有適合這個組織的、此時此地的策略，加油吧，在戰斗中摸索出最適合當下的道路。
那什么是靠譜的一線管理者呢？
溫伯格《成為技術領導者》一書中對領導職責的定義如下：
領導的職責就是創造這樣一個環境，每個人都能在其中發揮出更多的能力。
如果一個技術領導帶領的團隊，大部分人都能專心做與其能力適配的事情而不用整天泡在與本節前面所列類似的問題里，那他基本上就算是比較靠譜了。
至于像給測試預留多長的測試周期、調整設計要不要通知測試、需求調整要不要測試參與等問題，合理的流程和標準可以起到很大的輔助作用，技術領導者只要依據合理的制度，引導大家有效參與，就可以化解。
態度
場景一：
測試MM對阿猿說發現了一個Bug。 阿猿矢口否認：不可能，絕對不可能！ MM：真的有Bug，你過來看一下！ 阿猿：我都不用看，在我這兒好好兒的。 MM：你來看一下嘛…… 阿猿：看什么看，肯定你環境問題，動什么東西了嗎？重啟了嗎？
場景二：
測試MM想在jira上提個Bug，先在QQ上對阿猿說：有個Bug，你過來看下？ 阿猿：忙著呢，焦頭爛額的。 MM：一分鐘都用不了，你來看下吧。 阿猿：思路一打斷就不好恢復了，等會兒！ MM：你不看我提到jira上了啊。 阿猿：隨便，你不就是愛提Bug嘛。
場景三：
測試MM呼叫阿猿：阿猿阿猿，程序又崩潰了，快來看看！ 阿猿慢騰騰地起身過來，鼠標點幾下：看不出來什么問題，你怎么操作的？ MM：這樣點一下，那樣，這樣，……回車……。 阿猿：重現不了啊，你想辦法重現，重現了再叫我，我忙著呢。 MM：……
我曾經畫過一張暴漫，以“她發現了一個Bug”為題發布在微信訂閱號“程序視界”里，再現類似的場景，感興趣的可以在訂閱號內回復10019查看（點擊訂閱號底部的幫助菜單里的“所有文章”子菜單也能找到）。
開發和測試的日常工作中，上面的情景不斷上演，這其中有一部分原因來自態度。我們有時還能聽到類似下面的話：
有時，有一些開發人員會用技術優勢藐視測試，認為測試工作技術含量低，內心認為測試是附屬沒地位，說話就不太客氣……測試會感覺到，反過來也會對開發有意見……就這么，從相敬如賓開始走向嫌怨叢生……
有個朋友的QQ簽名檔是：沒有自我，只有大道。我琢磨，放在軟件項目里，也挺適用的。
其實，開發和測試擁有共同的目的：生產高質量軟件。具體說，每一個產品、項目、版本都有明確的目標，這些目標是屬于開發和測試的，是大家的。我們把共同的目標牢記在心，擺在首位，我們還要想著別人所做的一切，都是針對軟件本身，都是在為目標而努力，這樣就心平氣和多了，就容易從當下的泥沼中超脫出來，求同存異共同前進。
作者：foruok 微信訂閱號“程序視界”(programmer_sight)
原文：CSDN