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

測(cè)試人員到底做什么?

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

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

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

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

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

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

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

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

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

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

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

最終分析

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

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

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