視野的缺乏

毫無疑問，測試自動化最有危險的隱患是缺乏視野。一個連貫的視野產(chǎn)生一幅詳細的地圖---某種脆弱的你的團隊可以開始剖析和理解的東西。沒有那幅共享的理解，團隊們經(jīng)常在一個項目的生命周期里表現(xiàn)出漫無目的的情。盡管他們可能坐得很近，但是一個團隊可能跟下一個團隊的策略不同。其他團隊可能在做重復工作。另外一個可能完全在往錯誤的方向發(fā)展。更糟糕的是，團隊們可能在建造一些最終會被忽略或放棄的不可維護的東西。洞察力應當是簡單的并且清晰地闡述它的目標。主要的目標是去創(chuàng)建一個回歸套給予你的團隊信心當他們在重構程序的時候能夠發(fā)現(xiàn)缺陷。

重構舊的代碼沒有一個自動化安全網(wǎng)會是很危險的。它可能會有不可預見的質量后果，尤其是當處理那種過于復雜的不愿用手“摸”的代碼時。開發(fā)團隊和他們的產(chǎn)品擁有者需要有平靜的大腦讓他們無所顧忌地不用負面影響顧客體驗地重構程序。另外一個重要的目標是你的自動化測試套應當將你的測試人員從重復手工執(zhí)行回歸用例中解放出來。這種解放會允許你的團隊將精力集中在更有深度的探索性測試中。如果你曾經(jīng)多次手動跑過回歸測試，你就知道這最終是一個重復性的會麻木你的知覺和大腦的活動。

自由的測試人員是開心的測試人員，而開心的測試者會發(fā)現(xiàn)更好的缺陷。一個穩(wěn)固的自動化策略應當將你對單元，功能（或服務）和UI測試的預期細節(jié)化。因為每一種類型都有其自己的成本和投資回報，對你團隊應當對每個類型貢獻多少時間具體化。馬克.科恩的自動化三角形象地呈現(xiàn)了每個測試類型的合理比率。不要低估一個有粘聚性的可實現(xiàn)的策略的價值。

它會成為你在專業(yè)，奉獻和團隊合作之旅中的技術指導。

整合聚集

我曾見過三家機構的團隊測試自動化配置。第一和最有毀壞性的是孤狼方式。創(chuàng)建和維護測試的責任降落在一個單一的個人，通常是團隊里最有技術能力的QA工程師。這個人跟其他每個人一樣對手動測試有額外的責任。孤狼方式中使用的自動化工具很可能是由管理層購買的。第三方工具產(chǎn)生錄制-回放自動化用例，且能快速地創(chuàng)建，但是那些測試通常本質脆弱。他們無法擺脫地將用戶界面元素綁定到測試邏輯上，因此保證任何在用戶界面上的小的變動意味著級聯(lián)的測試失敗。對這種等級的測試破壞意味著很多測試將不得不重新錄制，而沒有足夠的時間來解決這些問題因為有其他的測試責任。所以，用戶界面回放測試停留在一個失敗的狀態(tài)。

因為對結果缺乏信心，回歸測試套最終將會被暫停使用。該機構將會把用戶界面測試自動化與失敗關聯(lián)在一起。在不同方面讓團隊信服將會是一場費勁的戰(zhàn)爭。下一個方式是有一個小的，分離的自動化測試團隊與其他團隊分開的方式。簡單的團隊不會將他們最好的做法與組織剩下的人員社交分享。這些團隊也會發(fā)現(xiàn)隨著他們的測試數(shù)增加，維護工作變得不可持續(xù)。不是去開發(fā)新的自動化用例，他們去修復測試問題并且給框架打補丁。他們沒有這種網(wǎng)絡帶寬來創(chuàng)新或者將他們的知識和專業(yè)與其他團隊共享。甚至更危險的是，他們的分離可能導致在所有測試自動化工作上的一種域擁有感和微妙的不愿分享的情緒。給測試自動化支持的最有效率的方式是讓每個人都負起責任來。

在敏捷中，有一種成熟度標準來定義工作是否被認為是完成的。整個團隊同意而且為這個完成情況負責。一個例子是，團隊需要手工測試他們開發(fā)的功能。測試人員給精心安排所有的測試成員測試活動，包括開發(fā)人員。將測試自動化編織近你的完成度標準中是一種讓所有人對產(chǎn)品質量負責的好方式。非技術測試人員可以幫忙編寫前段測試用例，而開發(fā)人員或者測試“自動化人員”編寫實際的自動化代碼。目標是讓整個團隊感受到所有權。每個人分享開發(fā)，維護和修復測試的責任增加了測試的效率，移除了職員的平靜。它鼓勵合作和共享最好的做事方法。對自動化策略有一個統(tǒng)一的洞察和普遍存在的理解是使用這種團隊為基礎的方式的前提。

銀彈

測試自動化對非技術的管理經(jīng)理們是一個黑盒子。他們對它的理解是有限的，而他們對調查解決方法的時間幾乎是不存在的。市場上有產(chǎn)品生成可以提供最終測試自動化解決方案—銀彈。它的設想是非技術測試人員可以從理解使用該產(chǎn)品開始，然后快速不費力氣地建造一個健壯的自動化套。管理者們可能有一種感覺是因為沒有必要的特殊的培訓，軟件的成本是合理化的。營銷這類產(chǎn)品的網(wǎng)站生成要移除測試自動化的復雜性換之以一種直觀的用戶界面。別弄錯，測試自動化是復雜的。當心提防那些聲稱可以戲劇化簡化創(chuàng)建自動化測試的產(chǎn)品。

隨著專利測試數(shù)目的增加，團隊們變得跟自動化工具更加緊密地連接起來。如果你已經(jīng)創(chuàng)建了成千上百個測試用例卻發(fā)現(xiàn)這個工具不能實現(xiàn)他承諾的功能怎么辦？對對成本有要求的機構，圍繞是撕還是替換的變動的討論會很困難因為已經(jīng)投入的沉沒成本。關心設想的經(jīng)理們不可能去承認失敗，而團隊被留在一遍無所選擇只能繼續(xù)講他們自己推往墻角。這需要有勇氣的領導力來承認在工具選擇流程上的錯誤。從一個技術角度來看，選擇一個第三方測試工具需要完全采用他們的架構。你想要一個增強嗎？提交一個功能請求，然后跟用戶庫的其他人排在一條線上。同時，你在非法訪問計算機測試系統(tǒng)
來讓他們工作。增加的技術債務將會導致廣泛的測試脆弱性。當脆弱測試越來越多時，維護他們的成本變得不可持續(xù)。如果你決定轉用另一個測試工具，沒有一個良好的退出策略。這不會像將你的測試用例從一個工具中到處然后導入到另一個中那么簡單。

數(shù)字游戲

那些對測試自動化直觀價值不熟悉的人嘗試從一些度量中收集獲取這種信息。他們將注意力放在數(shù)個編寫好的測試用例且注意自動化測試發(fā)現(xiàn)的缺陷數(shù)。而那些度量可能很有意思，他們只闡述了故事的一小部分。沒用自動化的測試團隊每次回歸測試用例手工運行時都會支付一輪循環(huán)成本。隨著代碼庫的增大，回歸測試集也會隨之增加。結果，那個循環(huán)成本繼續(xù)增加。一個有意義的度量是“我們使用自動化工具每周節(jié)約了多少人-時？”。隨著團隊可以執(zhí)行更多探索性測試用例，他們可能發(fā)現(xiàn)更多測試缺陷。有多少缺陷是在使用探索性測試發(fā)現(xiàn)而使用手工運行回歸測試用例不可能發(fā)現(xiàn)的？這是個有趣的問題，但是不可能有答案。更困難的是分配一美元可以展示投資回報的價值。自動化帶來價值，但是據(jù)我的經(jīng)驗很難衡量。

一個有著可靠的安全網(wǎng)的團隊很大膽。產(chǎn)品所有者可能不止會冒險還會允許團隊去對重構的代碼做更多冒險的活動。這種重構導致的結果可以增加產(chǎn)品質量，甚至它還能改善該程序的用戶體驗，然后可能增加登錄和轉變。更多的用戶就會帶來更多收入。而用這種假設的情形來決定投資回報率是不可能的。它強調了一個觀點---不是所有有價值的東西都容易去衡量。關注于錯誤的度量的領導者會激勵錯誤的事情。如果一個團隊將關鍵表現(xiàn)指數(shù)作為總測試數(shù)的話，隊員將會更可能會寫更多測試用例。總體測試數(shù)只代表自從引進測試自動化所走的距離；它并不告訴你離目的地有多近。而高測試總數(shù)并不等同于更好的覆蓋率；它只意味著團隊已經(jīng)找到一種方式去游戲/測試系統(tǒng)。有意義的測試自動化度量的一個例子是手工回歸測試集被自動化的百分比。那給團隊成員一個對進度的理解。它也回答了那個還需要多少工夫才能完全自動化手工回歸測試的問題。

不能快速傳送價值

沒有一個合理合適的架構的框架的自動化是毫無價值的。框架這個詞包括所有支持性的幫助你的測試有價值的代碼。開發(fā)一個合適的框架構架需要時間。它是一個與你團隊的需求不斷演變的一個適應性的過程。總是有要加強的代碼，有要更新的組件和要執(zhí)行的重構工作要去做。由于軟件開發(fā)的節(jié)奏的原因，編寫測試自動化的團隊迫切需要盡可能快地傳送價值。如果你的公司有沖刺評審，展示你所取得的進展。不要等到你的測試框架成熟到開始編寫測試用例；你可以使用現(xiàn)有的框架骨架來跑測試用例。

從價值的角度，你能做的最差的事是花費數(shù)軸來開發(fā)一個沒有任何測試進行的框架。一個沒有測試的框架-不管架構多么優(yōu)雅，提供的價值微乎其微。結果，投資商可能
開始懷疑他們的投資。從一開始，你的焦點應當放在自動化手工冒煙測試上。使用如Jenkins這樣的工具，將這些測試用例的運行綁到一塊部署代碼上然后部署到你的測試環(huán)境上。你的下一個目標應當是自動化整個手工回歸測試集，從高價值的組件開始。類似于注冊，轉變，登錄，下單和支付的功能是高價值目標，需要被透徹測試。采用一種自動化策略后，至少在首次沖刺末尾承諾發(fā)送一小部分測試結果。通過展示你的測試結果在團隊附近某處的信息發(fā)射器（如掛在墻上的電視）最大化透明度。然后定期間隔地，反思你的進展然后做過程改正來增加測試程序集的價值。

遺漏價值提議

任何團隊的自動化努力目標都是去創(chuàng)建有價值的測試用例。有價值的測試用例是穩(wěn)定的，快速的，恰當關注的和易于維護的。這些測試類型是由已經(jīng)長期自動化測試的團隊編寫的。隨著時間的推移，隊員們對什么該自動化，什么不該自動化有了理解。有經(jīng)驗的測試團隊視自動化為一把扳手，而不是錘子。由于增加的維護成本和擴展的整體執(zhí)行時間他們很小心地添加測試用例到程序中。當評價新功能是否能自動化，成功的團隊問自己，“這個果汁值得擠榨嗎？”這個測試被自動化更好還是留作手工測試更好？這個自動化太復雜、在我們的一個沖刺里給定的有限的時間里耗費時間編寫嗎？正在開發(fā)的功能做自動化已經(jīng)飽和了嗎？自動化的執(zhí)行依賴與某些我們無法控制的外部變動的代碼塊嗎？

如果對這些問題的任一個回答是是的話，找其他的去自動化吧。成功的團隊會快速刪掉不提供價值的測試。他們甚至更快速遞刪除那些沒有明顯原因就隨機失敗的測試。那些測試需要高維護成本。信息展示臺的觀察者可能視這些停留在失敗狀態(tài)的測試為不成比例的時間量。最終你的機構會成長為不再相信你的自動化測試，然后對其提供的任何價值打折扣。

測試自動化

一個成功的測試自動化，就像軟件開發(fā)，并不簡單。有很多重要的成本涉及到。有很多潛在的錯誤的轉變和錯誤的開始。要知道每個你編寫的有價值的自動化測試用例，
你的團隊變得更加解放。更重要的是，不要忘記授權成員做事。允許他們圍繞一個視野，提供給他們一個明晰的策略讓他們自我組織。給他們自由去探索新的技術，然后決
定他們想要擁抱的自動化工具。成為決定過程的一部分意味著他們會更多投資在他們自己的成功上。你的團隊可能剛剛發(fā)現(xiàn)了一個如果隱藏不被發(fā)現(xiàn)就會導致上百萬損失的缺陷。這種投資回報率怎樣？

原文轉載自：