我們如何更快、更智能地發布應用程序，並具有“正確”的質量和安全性水平?這是軟件交付和IT團隊每天都要麵對的挑戰——也是公司的重點獎-贏得新的視頻/播客係列，DevOps的．
通過兩周一次的視頻/播客和每月一次的圓桌會議，DevOps Unbound聚集了CI/CD、安全、雲計算、開源、測試等領域的思想領袖，直接討論成功需要什麼。沒有幻燈片。沒有旋轉。隻有優秀的客人，坦誠的對話，以及你可以立即運用的策略。
為了以一場大爆炸拉開序幕，主持人Alan Shimel邀請了兩位測試界最受尊敬、最具激情的“顛覆者”——James Bach和Grigori Melnik博士。盡管他們有很多不同(驕傲的)高中輟學Vs.以前的大學教授喜歡破壞東西還是喜歡建造東西……)這兩者其實有很多共同點。兩家公司都對軟件測試進行了幾十年的深入思考，兩家公司都堅定地致力於推動測試技術的發展，並且都願意為了實現這一目標而改變現狀。此外，兩人都不是特別害羞。
任何總結都不能公正地討論這個問題。完整的會議視頻如下;你也可以閱讀完整的成績單或者把它當做播客．
以下是對話中的一些難忘時刻。
第一本書——也是第一章——關於軟件測試[14:44]
(詹姆斯)好的，首先，你知道關於軟件測試的第一本書是什麼嗎，第一本已知的書?給你的格裏高利做個小測驗
(格裏戈裏·)是邁爾斯軟件測試的藝術。紐約:威利，1979)?
(詹姆斯)在那之前。這是1972年由Bill Hetzel編寫的程序測試方法．那本書是關於一個測試會議的報告，教堂山會議，是在72年舉行的。這似乎是測試領域的一個曆史性分水嶺。在此之前,軟件測試的第一章是我的老師格裏·溫伯格在1961年寫的，他在25歲的時候寫的。這是一個關於測試的精彩章節。
讓我著迷的是溫伯格在1961年對測試的討論與他們在1972年對測試的討論有多大的不同……在1961年的書(計算機編程基礎)中，格裏把測試說成是一種想象，而不是自動化，是一種懷疑和批評的問題，是一種根本不需要算法的過程。在他的章節中，他講述了一個美麗的故事，一個程序員確信自己找到了最後一個bug，然後發現自己錯了。然後他又開了一張支票。然後他確定他找到了最後一個漏洞然後他又發現了其他問題。Gerry的結論是，我們研究的是複雜的係統它總是這樣的。
敏捷，DevOps，自動化，以及工具，工具，工具[19:00]
(詹姆斯)在90年代，人們迫切希望擺脫瀑布式開發和大量文檔的束縛，這創造了敏捷，但同時也創造了軟件測試的上下文驅動學派，這是一個人文主義軟件測試的方法。
DevOps和敏捷在某種程度上繼續掌控著世界，隻是在我看來，敏捷在很多地方已經失去了它的人文主義基礎，它變成了工具、工具、工具。如果我們真的要討論unbinding, DevOps unbound，在我看來，我們必須明確我們要解綁定的是什麼。我希望這意味著人們擺脫了束縛，將DevOps作為一種工具而不是……
(艾倫)但不僅僅是一個工具。對不起，我不是故意要插嘴的。但是你知道嗎，James，我們不想犯敏捷所犯過的錯誤。你剛才說，敏捷的一個問題是我們從人本主義者變成了工具主義者，對吧，太依賴工具了。我們不要在DevOps中犯同樣的錯誤。這也是我一直提倡的——我們不能在DevOps中失去人類。
(詹姆斯)事實上，我想聽你多說一點，艾倫，如果你願意多說一點的話。
(艾倫)我不害羞。我來告訴你我的意見。看，我開始DevOps.com．我在這方麵做了很多工作，已經有七八年了。我不想說敏捷失敗了;敏捷遠非失敗。但是，我們一直依賴於工具，也許是過程。當我們想到ITIL而且ITSM與DevOps相比，我們傾向於將矛頭指向ITIL和ITSM，說它們的過程太多了，太沉重了，整個變更管理的東西太多了。
但也有好的方麵。沒有什麼是十全十美的。世界不是非黑即白的。它是灰色的。對吧?因此，我們從ITIL和ITSM中提取了一些東西，放到了DevOps中。但DevOps——至少對我來說，這隻是我的拙見——從根本上講是關於人、團隊和文化，而不是工具。
我們可以為此爭吵到最後，但從本質上講，DevOps確保開發人員、運維人員、測試人員和安全人員以及這些人在更高程度的溝通和合作下工作，更快地完成工作。我們通過加入諸如自動化之類的東西來做到這一點。但僅為自動化而自動化是不夠的。要實現自動化，是的，有時你必須使用工具來實現自動化。我明白了。但是如果我們失去了DevOps最基本的方麵，在它的核心，關於人類，我認為我們就失去了DevOps的本質。我不認為自己有你們兩個那麼有成就，但我……
(詹姆斯)我還是愛你的，艾倫。我喜歡你剛才說的話。我認為如果你能堅持你剛才所說的原則和感覺，我們可以用工具做任何事情，我們會沒事的。如果我們互相交談，互相關心，我們就會沒事的。我一直看到人們失去這種能力。當然，任何技術和方法，一旦被用於反社會，就會變成濫用。我們這些有能力的人應該盡我們所能不讓它變成虐待，讓我們繼續交談。我認為DevOps可以是一個很棒的東西。
工具+人類:協商boost vs. bind [23:40]
(格裏戈裏·)聽你這麼說真是太鼓舞人心了，艾倫。再說一次，我非常相信人類思維的偉大，但在我看來，我們行業的鍾擺一直在來回擺動。記得整個迷戀CASE工具回到八九十年代?然後，後來，有一個大的運動軟件工廠它的理念是，你可以去抽象一些高層次的東西，然後這些工具，會為你生成所有的代碼和所有的東西，並使其高度可維護，等等。當然，這也失敗了。
但我認為有一種願望是想要找到助推器，某種方式來裝備人類去處理固有的複雜問題，至少現在，需要人類的大腦。從人工智能的第一個時代，也就是六七十年代開始，人們就承諾用計算機編寫計算機代碼，但後來這種設想就消失了。現在又是同樣的事情，讓計算機完全負責測試策略，完全自動測試。我認為這是烏托邦。如果你考慮今天的工具能夠做什麼，我認為人類在未來很長很長一段時間內仍將是這項活動的中心。
所有的工具都很好，因為工具為您提供了額外的功能和額外的方法來自動化最基本的、最無聊的工作元素。這讓你有時間思考新理論、新假設、新模型、新方法……
(詹姆斯)但是你必須考慮不同種類的工具。考慮像程序員的IDE這樣的工具。當我使用程序員的IDE時，我不會感到壓抑。我感到充滿力量。我感覺就像坐在魔毯上，上麵裝著激光炮。我感覺棒極了!但是當我使用大多數測試工具時，我感到壓抑……
(艾倫)就像被閹割了一樣。
(詹姆斯)就像我隻有一些我可以做的事情，如果我有任何超出測試工具設計者認為我可能想要測試的東西，那麼我就不被允許那樣做。這就是我遇到像黃瓜這樣的東西時的感受，它是非常受限的，小黃瓜的語言也是非常受限的。它阻止了我的幻想。不出所料，當程序員為其他程序員創建工具時，這些工具會讓用戶感到強大和自由，並能夠做各種奇妙的事情。我想把同樣的自由感帶到測試中。這就是我們在Tricentis所做的轉型工作的一部分。
未來的測試平台[28:04]
(格裏戈裏·)我們正在Tricentis內部推動一個新的計劃，一個麵向未來的全新測試平台，有點類似於IDE的想法。這是一個集成的測試環境(ITE)，它將人類，人類測試人員放在非常非常中心的位置。所有這些其他的代碼片段、實用程序和服務以及所有的一切都是圍繞人類測試人員構建的，以支持個人，不管他或她的思路、探索思路和測試執行路線可能通向哪裏。
我們設想這是一個超級可配置的、不斷變化的工具——幾乎是變色龍風格的。根據上下文和環境的不同，ITE的不同能力將表現自己，然後人們將實際選擇這是否是他們想要利用的東西，而不是被迫采用一種特定的模式或一種特定的測試方法。我認為以前沒有人嚐試過這種級別的東西，特別是在測試工具領域。這就是為什麼我們對這個項目如此熱情和充滿激情。不是嗎，詹姆斯?
(詹姆斯):是的。我也不認為任何人能夠輕易地複製它，因為他們能夠與我們競爭的唯一方法是雇傭一個喜歡測試的人，這是測試工具公司討厭做的事情，因為測試人員是麻煩製造者。我仍然不能——我很難理解格裏高利雇傭我真的知道他做了什麼，因為我一直是個討厭鬼。
(格裏戈裏·)笑著說
James Bach在Tricentis擔任技術研究員的角色[30:14]
(詹姆斯)我一直在抱怨測試工具的狀態。我希望事情從根本上變得更好，但這意味著我們必須從根本上改變我們對測試人員的看法。這可能會讓我們有點進入測試的角色，但對我來說，測試人員是一個謎題解決者，一個問題發現者。我不是按按鈕的人，也不是驗證者。我不核實事情。工具可以驗證事情。我不是要證明某件事是有效的;我無法證明任何東西都有效。我可以要做的就是收集證據，然後以批判的心態從這些證據中得出推論。
當然，很多工具正在收集關於我正在測試的產品的事實，這些事實可以被自動化，所以我們把這些事實拉進來。我們可以說，“我們得到了這個輸出，我們期望得到這個輸出，所以顯然，就目前我們所知，這裏沒有問題。”但是測試者在此基礎上添加了一種批判性思維:“但我們怎麼知道，我們怎麼能欺騙自己呢?”
我把這種心態帶到了Tricentis，我真的很驚訝——到目前為止他們一直很歡迎我。多年來，我一直試圖幫助其他工具公司在這方麵，基本上，你知道我得到了什麼反應嗎?他們基本上會說，“嗯，我們的客戶隻是想要自動化，隻需要按一堆按鈕。我們並不真正關心測試設計。我們並不真正關心如何授權測試人員。這不會幫我們賺到錢，James，所以我們真的對支持你一直在說的熟練測試人員不感興趣。”Tricentis有一種不同的視角，我認為很難與之相比。
