本文要點
-
我們需要評估測試的價值，評估就是觀察人們的行爲、與人們交談、從根本上測試測試過程的過程。
-
測試用例不是一個測量單位。
-
圖表並沒有告訴我們它本身的意思，我們必須自己弄清楚這個圖表是什麼意思。你不可能從項目之外瞭解到。
-
這是自動化的問題，因爲自動化會以特定的方式查看非常具體的東西。人類能以更廣泛的方式查看更廣泛的東西。人類甚至可以看到我們甚至沒有意識到自己正在尋找的東西。
-
“散焦（Defocusing）”是解決農藥悖論的辦法。散焦意味着不斷地改變你的測試、技術，甚至測試策略。
在此次採訪中，James Bach探討了如何使軟件測試變得清晰易懂，以及如何評估測試工作的價值和軟件產品中的風險。他談到了如何克服測試自動化農藥悖論，以及我們在測試中應該如何利用AI和ML。Bach擁有超過30年的軟件測試經驗，他爲軟件測試初學者提供了三條建議。
Xiaoqian Geng：謝謝您接受我的採訪邀請。您周遊世界，爲軟件公司提供軟件測試服務，並在會議上發表演講。您是否可以與我們分享下，您爲何在1999年辭掉工作，成爲一名獨立顧問？我知道這個領域的很多專家都想從事類似的工作，您對他們有什麼建議？
Bach： 作爲一名軟件測試人員，我想毫不妥協地追求我的技藝。這就是我辭職的原因。我當時非常生氣，因爲我被要求爲我工作的諮詢公司的一個大客戶製作虛假和欺詐性的測試文檔。當我拒絕這麼做時，客戶很不高興，我的老闆也很不高興，因爲我沒有盡力去取悅我們的這個付費客戶。但是，你知道，那些只要你付錢他們就什麼都給的人被稱爲毒品販子。我想成爲一名醫生，而不是毒販。醫生提供尊貴的服務；醫生不會給你開你想要的藥，也不會對你說你想聽的謊話。
所以我決定成立自己的諮詢公司。這可能很難，因爲事實證明，並沒有多少人願意爲你認爲對他們有利的工作付費。在我看來，這就是許多諮詢公司裝模作樣的原因。他們必須追求金錢才能保住生意。這和追求卓越是不一樣的。
另一種解釋是，我真的是一個很難相處的人——從長遠來看，我只能爲一個完全理解我的人工作，那就是我的妻子Lenore。她知道如何保持我維持創造力所需的環境。她永遠不會期望我和一個不太合適的客戶一起工作。所以，當我創辦Satisfice公司時，我幾乎立刻就把它給了她，這樣她就會和我一樣對它感興趣。在過去的18年裏，我們做得很好。她做所有的後臺工作，我做所有的諮詢工作。
Geng：如果有一些專家想找和您一樣的工作，您對他們有什麼建議？
Bach：世界各地都有藝術家、哲學家和科技公司，他們是獨立的，他們願意做出犧牲，爲了能夠追求自己的技藝而不做大的妥協。但這是非常艱難的生活，如果你就是這樣的話，會很難謀生。所以我並不建議人們這樣做。在公司裏，你必須和有錢人相處。而那些擁有金錢和權力的人往往通過犧牲和妥協來讓他們的老闆感覺更好。他們往往期望他們僱傭的人也會爲他們做同樣的事情。
對於測試服務而言，這尤其如此，因爲當有錢人想到測試人員時，他們通常不希望有人制造麻煩。他們需要安靜的測試人員，或者僅僅告訴他們產品已經足夠好了。他們想要好消息。就像這樣：如果他們沒有任何測試，他們就會因爲不負責任而陷入麻煩。如果他們有真誠的、強有力的測試專家，他們就會陷入麻煩，因爲測試人員不斷地發現問題。但是，如果這些高管僱傭了假的測試人員，這些測試人員通過了ISTQB認證，編寫了大量文檔，但實際上並沒有在產品中發現多少問題，那麼，當產品不好時，他們可以責怪這些測試人員，沒有人會責怪僱傭他們的高管。我想這就是爲什麼世界上有那麼多的測試諮詢公司。有很多人願意別人出錢讓他們馬虎做事，使他們看起來很忙，而實際上只要他們安靜、有禮貌。
我的意思是，我的工作很辛苦，因爲我尋找的客戶都希望被告知真相，即使真相很殘酷、很不方便。我的客戶是那些不想被愚弄或奉承的人。最難的是找到這些客戶。
Geng：但是，您很出名，而且有很好的名聲。
Bach：你在谷歌上搜一下我。你會發現我有和人爭論的名聲；他們生氣是因爲我會對我認爲行爲糟糕的人大聲叫喚。有些人叫我惡霸。我不認爲爲正確的事情挺身而出是恃強凌弱，我認爲好人有責任站出來。但話又說回來，也許那些認爲我是惡霸的人都不相信我所代表的是正確的。我想，他們認爲我認爲對優秀工程而言至關重要的事情，只是我自己的主觀臆斷。
如何讓非測試人員清楚地理解測試工作？
Geng：您說，對於測試，不同的人有不同的觀點，有不同的短期和長期期望。在2017年10月PNSQC發佈的視頻中，您提到的一個非常關鍵的、困擾很多測試工程師的點，“如果我們要拯救我們的工作和方法，我們需要讓非測試人員清楚地理解測試工作”，請給我們簡要地介紹下，您認爲測量測試價值的最佳方法是什麼？
Bach：我不喜歡“測量”這個詞。這不是一個有用的詞。任何時候你想說“測量”，我建議你使用“評估”這個詞。評估是一個比測量更廣泛的概念。評估包括測量，也包括人們通常不認爲是測量的其他東西。
我們需要評估測試的價值，評估是觀察人的過程，是與人交談的過程，本質上是測試測試過程。我們需要幫助我們的客戶理解我們的測試以及爲什麼它是有價值的。這就是“易讀性”這個詞的由來。易讀性是指某物被閱讀的能力。手寫是我們所說的易讀或難讀的東西的一個典型的例子。但易讀性的概念不僅僅可以應用於手寫。你可以將其應用於任何流程或系統。如果一個系統，你能看着它，說出它正在做什麼，那麼它就具備易讀性。結婚27年了，妻子的情緒對我來說就具備易讀性。我幾秒鐘就能看出她的感受。
遺憾的是，測試往往不像手寫或人那樣容易閱讀。這就是爲什麼測試人員必須使他們的測試清晰易讀。他們使用白板或電子表格來顯示有用的信息。他們也通過學習講述一個測試故事來做到這一點。當測試人員不知道如何講述一個測試故事時，爲使測試看起來清晰，典型的方法是數一下測試用例的數量，或者指着故事卡說“我測試了那個。”但我認爲，這是一個可怕的想法。測試用例就是文件。數它們說明不了什麼。除非你知道其中包含的內容，否則你就不知道這500個測試用例是符合要求的。也許它只是一個被複制了499次的測試用例。
我沒有使用測試用例，而是將測試分解爲不同的活動，併爲每個活動命名。我可能會提到服務測試、完整性測試、性能測試、功能測試或這些東西的變體。我將給每個測試活動命名。每個活動的名稱都是描述性的。非測試人員可能可以藉此理解我在說什麼。如果我需要解釋特定活動中發生了什麼，我會談覆蓋（我驗證了什麼東西，包括我在測試中用了什麼數據）、判斷（當我看到它們時我如何識別出Bug）和方法（在活動期間我對軟件做了什麼具體的試驗）。我也準備談談這種活動的具體動機——可疑的產品風險。
Geng：您如何知道某個軟件應用程序中的風險是什麼？
Bach：同樣，這是一個評估的過程，而不是測量的過程。我們通過結合不同類型的分析來了解風險是什麼。
我們可以進行黑盒分析：這意味着我們可以研究一下產品的功能以及它在用戶世界中扮演的角色。我們問自己，如果產品表現不好，會對用戶產生怎樣的影響？你知道，Twitter剛出現的時候，它只是一個不實用的小平臺，人們互相發送無用的短信息。如果Twitter宕機，也沒有什麼風險。不會有人太在意。後來，人們開始使用Twitter來及時通知重要事件。Twitter成爲了一個傳播災難新聞的系統。如今，如果Twitter宕機，它真的能傷到人。
我們還可以打開黑盒子，查看系統內部：這意味着我們可以查看系統是如何編碼並鏈接在一起的。我們設想部件失敗，並跟蹤接下來會發生什麼。
我們也可以查看歷史：我們可以找出那個產品或類似產品以前出過什麼問題。以前發生的事情可能會再次發生。
當我說“找出可能的風險”時，我真正的意思是討論它。我們要作爲一個團隊討論系統及其潛在的故障。我們可能是獨自一人，但一般來說，你周圍會有具有不同專業知識和經驗的人。因此，分析風險的過程不是進行數學計算的過程。這不是計算風險的過程，也不是直接在某種“風險測量儀”上測量的過程，我們就像蓋革計數器一樣晃來晃去。事情不是這樣的。相反，這是一個社會化過程，通關學習來明確我們要擔心什麼。
討論告訴我們產品中存在哪些風險。測試告訴我們產品中實際存在的風險。然後，我們發佈產品，看看我們是否正確。也許我們是對的，也許還有另一個風險沒有被測試發現。隨着時間的推移，通過研究任何因爲我們未能發現而進入生產環境的問題，我們能夠更好地理解真正的風險是什麼，對它們做出預測，並針對這些問題進行重點測試。
如何讓自動化測試更有效？
Geng：自動化測試是當今大多數軟件公司的普遍行爲，但是有一個非常著名的爭論，叫做“農藥悖論”，您能談談您的看法嗎，如何讓自動化測試更有效？
Bach：簡單來說，“農藥悖論”是指，如果你有一種方法用來發現一種特殊的Bug，那麼你就會發現這種Bug，而不是其他種類的。如果這種Bug已經沒有了，就什麼也找不到了。與此同時，任何其他種類的Bug都會漏掉。你會認爲自己測試得很好，因爲再也發現不了Bug了，但是你錯了。這是自動化的一個問題，因爲自動化以特定的方式看待非常具體的事情。人類有能力以更廣泛的方式看待更廣泛的事物。人類甚至可以看到我們甚至沒有意識到自己正在尋找的東西。所以，農藥悖論對於自動化測試的影響比對於人類測試人員的影響更大。
但它也會影響人類測試人員，因爲人類測試人員也有偏見。一個非常常見的例子是，人類測試人員往往專注於邊界測試。在我的測試人員教學中，邊界測試是最常用的技術。問題是：並沒有很多Bug是邊界Bug。如果你只使用邊界測試，並且沒有發現問題，你就會認爲產品良好。
因此，給測試人員授課很大一部分是教他們如何散焦。散焦是解決農藥悖論的方法。散焦意味着不斷地改變你的測試、你的技術，甚至你的測試策略。你也可以使用工具來實現這一點。
你知道，我不使用術語“測試自動化”，因爲我不相信測試可以自動化。當人們說測試自動化時，他們的意思通常是使事實檢查自動化。他們在查看特定的東西，查看那些特定的東西是通過還是失敗。這是自動檢查，但肯定不是自動化任何懂測試的人所做的一切測試。當我作爲一個人進行測試時，我不會孤立地看待具體的事情，我同時也在尋找線索。我在尋找奇怪的東西。一旦我發現了一些奇怪的東西，我就會調查它。然後，當然，通過這個調查，我可能會發現一種新的Bug，在開始的時候，我甚至都沒有往這個方向想。機器永遠不會那樣做。只有人類。
如果我使用的是自動化方法，我通常會隨機化測試數據。這樣，我使我的自動化可以自我更新。我也使用數據驅動的自動化，所以我所要做的就是從上面更改數據文件。我不必更改工具可能使用的代碼。我不需要重寫自動化。自動化可以始終運行相同的代碼，但是使用不同的數據庫或不同的環境。
Geng：這是與上下文驅動測試類似的概念嗎？
Bach：不。那完全是另一回事。簡單地說，上下文驅動測試意味着你拋棄了測試的“最佳實踐”，而是在上下文中看待測試問題並簡單地解決它。測試人員是技能型人才，技能型人才會使用不同的實踐，會使用不同的技術，會使用不同的方法和不同的工具，這取決於他們所處的特定情況。你獲得自己的測試技能，做任何需要做的事情，而不是記住一種正確的測試方法。你可以說上下文驅動測試是基於人類技能的測試哲學。換句話說，它是工程學。因爲這就是工程。一個熟練的工程師，一個訓練有素的工程師，會仔細瞭解情況，解決那個情況下需要解決的問題。
這與工廠學校的測試形成了鮮明對比。工廠學校的測試會認爲技能不是很重要。關鍵不在於技能，而在於遵循流程。在工廠學校，他們希望你寫下測試用例，寫下測試腳本，然後他們希望你自動化它。就像工業革命時期的工廠一樣，他們想把人完全剔除掉。在上下文驅動領域，我們認爲這是一個非常糟糕的想法。首先，它甚至無效！這導致了農藥悖論。它會導致測試質量低下，成本高昂，而且缺乏人性化。
上下文驅動者是人文主義者。
Geng：您剛纔提到工廠學校測試。但是，大多數公司仍然使用這種方法，因爲它很容易可視化測試的數量？
Bach：什麼叫很容易可視化測試的數量？
Geng：比如，多少測試用例，覆蓋了多少測試場景。
Bach：但那是謊言！他們說這很容易可視化，但這根本不是可視化測試的數量。他們不知道測試的數量是多少。如果你說你有500個測試用例，你只是有個數字500。你不知道這500個測試用例是什麼。我這麼說吧。如果你說你要走500英里，你可以將其可視化。因爲英里是一個標準的測量單位。但是，如果你說你要旅行500段，沒有人能將其可視化。比如餅乾。你可以拿一塊餅乾，放在手裏。那是一塊餅乾。然後你握緊手，它就碎了。現在，你張開手。你手裏只有幾塊餅乾，卻有一萬個碎屑。同樣的餅乾，以前是一塊，現在變成了1萬個碎屑。只是打包方式不同而已。你改變了餅乾的打包方式，但它還是那塊餅乾。測試也是如此：在某些打包方式中，你可以稱之爲一種情況，但是這種測試的價值可能與這裏的500個測試用例相同。測試用例不是測量單位。
讓我這麼說吧，我已經52歲了，一旦你老了，公司就會由比你年輕的人經營。突然間，公司經營不善的原因就講得通了：這是因爲孩子們在經營公司。他們是小孩子，但他們現在在經營公司。在20歲的時候，我想，也許那些年長的人知道一些我不知道的事情。也許他們有一些祕密，使得其管理行爲變得明智。現在，我已經在這個社區生活了30年。我知道他們沒有什麼祕密。
人們仍然計算測試用例數量的唯一原因，要麼是他們拒絕學習如何管理測試過程，要麼是他們信任那些拒絕學習的人。他們從來沒有長大。的確，在我很小的時候，我也計算過測試用例數量。但後來我長大了。
Geng：測試用例的數量並不能顯示測試的有效性，它是一種測量人們工作有多努力的方法。這並不意味着工作是否有價值，這是另一種角度。這是完全不同的。也許我們可以使用測試發現的Bug數量來評估它們所創造的價值。
Bach：您使用Bug的數量來測量測試的價值嗎？
Geng：很難說，例如系統測試，你發現了一個Bug，但是這個Bug可能非常關鍵、非常複雜、非常有價值。
Bach：完全正確。我用過Bug指標。你可以使用Bug指標來做一些有趣的事情，特別是在項目中報告了大量Bug時。你可以畫圖表。根據圖表，你可以問一些有趣的問題。不過，話雖如此，我認爲重要的是討論測量；看看這些圖表，想想這意味着什麼，我們應該怎麼做？這是這個過程中很重要的一部分。這個圖表並沒有告訴我們它本身是什麼意思：我們必須弄清楚這個圖表是什麼意思。你不可能從項目外知道這些。所以我們用Bug計數作爲提出問題的一種方式，然後我們會去調查，並通過與人交談來得到這些問題的答案。
有時，人們會給你一些圖表，而這些圖表代表着一個虛假的故事。當人們對真相感到尷尬時，他們可以僞造或掩蓋數據。人們可以躲在數字後面。你需要意識到這一點，任何從事管理和使用指標的人都應該知道這一點。管理人員應該做的是降低對數字的重視程度，這樣人們就不會有那麼大的動力去撒謊或隱瞞數字。
對於人爲過程的測量從來都是不客觀的。Bug報告是一個人類社會過程，它不是一個物理系統。它不像測量火山。想象一下，如果火山對地面溫度在情感上存在自我意識，並有意識地在地質學家放置溫度計的地方抑制其岩漿活動。那測量將是錯誤的。但這種想法太愚蠢了。火山不在乎被測量，但人在乎。
新技術對測試方法會產生怎樣的影響？
Geng：您認爲新技術將對測試方法產生什麼樣的影響？例如，AI/ML如何幫助提高測試效率和充分性？
Bach：使用任何工具都要面臨的問題是，你必須瞭解該工具的功能，以便你作爲測試人員可以正確地使用它。如果你不瞭解這個工具的功能，那麼你就不能依賴它。你仍然可以使用它，但不能依賴它。舉個可以使用但不能依賴的例子：一個孩子。我可以讓一個十歲的孩子在我的產品中尋找Bug。我可以讓一整個教室的孩子檢查這個產品，他們可能會發現一些Bug。如果他們這樣做了，你不會放過那些Bug；你不會說，我不能接受這個Bug報告，因爲你還是個孩子。你可以接受這些Bug，但是還不能說產品已經經過了適當的測試。
另一件你不能做的事情是問10歲的孩子，“你是怎麼發現這個Bug的？說明你的方法以及如何才能做得更好。”這個兒童測試人員的例子完全等同於一個人工智能工具。如果你有某種深度學習工具可以會爲你做測試。你說，“好的，超級工具，測試這個產品”。它就會發出嘟嘟聲……並說，“發現了三個Bug。“這就像一個孩子爲你發現了三個Bug。
當我作爲測試人員與你交談時，我可以詢問你的技術。你給我的答案讓我開始信任你。你說，"我在用這個技術，或者那個技術。”我問你能否演示一下你的技術，你說：“好吧，我可以演示一下。”然後，我問你關於你的判斷和你的覆蓋率的問題，你可以回答我的問題。你的回答讓我越來越相信，你正在處理它。
我認爲，對於人工智能，人們想要一種神奇的工具，他們會信任它，就像兒童讀物裏虛構的朋友一樣。我把人工智能稱爲“自動不負責”，它實際上就是那樣。
我沒有看到任何AI工具是透明的。我認爲他們沒有贏得信任。但如果你想要這樣的工具。如果你想相信它，你必須測試它。這個測試過程將非常廣泛。而且，這個工具的範圍會非常狹窄。因爲機器學習是建立在訓練數據的基礎上，而訓練數據是非常具體的。如果某樣東西是專門針對某個東西以某種方式訓練出來的，那麼它可能就不擅長測試稍微不同的東西。我們應該問這個系統是如何訓練的，我們如何知道訓練數據是恰當的、沒有偏見的數據。因爲數據中的任何偏差都會成爲機器中的偏差。我們必須問自己，我們是否要依賴這個？
給希望從事測試工作的人的三條建議
Geng：謝謝您！如果請您給新晉測試人員提三條建議，您會提什麼？
Bach：1.安全測試現在非常熱門。如果你對安全測試人員需要知道的所有細節感興趣，我建議你進入網絡安全測試專業。
2.我想說，如果你想學習編程，那你絕對應該學習編程。如果你不想學習編程，那麼，如果你爲一名優秀的測試經理工作，你仍然可以作爲一名測試人員做得很好。但是，如果你對自動化不熟悉，就很難找到一份測試的工作，因爲有太多的測試經理認爲自動化是很好的測試。就我個人而言，我認爲在測試領域，如果我們讓每個人都成爲程序員，情況會更糟。我是一名程序員。我並不反對程序員。問題是，作爲一名程序員，我傾向於在測試時編寫一個工具。我想寫一個軟件來幫助我測試。這常常使我無法進行測試。我需要那些對代碼不那麼感興趣的人讓我專注於實際的測試過程。
3.這是我的最後一條建議：“找一位導師。”找一個不一定在公司和你一起工作的人，你可以向他諮詢，可以向他吐槽。或者加入一個測試論壇。
Geng：這聽起來很不錯！謝謝您和我分享這個。我們已經完成了今天所有的問題，非常感謝您今天抽出時間，也非常感謝您能給我講測試故事和測試經驗。我相信所有的測試人員都能從中學到東西。謝謝您！
關於受訪者
James Bach一直是一名測試人員、測試經理或測試顧問。他從事測試工作已有31年，著有《軟件測試經驗與教訓》和《學習要像加勒比海盜》。他是快速軟件測試方法的創建者，也是代理或算法的堅定捍衛者。
關於採訪者
Xiaoqian Geng從事軟件測試工作12年多。她在測試大會上做過題爲“軟件測試自動化的六大演進”和“大數據測試的挑戰”的公開演講。她擁有美國專利“基於手勢的應用程序自動化測試”。現在，她是美國舊金山Splunk公司的QA/測試總監。
查看英文原文：