流程與標準
你身邊的人員會這么抱怨嗎:
我們一報Bug,開發就說用戶根本不可能這么用,還說不知道我們怎么會這么測
送測單里根本不寫測試范圍或者寥寥幾句跟沒寫一樣
開發調整設計從來也不告訴我們
為什么產品經理和UI只和開發討論需求變更?
為什么發布計劃里不給測試預留測試時間?
為什么開發寫完代碼測都不測就扔給我們?
為什么客戶那里發現了問題老問是誰測的、為什么沒測出來?
測試老是一聲不吭就把Bug優先級設置為Major
測試總是把大量時間花在用戶根本不可能用到的功能上
測試分不清哪些什么是重點,你給他說他還老是一堆道理這了那了
測試提的Bug,現象描述也不準確,重現步驟也沒有,有的根本就知道是不是誤操作
測試老來打斷我,一會兒叫一下一會兒叫一下,根本沒辦法專注開發
jira上的Bug重復率太高,一個問題提N遍,難道就不能合并一下?
測試發現Bug,一聲招呼都不打就直接告訴老板了,搞得我很被動
測試就是專門挑刺兒的,有勁不往正地兒使,你倒是測測用戶常用的功能啊
那么簡單的Bug都能流出到用戶那里,真不知道測試怎么測的
開發老嫌測試報告數據不漂亮,逼著我們調整
Ok,如果你身邊的開發和測試從來沒有過類似的問題,那很好,恭喜你,看來你們的團隊人nice協作也很順暢,棒棒噠。
假如你身邊充斥著這樣嘈雜的抱怨,那說明什么呢?開發、測試、發布這一套流程有問題?還是團隊缺乏明確的指向來引導大家向積極、有效的行為靠近?
流程和標準總是有待解釋的,再好的規則,歪嘴和尚也能把它念斜……
我們隨便挑一個問題吧:為什么開發寫完代碼測都不測就扔給我們?這個問題普遍存在,它反映出的是程序員和測試人員的工作邊界難以界定的矛盾。
程序員會說,我都測一遍,還要你們測試做什么?
測試會說,你測都不測,冒煙都過不了,有沒有責任心?
程序員說,要我寫測試用例,搭各種環境,遍歷各種正常、異常邏輯,我還有沒有時間寫代碼了?
測試會說,我們測試是垃圾桶嗎,什么爛玩意兒都直接扔給我們,我們的時間就那么不值錢?
開發會說,測試本來就是干這個的,你不測誰測?
……
像這樣的問題,能制定一個標準,說明什么樣的邏輯開發要自測覆蓋什么樣的邏輯可以交給測試來測?能畫一條三八線嗎?
不能。所以,這個時候,靠譜的一線管理者就顯得很重要。如何創造性的發現適合團隊的方法來讓大家順暢地協同工作,比標準、制度更重要,這往往依賴于技術管理者的能力和團隊成員的意識。沒有普適的方法,只有適合這個組織的、此時此地的策略,加油吧,在戰斗中摸索出最適合當下的道路。
那什么是靠譜的一線管理者呢?
溫伯格《成為技術領導者》一書中對領導職責的定義如下:
領導的職責就是創造這樣一個環境,每個人都能在其中發揮出更多的能力。
如果一個技術領導帶領的團隊,大部分人都能專心做與其能力適配的事情而不用整天泡在與本節前面所列類似的問題里,那他基本上就算是比較靠譜了。
至于像給測試預留多長的測試周期、調整設計要不要通知測試、需求調整要不要測試參與等問題,合理的流程和標準可以起到很大的輔助作用,技術領導者只要依據合理的制度,引導大家有效參與,就可以化解。
態度
場景一:
測試MM對阿猿說發現了一個Bug。
阿猿矢口否認:不可能,絕對不可能!
MM:真的有Bug,你過來看一下!
阿猿:我都不用看,在我這兒好好兒的。
MM:你來看一下嘛……
阿猿:看什么看,肯定你環境問題,動什么東西了嗎?重啟了嗎?
場景二:
測試MM想在jira上提個Bug,先在QQ上對阿猿說:有個Bug,你過來看下?
阿猿:忙著呢,焦頭爛額的。
MM:一分鐘都用不了,你來看下吧。
原文轉自:http://www.testwo.com/article/641