2016年管理好軟體測試事業

從嘗試定義測試開始聽上去不錯至少可以作為起點。但是測試通常聽上去更像筆頭工作是一個低價值的角色很可能被外包。這裡我會分享一些掌控軟體測試事業的方式。現在是管理層將測試看為能夠增加更多價值的角色的時候了測試人員也應該能夠造成更大的影響力。

測試人員到底做什麼?

幾年前在SearchSoftwareQuality裡我發表了一篇文章關於回答“為什麼QA一直是瓶頸所在”這個問題。這篇文章對這個問題可能是不公平的但是它本來也不需要公平。Tim Lister我崇拜的一個人在Better Software大會上的主題演講裡提出軟體測試人員的工作就是隻釋出好的東西;而將其他不好的東西打回去。也就是說當測試人員終止某個工作流時他們只不過在盡職工作而已。

這是有關測試或者質量保證(QA)的老看法確保錯誤不會暴露給使用者。這樣的定義設定了與開發人員的對抗開發人員想釋出新程式碼而測試人員希望確保程式碼正確。但是這樣的看法並不是唯一的。軟體測試的上下文驅動的想法傾向於建議測試能夠向決策制定者通知軟體狀態。也就是說測試人員執行分析包括可操作的細節但是隨後讓管理層來決定怎麼處理軟體。隨著交付越來越快我發現一些領導並沒有時間或者興趣來幫助決定哪個bug必須修復。我的目標變成了瞭解他們以及他們是怎麼想的從而我們可以做出產品所有者可能會作出的決定。這樣測試人員成為初級產品所有者擁有一些產品和特性的權利。這不是“給高階管理層的信任公告”它意味著測試人員能夠不受阻礙地更大地影響釋出團隊。

一些公司的軟體測試職業發展道路上有“測試架構師”的角色但以我個人的經驗這個角色實際非常困惑。我的朋友Noah Sussman建議使用另一個角色QA架構師。

QA架構師成長之路

人們通常認為測試和質量都是為了預防錯誤發生。產品釋出前我們要確保軟體足夠好。這讓IT花費了很多時間思考如何部署、什麼時候部署、改變控制等等。如果測試人員會因為錯誤而受罰他們就會努力工作儘量避免錯誤從而會減慢整個系統的速度。假定在一個遊戲裡你將很多東西堆在平板上當越堆越高時會崩塌。你的目標是確保沒有東西掉到平板外面。那麼在放置每一塊時你就會很小心這會降低新特性(塊)交付的速度。

另一方面程式設計人員想要拿到平板上越多的塊。

Sussman提出結束這樣衝突的解決方法是讓質檢角色最小化失敗的影響。這種理念的一部分和DevOps重合包括快速部署到快速回滾監控生產環境以便快速定位問題臨時環境回滾以及功能標籤。

不用完全脫離這些想法我建議——讓軟體測試有益於你的事業——我們需要擁抱它們創造出真正的QA架構師他負責在快速變化和預期失敗之下確保系統的穩定性。可以從歷史資料開始系統多久失敗一次下線時間多長以及如果可能的話多少人受這樣失敗的影響?

比如將執行持續交付的團隊和使用兩週衝刺經典Scrum團隊作比較。Scrum團隊在新衝刺開始前的週日晚上將程式碼交付到生產環境。如果在衝刺一第一週的週一早晨發現bug那麼會將這個bug新增到下個衝刺 backlog裡會在衝刺二里解決從而在問題發現的四周後部署到生產環境裡。

實踐持續交付的團隊會在發現問題的當天修復問題這比Scrum團隊快20倍。持續交付團隊可能會處理10倍bug但是對客戶只會造成一半的影響。

這些數字都是理想場數字但它們的確和我的實際經驗匹配。如果有機會通過關注更快響應問題來改進交付時間測試人員就能夠成為解決方案的一部分。在一些情況下測試人員甚至能夠設計解決方案——這對於軟體測試事業肯定是個好訊息。比如我曾經工作過的一家公司有個技術人員針對生產環境編寫自動化的檢查。他們並沒有做太多事情只是登入系統在迴圈裡檢視某個特定使用者網站但是他們涵蓋了時間資料。當客戶開始抱怨嘗試登陸超時時這樣的時間資料提供了問題發生時的更為詳細的資料並且精確表示了影響有多壞。

最終分析

能夠在測試領域成功的人都擅長於解決無限的問題集從中分析出幾個核心問題得到合理的結論並且和各方溝通這樣的結果。這樣的工作和高階管理層的質量監控工作有所重合。最大的不同在於測試更加接近工作本身;測試人員能夠看到專案實際發生的情況以及在咖啡站大家談論的內容。高階管理層通常和實際工作沒有什麼聯絡並且依賴於實際完成工作的人員的彙報。這意味著測試能夠充當獨立監管員的職責——以最可能的方式。

測試人員作為顧問的方式在傳統擁有測試階段的企業裡可能工作得更好。在每幾周就要交付甚至更頻繁交付的企業裡產品質量和截止日期更為不確定。這時候你可能需要系統長期穩定性的建議並且找到衡量和管理方式。無論怎樣關鍵是要真正負責你自己的流程。找到目前最適合自己和公司的模型並自定義具體的方法、操作以及向這個方向前進的想法。

如今很多企業缺乏測試和質量有價值的願景。這造成了一個真空、空白的區域。不要僅僅告訴大家應該是什麼樣子而是要採取行動看看到底會發生了什麼。

本文轉自d1net轉載