1. 程式人生 > >測試與開發(一)

測試與開發(一)

讓我們思考幾個常見的問題:

  • 軟體測試的目的是什麼?
  • 開發人員能否構建出沒有Bug的完美軟體?
  • 測人人員和開發人員是什麼關係?
  • 軟體測試能否保證軟體質量?

先閉目冥想五分鐘吧,然後可以嘗試著回答上面的問題。

計算機先驅 Maurice Wikes 回憶起 1949 年他在英國劍橋工作的情形,在拖著打孔紙帶上樓給雛形計算機 EDASC 裝載程式時,他看到了自己的未來:

我強烈的意識到,生命中剩下的好日子,都將耗費在給自己的程式找錯誤上頭。
  • 1
  • 2

Maurice Wikes告訴我們,沒有完美的軟體。

我在我的微信訂閱號“程式視界”裡釋出過一篇薦書文,推薦了溫伯格技術思想三部曲中的《顛覆完美軟體::軟體測試必須知道的幾件事

》。在這本書裡,溫伯格也告訴我們,沒有完美的軟體。所有的開發和測試人員都應該讀讀那本書。

溫伯格在《顛覆完美軟體》中幾乎討論所有常見的與軟體測試相關的概念、問題和指導思想,所以,在這篇文章裡,我只能來吐槽啦,我將從以下幾方面列一些常見的現象,希望能引起大家的思考。

  • 測試和開發的關係
  • 流程與標準
  • 資源
  • 態度

測試和開發的關係

測試和開發是對立的嗎?

從處理Bug的角度看,似乎可以這麼說。開發人員既生產程式碼,也生產Bug。因為開發人員不可避免地會生產Bug,所以測試人員必須存在,以便在軟體交付之前儘可能多地檢出Bug,保證交付給客戶的軟體質量更好一些。一個產Bug,一個挑Bug,看起來似乎是對立的。

在現實中,很多測試團隊和開發團隊也正是因為這一點而搞得關係不和,甚至真的對立起來。請回想一下你周圍發生的與開發和測試相關的事兒,看看有沒有遇到過下面的情景:

  • 開發說,測試淨找麻煩,客戶跟本不可能像他們那樣使用軟體
  • 測試說,問題總是會在看似極端的條件下產生,使用者總是會不經意觸碰到看似極端的不可能出現的條件
  • 開發說,測試花在異常情況下的精力比測試主流程還多,不知道輕重緩急
  • 測試說,開發從來不考慮測試的感受,連測都不測就扔給我們
  • 開發說,我都測了,還要測試人員幹什麼
  • 測試說,這麼明顯的問題你們都不測一下,把我們測試當垃圾桶啊
  • ……

許許多多類似的問題,讓開發和測試的關係從撲朔迷離、相愛相殺走向對立。我見過開發和測試搞冷戰某人遇見某人側臉而過,也見過測試經理和開發經理打架,還見過高層領導故意讓測試團隊和開發團隊關係緊張以為這樣可以提高測試效率也能給開發壓力最終會產出更高質量的軟體……

實際上,測試和開發擁有同一個目的:讓軟體更完美。測試和開發的關係,是一個問題的兩面,應該是相輔相成和平共處的。測試不是為了挑刺兒,他提出的問題也不針對生產軟體的開發人員,而僅僅是在努力想讓開發人員的產出物看起來更好用。只要開發不將測試提Bug這個行為看成針對個人的行為,一切就有了美好的前提。

否定軟體,並不是否定開發軟體的人。這是開發和測試都需要明確的一個原則和前提。

還有的人認為開發和測試之關係類似皮與毛,皮之不存毛將焉附?所以有的開發也會因此而有優越感:沒我們寫軟體,你們測試早下崗了!可是,開發不寫軟體,開發也下崗了耶!

感謝開發的不完美,讓測試可以有事可做並練就慧眼。

感謝測試的認真細緻和耐心體貼,讓開發可以發現自己的不完美並有機會提升自己——那些說我軟體不好的,都是為了我好。

資源

別動我們測試的伺服器,你們自己搭一個!

我們沒環境,不用你們的用誰的?

誰把我們的測試手機拿走了?你們申請一個嘛,老來佔我們裝置。

誰在用我們的賬號?招呼都不打!我要用,趕緊退出來!

有時開發和測試之間也會有資源上的衝突,要有努力的有創造性的解決(我可以負責任地說,裝黑蘋果不是好辦法),不要讓大傢伙的工作卡在環境上,這是管理者要解決的基本問題。我見過很多非常棒的一線經理,在現實制約下,主動把自己的手機、iPad都貢獻出來當做測試裝置。這也是解決資源問題的一種辦法哦。

流程與標準

你身邊的人員會這麼抱怨嗎:

  • 開發根本不看我們的測試用例,評審郵件從來就不回覆
  • 我們一報Bug,開發就說使用者根本不可能這麼用,還說不知道我們怎麼會這麼測
  • 送測單里根本不寫測試範圍或者寥寥幾句跟沒寫一樣
  • 開發調整設計從來也不告訴我們
  • 為什麼產品經理和UI只和開發討論需求變更?
  • 為什麼釋出計劃裡不給測試預留測試時間?
  • 為什麼開發寫完程式碼測都不測就扔給我們?
  • 為什麼客戶那裡發現了問題老問是誰測的、為什麼沒測出來?
  • 測試老是一聲不吭就把Bug優先順序設定為Major
  • 測試總是把大量時間花在使用者根本不可能用到的功能上
  • 測試分不清哪些什麼是重點,你給他說他還老是一堆道理這了那了
  • 測試提的Bug,現象描述也不準確,重現步驟也沒有,有的根本就知道是不是誤操作
  • 測試老來打斷我,一會兒叫一下一會兒叫一下,根本沒辦法專注開發
  • jira上的Bug重複率太高,一個問題提N遍,難道就不能合併一下?
  • 測試發現Bug,一聲招呼都不打就直接告訴老闆了,搞得我很被動
  • 測試就是專門挑刺兒的,有勁不往正地兒使,你倒是測測使用者常用的功能啊
  • 那麼簡單的Bug都能流出到使用者那裡,真不知道測試怎麼測的
  • 開發老嫌測試報告資料不漂亮,逼著我們調整

Ok,如果你身邊的開發和測試從來沒有過類似的問題,那很好,恭喜你,看來你們的團隊人nice協作也很順暢,棒棒噠。

假如你身邊充斥著這樣嘈雜的抱怨,那說明什麼呢?開發、測試、釋出這一套流程有問題?還是團隊缺乏明確的指向來引導大家向積極、有效的行為靠近?

流程和標準總是有待解釋的,再好的規則,歪嘴和尚也能把它念斜……

我們隨便挑一個問題吧:為什麼開發寫完程式碼測都不測就扔給我們?這個問題普遍存在,它反映出的是程式設計師和測試人員的工作邊界難以界定的矛盾。

程式設計師會說,我都測一遍,還要你們測試做什麼?

測試會說,你測都不測,冒煙都過不了,有沒有責任心?

程式設計師說,要我寫測試用例,搭各種環境,遍歷各種正常、異常邏輯,我還有沒有時間寫程式碼了?

測試會說,我們測試是垃圾桶嗎,什麼爛玩意兒都直接扔給我們,我們的時間就那麼不值錢?

開發會說,測試本來就是幹這個的,你不測誰測?

……

像這樣的問題,能制定一個標準,說明什麼樣的邏輯開發要自測覆蓋什麼樣的邏輯可以交給測試來測?能畫一條三八線嗎?

不能。所以,這個時候,靠譜的一線管理者就顯得很重要。如何創造性的發現適合團隊的方法來讓大家順暢地協同工作,比標準、制度更重要,這往往依賴於技術管理者的能力和團隊成員的意識。沒有普適的方法,只有適合這個組織的、此時此地的策略,加油吧,在戰鬥中摸索出最適合當下的道路。

那什麼是靠譜的一線管理者呢?

溫伯格《成為技術領導者》一書中對領導職責的定義如下:

領導的職責就是創造這樣一個環境,每個人都能在其中發揮出更多的能力。
  • 1
  • 2

如果一個技術領導帶領的團隊,大部分人都能專心做與其能力適配的事情而不用整天泡在與本節前面所列類似的問題裡,那他基本上就算是比較靠譜了。

至於像給測試預留多長的測試周期、調整設計要不要通知測試、需求調整要不要測試參與等問題,合理的流程和標準可以起到很大的輔助作用,技術領導者只要依據合理的制度,引導大家有效參與,就可以化解。

態度

場景一:

測試MM對阿猿說發現了一個Bug。

阿猿矢口否認:不可能,絕對不可能!

MM:真的有Bug,你過來看一下!

阿猿:我都不用看,在我這兒好好兒的。

MM:你來看一下嘛……

阿猿:看什麼看,肯定你環境問題,動什麼東西了嗎?重啟了嗎?
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12

場景二:

測試MM想在jira上提個Bug,先在QQ上對阿猿說:有個Bug,你過來看下?

阿猿:忙著呢,焦頭爛額的。

MM:一分鐘都用不了,你來看下吧。

阿猿:思路一打斷就不好恢復了,等會兒!

MM:你不看我提到jira上了啊。

阿猿:隨便,你不就是愛提Bug嘛。
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12

場景三:

測試MM呼叫阿猿:阿猿阿猿,程式又崩潰了,快來看看!

阿猿慢騰騰地起身過來,滑鼠點幾下:看不出來什麼問題,你怎麼操作的?

MM:這樣點一下,那樣,這樣,……回車……。

阿猿:重現不了啊,你想辦法重現,重現了再叫我,我忙著呢。

MM:……
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10

我曾經畫過一張暴漫,以“她發現了一個Bug”為題釋出在微信訂閱號“程式視界”裡,再現類似的場景,感興趣的可以在訂閱號內回覆10019檢視(點選訂閱號底部的幫助選單裡的“所有文章”子選單也能找到)。

開發和測試的日常工作中,上面的情景不斷上演,這其中有一部分原因來自態度。我們有時還能聽到類似下面的話:

  • 你Bug裡的現象描述根本沒用
  • 你根本就沒理解這個邏輯,給你說不清楚
  • 測試什麼都不懂……
  • 你聽我的,我讓你怎麼測你就怎麼測
  • 你這種測法兒,再好的軟體都經不起你折騰
  • 使用者根本不可能這樣用,你們整來整去淨瞎耽誤工夫
  • 一輪都沒測完,你們就給老闆說可以按期交付沒問題?
  • 你們安排計劃時根本不考慮測試,三天,三天怎麼可能測得完!
  • ……

有時,有一些開發人員會用技術優勢藐視測試,認為測試工作技術含量低,內心認為測試是附屬沒地位,說話就不太客氣……測試會感覺到,反過來也會對開發有意見……就這麼,從相敬如賓開始走向嫌怨叢生……

有個朋友的QQ簽名檔是:沒有自我,只有大道。我琢磨,放在軟體專案裡,也挺適用的。

其實,開發和測試擁有共同的目的:生產高質量軟體。具體說,每一個產品、專案、版本都有明確的目標,這些目標是屬於開發和測試的,是大家的。我們把共同的目標牢記在心,擺在首位,我們還要想著別人所做的一切,都是針對軟體本身,都是在為目標而努力,這樣就心平氣和多了,就容易從當下的泥沼中超脫出來,求同存異共同前進。