|
讓我們思考幾個常見的問題：
先閉目冥想五分鐘吧,，然后可以嘗試著回答上面的問題,。 計算機先驅(qū) Maurice Wikes 回憶起 1949 年他在英國劍橋工作的情形，在拖著打孔紙帶上樓給雛形計算機 EDASC 裝載程序時,，他看到了自己的未來： 我強烈的意識到,，生命中剩下的好日子，都將耗費在給自己的程序找錯誤上頭,。Maurice Wikes告訴我們,，沒有完美的軟件。 我在我的微信訂閱號“程序視界”里發(fā)布過一篇薦書文,，推薦了溫伯格技術思想三部曲中的《顛覆完美軟件：:軟件測試必須知道的幾件事》,。在這本書里，溫伯格也告訴我們,，沒有完美的軟件,。所有的開發(fā)和測試人員都應該讀讀那本書。 溫伯格在《顛覆完美軟件》中幾乎討論所有常見的與軟件測試相關的概念,、問題和指導思想,，所以，在這篇文章里,，我只能來吐槽啦,，我將從以下幾方面列一些常見的現(xiàn)象，希望能引起大家的思考,。
測試和開發(fā)的關系測試和開發(fā)是對立的嗎,？ 從處理Bug的角度看，似乎可以這么說,。開發(fā)人員既生產(chǎn)代碼,，也生產(chǎn)Bug。因為開發(fā)人員不可避免地會生產(chǎn)Bug,，所以測試人員必須存在,，以便在軟件交付之前盡可能多地檢出Bug，保證交付給客戶的軟件質(zhì)量更好一些,。一個產(chǎn)Bug,，一個挑Bug,，看起來似乎是對立的。 在現(xiàn)實中,，很多測試團隊和開發(fā)團隊也正是因為這一點而搞得關系不和,，甚至真的對立起來。請回想一下你周圍發(fā)生的與開發(fā)和測試相關的事兒,，看看有沒有遇到過下面的情景：
許許多多類似的問題,，讓開發(fā)和測試的關系從撲朔迷離、相愛相殺走向?qū)α?。我見過開發(fā)和測試搞冷戰(zhàn)某人遇見某人側(cè)臉而過,，也見過測試經(jīng)理和開發(fā)經(jīng)理打架，還見過高層領導故意讓測試團隊和開發(fā)團隊關系緊張以為這樣可以提高測試效率也能給開發(fā)壓力最終會產(chǎn)出更高質(zhì)量的軟件…… 實際上,，測試和開發(fā)擁有同一個目的：讓軟件更完美,。測試和開發(fā)的關系，是一個問題的兩面,，應該是相輔相成和平共處的,。測試不是為了挑刺兒，他提出的問題也不針對生產(chǎn)軟件的開發(fā)人員,，而僅僅是在努力想讓開發(fā)人員的產(chǎn)出物看起來更好用,。只要開發(fā)不將測試提Bug這個行為看成針對個人的行為，一切就有了美好的前提,。 否定軟件,，并不是否定開發(fā)軟件的人。這是開發(fā)和測試都需要明確的一個原則和前提,。 還有的人認為開發(fā)和測試之關系類似皮與毛,，皮之不存毛將焉附？所以有的開發(fā)也會因此而有優(yōu)越感：沒我們寫軟件，你們測試早下崗了,！可是，開發(fā)不寫軟件,，開發(fā)也下崗了耶,！ 感謝開發(fā)的不完美，讓測試可以有事可做并練就慧眼,。 感謝測試的認真細致和耐心體貼,，讓開發(fā)可以發(fā)現(xiàn)自己的不完美并有機會提升自己——那些說我軟件不好的，都是為了我好,。 資源
有時開發(fā)和測試之間也會有資源上的沖突,，要有努力的有創(chuàng)造性的解決（我可以負責任地說,，裝黑蘋果不是好辦法），不要讓大家伙的工作卡在環(huán)境上,，這是管理者要解決的基本問題,。我見過很多非常棒的一線經(jīng)理，在現(xiàn)實制約下,，主動把自己的手機,、iPad都貢獻出來當做測試設備。這也是解決資源問題的一種辦法哦,。 流程與標準你身邊的人員會這么抱怨嗎：
Ok，如果你身邊的開發(fā)和測試從來沒有過類似的問題,，那很好,，恭喜你，看來你們的團隊人nice協(xié)作也很順暢,，棒棒噠,。 假如你身邊充斥著這樣嘈雜的抱怨，那說明什么呢,？開發(fā),、測試、發(fā)布這一套流程有問題,？還是團隊缺乏明確的指向來引導大家向積極,、有效的行為靠近？ 流程和標準總是有待解釋的,，再好的規(guī)則,，歪嘴和尚也能把它念斜…… 我們隨便挑一個問題吧：為什么開發(fā)寫完代碼測都不測就扔給我們？這個問題普遍存在,，它反映出的是程序員和測試人員的工作邊界難以界定的矛盾,。 程序員會說，我都測一遍,，還要你們測試做什么,？ 測試會說，你測都不測,，冒煙都過不了,，有沒有責任心？ 程序員說，要我寫測試用例,，搭各種環(huán)境,，遍歷各種正常、異常邏輯,，我還有沒有時間寫代碼了,？ 測試會說，我們測試是垃圾桶嗎,，什么爛玩意兒都直接扔給我們，我們的時間就那么不值錢,？ 開發(fā)會說,，測試本來就是干這個的，你不測誰測,？ …… 像這樣的問題,，能制定一個標準，說明什么樣的邏輯開發(fā)要自測覆蓋什么樣的邏輯可以交給測試來測,？能畫一條三八線嗎,？ 不能。所以,，這個時候,，靠譜的一線管理者就顯得很重要。如何創(chuàng)造性的發(fā)現(xiàn)適合團隊的方法來讓大家順暢地協(xié)同工作,，比標準,、制度更重要，這往往依賴于技術管理者的能力和團隊成員的意識,。沒有普適的方法,，只有適合這個組織的、此時此地的策略,，加油吧,，在戰(zhàn)斗中摸索出最適合當下的道路。 那什么是靠譜的一線管理者呢,？ 溫伯格《成為技術領導者》一書中對領導職責的定義如下： 領導的職責就是創(chuàng)造這樣一個環(huán)境,，每個人都能在其中發(fā)揮出更多的能力。如果一個技術領導帶領的團隊,，大部分人都能專心做與其能力適配的事情而不用整天泡在與本節(jié)前面所列類似的問題里,，那他基本上就算是比較靠譜了。 至于像給測試預留多長的測試周期,、調(diào)整設計要不要通知測試,、需求調(diào)整要不要測試參與等問題，合理的流程和標準可以起到很大的輔助作用，技術領導者只要依據(jù)合理的制度,，引導大家有效參與,，就可以化解。 態(tài)度場景一： 測試MM對阿猿說發(fā)現(xiàn)了一個Bug,。
阿猿矢口否認：不可能,，絕對不可能！
MM：真的有Bug,，你過來看一下,！
阿猿：我都不用看，在我這兒好好兒的,。
MM：你來看一下嘛……
阿猿：看什么看,，肯定你環(huán)境問題，動什么東西了嗎,？重啟了嗎,？場景二： 測試MM想在jira上提個Bug，先在QQ上對阿猿說：有個Bug,，你過來看下,？
阿猿：忙著呢，焦頭爛額的,。
MM：一分鐘都用不了,，你來看下吧。
阿猿：思路一打斷就不好恢復了,，等會兒,！
MM：你不看我提到jira上了啊。
阿猿：隨便,，你不就是愛提Bug嘛,。場景三： 測試MM呼叫阿猿：阿猿阿猿，程序又崩潰了,，快來看看,！
阿猿慢騰騰地起身過來，鼠標點幾下：看不出來什么問題,，你怎么操作的,？
MM：這樣點一下，那樣,，這樣,，……回車……。
阿猿：重現(xiàn)不了啊,，你想辦法重現(xiàn),，重現(xiàn)了再叫我,，我忙著呢。
MM：…… |
|
|
