從嘗試定義測試開始聽上去不錯,至少可以作為起點。但是,測試通常聽上去更像筆頭工作,是一個低價值的角色,很可能被外包。這里,我會分享一些掌控軟件測試事業(yè)的方式?,F(xiàn)在是管理層將測試看為能夠增加更多價值的角色的時候了,測試人員也應該能夠造成更大的影響力。
測試人員到底做什么?
幾年前,在SearchSoftwareQuality里,我發(fā)表了一篇文章,關于回答“為什么QA一直是瓶頸所在”這個問題。這篇文章對這個問題可能是不公平的,但是它本來也不需要公平。Tim Lister,我崇拜的一個人,在Better Software大會上的主題演講里提出,軟件測試人員的工作就是只發(fā)布好的東西;而將其他不好的東西打回去。也就是說,當測試人員終止某個工作流時,他們只不過在盡職工作而已。
這是有關測試,或者質(zhì)量保證(QA)的老看法,確保錯誤不會暴露給用戶。這樣的定義設置了與開發(fā)人員的對抗,開發(fā)人員想發(fā)布新代碼,而測試人員,希望確保代碼正確。但是這樣的看法并不是唯一的。軟件測試的上下文驅(qū)動的想法傾向于建議測試能夠向決策制定者通知軟件狀態(tài)。也就是說,測試人員執(zhí)行分析,包括可操作的細節(jié),但是隨后讓管理層來決定怎么處理軟件。隨著交付越來越快,我發(fā)現(xiàn)一些領導并沒有時間或者興趣,來幫助決定哪個bug必須修復。我的目標變成了了解他們,以及他們是怎么想的,從而我們可以做出產(chǎn)品所有者可能會作出的決定。這樣,測試人員成為初級產(chǎn)品所有者,擁有一些產(chǎn)品和特性的權(quán)利。這不是“給高級管理層的信任公告”,它意味著測試人員能夠不受阻礙地更大地影響發(fā)布團隊。
一些公司的軟件測試職業(yè)發(fā)展道路上有“測試架構(gòu)師”的角色,但以我個人的經(jīng)驗,這個角色實際非常困惑。我的朋友Noah Sussman,建議使用另一個角色:QA架構(gòu)師。
QA架構(gòu)師成長之路
人們通常認為測試和質(zhì)量都是為了預防錯誤發(fā)生。產(chǎn)品發(fā)布前,我們要確保軟件足夠好。這讓IT花費了很多時間思考如何部署、什么時候部署、改變控制,等等。如果測試人員會因為錯誤而受罰,他們就會努力工作盡量避免錯誤,從而會減慢整個系統(tǒng)的速度。假定在一個游戲里,你將很多東西堆在平板上,當越堆越高時會崩塌。你的目標是確保沒有東西掉到平板外面。那么在放置每一塊時你就會很小心,這會降低新特性(塊)交付的速度。
另一方面,編程人員,想要拿到平板上越多的塊。
Sussman提出,結(jié)束這樣沖突的解決方法,是讓質(zhì)檢角色最小化失敗的影響。這種理念的一部分和DevOps重合,包括快速部署到快速回滾,監(jiān)控生產(chǎn)環(huán)境以便快速定位問題,臨時環(huán)境回滾以及功能標簽。
不用完全脫離這些想法,我建議——讓軟件測試有益于你的事業(yè)——我們需要擁抱它們,創(chuàng)造出真正的QA架構(gòu)師,他負責在快速變化和預期失敗之下確保系統(tǒng)的穩(wěn)定性??梢詮臍v史數(shù)據(jù)開始:系統(tǒng)多久失敗一次,下線時間多長,以及,如果可能的話,多少人受這樣失敗的影響?
比如,將執(zhí)行持續(xù)交付的團隊和使用兩周沖刺經(jīng)典Scrum團隊作比較。Scrum團隊在新沖刺開始前的周日晚上,將代碼交付到生產(chǎn)環(huán)境。如果在沖刺一第一周的周一早晨發(fā)現(xiàn)bug,那么會將這個bug添加到下個沖刺 backlog里,會在沖刺二里解決,從而在問題發(fā)現(xiàn)的四周后部署到生產(chǎn)環(huán)境里。
實踐持續(xù)交付的團隊會在發(fā)現(xiàn)問題的當天修復問題,這比Scrum團隊快20倍。持續(xù)交付團隊可能會處理10倍bug,但是對客戶只會造成一半的影響。
這些數(shù)字都是理想場數(shù)字,但它們的確和我的實際經(jīng)驗匹配。如果有機會通過關注更快響應問題來改進交付時間,測試人員就能夠成為解決方案的一部分。在一些情況下,測試人員甚至能夠設計解決方案——這對于軟件測試事業(yè)肯定是個好消息。比如,我曾經(jīng)工作過的一家公司,有個技術(shù)人員針對生產(chǎn)環(huán)境編寫自動化的檢查。他們并沒有做太多事情,只是登入系統(tǒng),在循環(huán)里查看某個特定用戶網(wǎng)站,但是他們涵蓋了時間數(shù)據(jù)。當客戶開始抱怨嘗試登陸超時時,這樣的時間數(shù)據(jù)提供了問題發(fā)生時的更為詳細的數(shù)據(jù),并且精確表示了影響有多壞。
最終分析
能夠在測試領域成功的人都擅長于解決無限的問題集,從中分析出幾個核心問題,得到合理的結(jié)論,并且和各方溝通這樣的結(jié)果。這樣的工作和高級管理層的質(zhì)量監(jiān)控工作有所重合。最大的不同在于測試更加接近工作本身;測試人員能夠看到項目實際發(fā)生的情況,以及在咖啡站大家談論的內(nèi)容。高級管理層通常和實際工作沒有什么聯(lián)系,并且依賴于實際完成工作的人員的匯報。這意味著測試能夠充當獨立監(jiān)管員的職責——以最可能的方式。
測試人員作為顧問的方式在傳統(tǒng)擁有測試階段的企業(yè)里可能工作得更好。在每幾周就要交付,甚至更頻繁交付的企業(yè)里,產(chǎn)品質(zhì)量和截止日期更為不確定。這時候,你可能需要系統(tǒng)長期穩(wěn)定性的建議,并且找到衡量和管理方式。無論怎樣,關鍵是要真正負責你自己的流程。找到目前最適合自己和公司的模型,并自定義具體的方法、操作,以及向這個方向前進的想法。
如今很多企業(yè)缺乏測試和質(zhì)量有價值的愿景。這造成了一個真空、空白的區(qū)域。不要僅僅告訴大家應該是什么樣子,而是要采取行動,看看到底會發(fā)生了什么。