Spring boot 自動化測試課程（UI和微服務）旨在解決如何將 Spring boot 框架與自動化測試工具（如Selenium）融合，以執行 UI 自動化並使用不同的工具和技術測試基於微服務的應用程式的一些常見和基本理解。

https://softnshare.com/spring-boot-testing/

NT 390 特價中

Python 是世界上最流行的語言之一，對它的需求持續增加。 Selenium 是測試自動化的行業標準，因此 Python 的可讀性使得這兩者成為編寫有價值的自動化測試的完美匹配。

隨著軟體測試成本的上升以及軟體行業的規模擴大，瀏覽器自動化的需求量很大。不幸的是，對自動化感興趣的工程師幾乎沒有關於如何成功的具體指引，或者甚至不知道正確編寫的自動化程式碼是什麼樣子。

關於這些主題的最廣泛流傳的視訊教學僅涉及技術本身，並未提供可行的實施指南或有價值的行業慣例。這門課將這些有價值的實踐作為本課程的重點。

https://softnshare.com/elegant-browser-automation-with-python-and-selenium/

蠻有趣的詞：「低代碼」。

簡單的說，原本要完成一件事需要 programmer 寫的程式碼量，因為一些解決方案而有機會讓不太懂寫程式的人，透過設定或簡易一點的方式來完成一些代碼的設定，就能看到讓人「驚艷」的成果。

註：這個驚艷通常有一定的比例來自於「不懂寫程式的人」能做出「這樣的成果」

這一篇文章提到的低代碼是行業毒瘤，裡面一些論述點我蠻有共鳴的（有一些則是覺得並非該強調的重點），但這的確是個該留意的議題。

其實用 programmer 去寫程式完成某一項工作的成本是不低的。只是大家在這一行，身為這個角色，會覺得這不難，卻忽略了一樣的時間你可能可以創造更多其他的價值。（價值優先） 這也是類似 design thinking 中為何要用低成本先驗證可行性與價值的概念。

拉回來主軸，我自己過去對「低代碼」這類的擔憂，最常見的就是 Robot framework VS cucumber.

如果 enterprise application 產品夠大、夠複雜、夠重要，那其對應的自動化測試（尤其是 end-to-end）肯定也是同樣產品量級的測試系統。

與其總是想著讓一堆不會寫程式，尤其是「不願意學」寫程式的人，能用哪些方式少寫一些測試程式，最終付出的代價是，前期投入的成本都將毀於一旦。因為當產品越來越複雜時，測試程式也會越來越複雜。

甚至測試程式還會依賴許多 “DevOps” (developer + operation 的工作範圍）都得碰到的相關內容，例如用 docker 起一座 redis，例如怎麼清理與初始化測試資料。

越不想碰程式碼，最後就會一直繞路，或是把一些「限制」視為理所當然。那些事情對 developer 來說，可能就是平時的工作之一，但對不諳程式的測試人員來說就是天方夜譚。

越是這樣把職責角色分開的組織，他們的開發人員往往越是覺得測試是測試人員的工作，他們就是負責把關（甚至覺得他們是專門找碴的），我的工作是負責開發，不是測試。如果我去寫測試程式，那誰要開發？

所以退10步來看全貌，我們很常讓不會、不愛、不想寫程式的測試人員，試著去自動化測試。我們讓會寫程式的人員，覺得測試是測試人員的事，開發人員只要想辦法在時間內做完功能交付（往往品質低落）。

而我們真正希望的目標是產品交付能有比較好的品質，產品交付速度不會因為規模而導致交付時間冪次上升。

讓真正的「測試」人員（不是做那種已知的 check/validation）去做那些未知的、發散思維的探索，甚至讓他們結合 UX/UI 找到更好使用產品的動線與方式，讓他們產出並指導其他人來進行這些已知的 check 動作自動化（最好他們也願意參與、動手自動化的過程），讓開發人員有認知：產品就是我們的小孩，品質跟功能都是我們要 cover 的，開發跟測試是一體兩面的，我們對測試思路與角度的短板，團隊中能有專業的測試人員來互補。

我們能在開始動手開發功能之前，知道這樣的功能是為了給
1.「怎樣的使用者」
2.「解決怎樣的問題」
3.「帶來怎樣的好處」

而這樣的功能提供使用者「哪些使用的情境與方式」。

當我開發完功能之後，我至少能模擬出來各種使用者會碰到的使用場景，功能要如預期般運作。（白話一點，簡單一點，就是問後面把關的測試人員，如果這個功能做出來，你會測試那些東西、怎麼測，再把他講出來的內容，思考哪些動作跟環節可以自動化，這是一個合作的過程，往往因應搭配自動化，會需要微調他們的測試方式）

這中間當然就會應用到 #實例化需求，而這基本的概念才是 #測試左移 的原型。

議題跑得有點遠了，「低代碼」用對地方，就是事半功倍，用錯地方，就是在基礎建設埋了顆地雷，未來爆掉時付出的代價將相當艱鉅。

怎麼評估用對地方、用錯地方？

第一，核心的部分避免用低代碼思維去貪快走捷徑，總有一天要還的。

第二，讓懂得寫程式的人來決定哪些地方適合用低代碼，也讓他為未來衍生的代價負責。

第三，與商業價值的平衡。如果就是埋一顆地雷可以讓公司活下來，評估有著大量的商業價值值得冒險，那就找專業一點的人埋地雷，讓他評估未來抽換掉地雷時，不會導致整個大樓付之一炬。

—
另外一點就是關於招募的。

招了不想寫程式的人，再來想辦法改變他們，讓他們學寫程式，當然事倍功半。

因為他們不想寫程式，所以找一些低代碼的解決方案，可能是種飲鴆止渴。

就像找了一堆需要被管理的人進來，希望他們能自組織、自我管理，當然就擔心東擔心西。

然後再訂了一堆指標來衡量評估他們是否有認真工作，有產出對應得了薪水的價值。

再聘專門管理工作的管理者來管這些需要被管理的人。

如果源頭就是找到能自我管理的人，會不會省了很多「希望能改變他們」的動作呢？

找了一些不懂也不想，甚至也不會持續自我學習的人進來，然後希望弄點內訓、活動、team building, 讀書會，就希望他們具有團隊學習能力，甚至學習型組織，會不會太樂觀了一點？