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

測試人員到底做什么?

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

這是有關(guān)測試，或者質(zhì)量保證(QA)的老看法，確保錯誤不會暴露給用戶。這樣的定義設(shè)置了與開發(fā)人員的對抗，開發(fā)人員想發(fā)布新代碼，而測試人員，希望確保代碼正確。但是這樣的看法并不是唯一的。軟件測試的上下文驅(qū)動的想法傾向于建議測試能夠向決策制定者通知軟件狀態(tài)。也就是說，測試人員執(zhí)行分析，包括可操作的細(xì)節(jié)，但是隨后讓管理層來決定怎么處理軟件。隨著交付越來越快，我發(fā)現(xiàn)一些領(lǐng)導(dǎo)并沒有時間或者興趣，來幫助決定哪個bug必須修復(fù)。我的目標(biāo)變成了了解他們，以及他們是怎么想的，從而我們可以做出產(chǎn)品所有者可能會作出的決定。這樣，測試人員成為初級產(chǎn)品所有者，擁有一些產(chǎn)品和特性的權(quán)利。這不是“給高級管理層的信任公告”，它意味著測試人員能夠不受阻礙地更大地影響發(fā)布團(tuán)隊。

一些公司的軟件測試職業(yè)發(fā)展道路上有“測試架構(gòu)師”的角色，但以我個人的經(jīng)驗，這個角色實際非常困惑。我的朋友Noah Sussman，建議使用另一個角色：QA架構(gòu)師。

QA架構(gòu)師成長之路

人們通常認(rèn)為測試和質(zhì)量都是為了預(yù)防錯誤發(fā)生。產(chǎn)品發(fā)布前，我們要確保軟件足夠好。這讓IT花費(fèi)了很多時間思考如何部署、什么時候部署、改變控制，等等。如果測試人員會因為錯誤而受罰，他們就會努力工作盡量避免錯誤，從而會減慢整個系統(tǒng)的速度。假定在一個游戲里，你將很多東西堆在平板上，當(dāng)越堆越高時會崩塌。你的目標(biāo)是確保沒有東西掉到平板外面。那么在放置每一塊時你就會很小心，這會降低新特性(塊)交付的速度。

另一方面，編程人員，想要拿到平板上越多的塊。

Sussman提出，結(jié)束這樣沖突的解決方法，是讓質(zhì)檢角色最小化失敗的影響。這種理念的一部分和DevOps重合，包括快速部署到快速回滾，監(jiān)控生產(chǎn)環(huán)境以便快速定位問題，臨時環(huán)境回滾以及功能標(biāo)簽。

不用完全脫離這些想法，我建議——讓軟件測試有益于你的事業(yè)——我們需要擁抱它們，創(chuàng)造出真正的QA架構(gòu)師，他負(fù)責(zé)在快速變化和預(yù)期失敗之下確保系統(tǒng)的穩(wěn)定性。可以從歷史數(shù)據(jù)開始：系統(tǒng)多久失敗一次，下線時間多長，以及，如果可能的話，多少人受這樣失敗的影響?

比如，將執(zhí)行持續(xù)交付的團(tuán)隊和使用兩周沖刺經(jīng)典Scrum團(tuán)隊作比較。Scrum團(tuán)隊在新沖刺開始前的周日晚上，將代碼交付到生產(chǎn)環(huán)境。如果在沖刺一第一周的周一早晨發(fā)現(xiàn)bug，那么會將這個bug添加到下個沖刺 backlog里，會在沖刺二里解決，從而在問題發(fā)現(xiàn)的四周后部署到生產(chǎn)環(huán)境里。

實踐持續(xù)交付的團(tuán)隊會在發(fā)現(xiàn)問題的當(dāng)天修復(fù)問題，這比Scrum團(tuán)隊快20倍。持續(xù)交付團(tuán)隊可能會處理10倍bug，但是對客戶只會造成一半的影響。

這些數(shù)字都是理想場數(shù)字，但它們的確和我的實際經(jīng)驗匹配。如果有機(jī)會通過關(guān)注更快響應(yīng)問題來改進(jìn)交付時間，測試人員就能夠成為解決方案的一部分。在一些情況下，測試人員甚至能夠設(shè)計解決方案——這對于軟件測試事業(yè)肯定是個好消息。比如，我曾經(jīng)工作過的一家公司，有個技術(shù)人員針對生產(chǎn)環(huán)境編寫自動化的檢查。他們并沒有做太多事情，只是登入系統(tǒng)，在循環(huán)里查看某個特定用戶網(wǎng)站，但是他們涵蓋了時間數(shù)據(jù)。當(dāng)客戶開始抱怨嘗試登陸超時時，這樣的時間數(shù)據(jù)提供了問題發(fā)生時的更為詳細(xì)的數(shù)據(jù)，并且精確表示了影響有多壞。

最終分析

能夠在測試領(lǐng)域成功的人都擅長于解決無限的問題集，從中分析出幾個核心問題，得到合理的結(jié)論，并且和各方溝通這樣的結(jié)果。這樣的工作和高級管理層的質(zhì)量監(jiān)控工作有所重合。最大的不同在于測試更加接近工作本身;測試人員能夠看到項目實際發(fā)生的情況，以及在咖啡站大家談?wù)摰膬?nèi)容。高級管理層通常和實際工作沒有什么聯(lián)系，并且依賴于實際完成工作的人員的匯報。這意味著測試能夠充當(dāng)獨(dú)立監(jiān)管員的職責(zé)——以最可能的方式。

測試人員作為顧問的方式在傳統(tǒng)擁有測試階段的企業(yè)里可能工作得更好。在每幾周就要交付，甚至更頻繁交付的企業(yè)里，產(chǎn)品質(zhì)量和截止日期更為不確定。這時候，你可能需要系統(tǒng)長期穩(wěn)定性的建議，并且找到衡量和管理方式。無論怎樣，關(guān)鍵是要真正負(fù)責(zé)你自己的流程。找到目前最適合自己和公司的模型，并自定義具體的方法、操作，以及向這個方向前進(jìn)的想法。

如今很多企業(yè)缺乏測試和質(zhì)量有價值的愿景。這造成了一個真空、空白的區(qū)域。不要僅僅告訴大家應(yīng)該是什么樣子，而是要采取行動，看看到底會發(fā)生了什么。