測試不是寫測試用例。測試人員的目標是以幫助客戶做出有關產品的決定的方式來理解產品狀態。這需要你係統地收集有關產品的證據。像Tricentis這樣的公司提供工具來幫助你做到這一點。我正在幫助他們尋找更好的實現它的方法——更接近測試的本質，為有才華的測試人員提供更好的夥伴。
我成為了一名測試員(在蘋果，1987年)，因為我喜歡抱怨，喜歡發現事物。它比編程更具有社交性，日程安排也更多樣化。至少，這一直是我的故事。但隨著時間的流逝，另一個我認為比其他因素更重要的因素開始受到關注:我覺得需要．
我被聘為測試經理，以前沒有任何作為經理或測試員的經驗。這證明了高中輟學如果他不放棄他的夢想，他可以實現任何事情，而且我們的行業是一個爛攤子，讓任何人都可以去嚐試。在我工作的第一天，我詢問了測試方法和文化。答案是聳聳肩或含糊誇張的口號(“測試人員破壞東西!，“我們代表質量!”)。蘋果的測試人員沒有接受任何培訓。也沒有任何針對公司的指南或手冊。因為沒有人知道如何成為一名測試工匠，我決定自己承擔這項工作。
蘋果公司有一個豐富的企業圖書館，有幾本關於測試的書。他們還提供學術期刊文章投遞服務。我很快就積累了幾百篇與考試有關的論文。但我的閱讀讓我感到沮喪。計算機科學的人把測試當作一個數學難題來寫。舉一個例子來說明一種全麵的方法:
“一旦定義了一組評估標準，就可以調用自動測試用例生成。根據用戶指定的強度(和成本)選擇標準，生成器生成一組測試用例，在指定的成本參數內滿足評估標準。”(DeMillo 1991）
哦?發電機是怎麼工作的?
“這一過程是通過將評估標準建模為代數約束係統，並應用越來越複雜的代數係統求解器，直到滿足標準或超過成本參數。”(DeMillo 1991 b）
嗯嗯。如果你想的話可以去看報紙。我做到了。在我看來，它對實際項目的測試沒有幫助——我也沒有聽說業內有人使用它。
那些真正在這個行業工作並為客戶創造產品的人寫的文章——除了少數例外，他們似乎不讀計算機科學的論文——也沒有多大幫助。他們的寫作方式好像測試是一種觀察教會他們的特定形式和儀式明欽小姐測試員寄宿學校．遵循IEEE 829標準，孩子們!附錄C第5.4.3節(2)規定“生成係統測試設計”。但如何?那麼，請繼續閱讀第5.4.3節。b，上麵寫著“驗證測試設計在目的、格式和內容上符合本標準”。這就是全部!(如,字麵上。該標準中沒有關於該主題的進一步內容。)
為什麼行業從業者沒有說明測試實際上是如何進行的?是可恥的嗎?可怕嗎?或者是神秘的——由皮提亞的，也許——在緊閉的寺廟門後?
這些形式和標準對我們不起作用。我在開發係統組的團隊對我們部門的14個項目進行了研究。在1989年的報告中，我們寫道:“在14個測試套件中，有11個正在為其開發新測試或更新舊測試，沒有使用測試計劃作為指導。”相反，測試人員每天都在與團隊協商，即興進行測試。
當時，我認為蘋果(後來是整個矽穀)是在一個特殊的環境下運作的，教科書上寫的形式和儀式並不適用。在做了幾十年的旅行顧問之後，我了解到，上世紀八九十年代教科書中流行的建議並不適用在任何地方．它基本上是弗雷德裏克•泰勒同人小說。
我是如何發現測試的
在“我是如何發現測試”的故事中有幾個關鍵時刻，但今天我想告訴你的是“啊哈!1995年“。當我創建我的第一個測試類時，它出現了。我做了一些幻燈片，作為測試的初步概括。例如，我有一張關於單元測試、集成測試和係統測試的幻燈片。當時每個測試課都有這樣的幻燈片。
然後到了我要告訴學生們如何測試的部分。如何設計測試?這個過程到底是什麼?
我無話可說!
那時我已經在測試界工作了8年，所以這有點可怕。當我分析我的困難時，我意識到問題的根源:在我職業生涯的大部分時間裏，我一直是一個測試經理，而不是測試員。測試經理要做很多事情，我們要處理測試的概念和形式。然而，我們沒有花很多時間自己尋找bug。
在那一刻，我麵臨著一個選擇。一個誘人的想法從我的腦海中浮現出來:從一些考試教科書上複製關於考試設計的民間傳說。這曾經是(現在也是)一個流行的做法。我很慶幸我沒有走那條路。相反，在我職業生涯的決定性時刻，我進入了測試實驗室，作為一名測試人員，並仔細注意我自己的方法它們從我的自發實踐中浮現出來．我采用了我現在知道的社會科學方法(民族方法學或多或少)。
因此，我測試了又測試又測試。我看著自己測試。我盡可能多地寫下我所做的每一個行動、每一個決定和每一個錯誤。我不停地阻止自己問自己:“我怎麼知道要做這個而不是那個?”我還觀察了其他測試者。
在幾個月的時間裏，我逐漸發現，例如，所有有意的測試似乎都是基於心智模型。所有的測試技術都是根據一些模型來組織的。測試的過程主要是探索產品的過程，形成關於它的理論，並收集證據來證實或駁斥這些理論。測試幾乎就是成為科學家的必經過程。
我能夠回到我的課堂筆記，創造一個原始的方法來教學測試。我還扔掉了關於“集成測試”和“係統測試”的材料。我用一個簡單的格言替換它:如果它存在，就測試它。你有單位嗎?測試它們。子係統?測試它們。您不需要學習集成測試。你需要學習測驗然後你可以根據需要將其應用到一個綜合係統中。
測試在很大程度上是一個隱性知識的問題
現在我可以告訴你為什麼測試如此難以確定:它是一種隱性的知識形式。測試技能並不存在於文字和圖片中，而是存在於我們所體現的人性中。就像走路和說話一樣，我們不能通過明確的指導來學習測試的基礎知識。從某種意義上說，我們是天生的測試者(舒爾茨2015年，舒爾茨2007年)，但我們可以通過訓練和刻意的練習，發展出老練的批判性思考者(周星馳2015年，Lehtinen 2017)．當然，這也適用於測試。
我確實找到了一些幫助我理解測試的書籍，但它們不是“測試書籍”。它們是關於組織學習，係統思考，批判性思維以及科學的本質認為而且實踐．
作為測試人員，您的工作不是“編寫測試用例”。你的工作是弄清楚產品的狀態，以滿足客戶做出有關產品的決策(例如發布決策)的需要。這需要你係統地收集有關產品的證據。像Tricentis這樣的公司提供工具來幫助你做到這一點。
我在特裏森提斯的工作，就是尋找更好的方法。我想讓大家更接近測試的本質;為了使測試人員能夠收集更豐富的證據形式，這些證據可能無法以標準化的方式獲得;為有才華的測試人員創造更好的夥伴工具。
我覺得需要。
＊＊＊＊
James Bach是Tricentis的谘詢軟件測試員和技術研究員。他也是軟件測試谘詢公司Satisfice, Inc.的創始人兼首席執行官。James在技術領域擔任開發人員、測試人員、測試經理和顧問已有38年。他是環境驅動測試學派的創始人，軟件測試協會的創始成員，快速軟件測試方法和基於會話的測試管理的創造者。他還著有兩本書: 軟件測試的經驗教訓而且海盜學者的秘密:自我教育和對激情的追求如何能導致一生的成功．有關他的工作和在線課程的更多信息，請參見https://www.satisfice.com/．