無程式碼測試：解決了什麼，又把什麼搬到了別處

無程式碼測試真正解決的問題

• 撰寫測試的可及性。 懂產品、但不懂測試框架的人也能建立一個測試。這是真的，而且很重要。

• 對非工程師而言的可讀性。 視覺化流程能讓產品經理看懂，程式碼檔案做不到這件事。

• 更快做出第一個測試。 從零到第一個能運作的檢查，所需時間大幅下降。

它只是搬移、而沒有移除的東西

這些都不是致命問題。但它們正是那個承諾讓人覺得不完整的原因，也解釋了為什麼許多無程式碼測試套件在第一個季度之後就停滯不前。

底層的假設

無程式碼平台假設有一個人的工作就是建立測試流程。這個角色存在時，平台運作得很好；不存在時，平台就會閒置，因為開發者通常不會去用視覺化編輯器，而又沒有其他人能做。

這個假設不成立，是無程式碼測試套件停止成長最常見的單一原因，而它是組織問題，不是技術問題。

交接的問題

這一類工具有一種特有的失效模式值得預先規劃，因為它是突然出現，而不是逐漸發生。

視覺化流程由一個人建立，卻人人都看得懂，這聽起來和 bus factor 問題正好相反。但「看得懂」不等於「維護得了」。一條有三十個步驟、條件分支和共用變數的流程，複雜程度和程式碼沒有兩樣，而建立它的人心裡有一套關於每個步驟為何存在的模型，編輯器並不會把它顯示出來。

這個人離開之後，流程會繼續跑，直到有東西改變，接著就沒有人分得出哪些步驟是承重的關鍵。程式碼至少還帶著註解和提交紀錄。緩解的辦法是要求每條流程都附上一段簡短的文字說明，寫清楚它在保護什麼；作者還在的時候，這件事感覺很多餘，卻是唯一能在他離開後留下來的東西。

新一代做法改變了什麼

用自然語言描述一項檢查，再交由 agent 建立並維護，既保留了可及性，又完全省去了撰寫測試這一步。以意圖表達的步驟，還能在改版之後繼續成立，而改版正是會弄壞錄製流程的地方，也是過去大部分維護成本的去向。

代價是，你要審查不是自己親手建立的涵蓋範圍，而這和動手建立是不同的能力。

這一切都不需要終端機。在 TestSprite 儀表板中建立專案，用自然語言描述要檢查的內容，然後指向你的應用程式。團隊裡的開發者如果偏好指令列，也可以用同樣的方式操作，相關內容都在 CLI 儲存庫。

從儀表板連接儲存庫，測試就會從你原本就會產出的部署開始執行；或者改為在你自己的工作流程中加入一個步驟。

「描述一項檢查」帶來的改變

撰寫測試這一步是消失了，而不是變成視覺化。你用自然語言說出什麼應該成立，TestSprite 會自己想出該怎麼檢查，因此涵蓋範圍不再取決於有沒有人坐在編輯器前面拼流程。

無程式碼只是搬移、並未移除的那部分維護成本也跟著下降，因為步驟是以意圖的形式儲存，而不是錄製下來的路徑。改版把一個按鈕移到別處，並不會讓檢查失效，而這正是上一代最大的一筆重複成本。

它要求你做的，是審查不是自己親手建立的涵蓋範圍。這和動手建立是不同的能力，投入的時間也少得多；在採用任何一種做法之前，這就是值得先弄清楚的取捨。