上文書提到面對ET的幾大問題，包括如何進行記錄？一旦記錄下來，跟ST的差別又是什麼？以及即便面對ET的結果，如何判斷feature是否被充分覆寫等。
先來說說結果記錄，這可是一定要有的，但用什麼工具呢？小貼紙，notepad之類原則上其實都是ok的，目的不都是記錄下自己探索過的足迹和腳印嘛。但同時考慮到還需要給日後的自己和其他同僚作reference，那麼簡單的貼紙和txt由于不易于管理和分析，就顯得不合時宜了。在這裡，本文會介紹一種解決記錄測試路徑的工具ET Reporter（目前仍在内部使用，未開源），供大家參考。
ET Reporter本身部署在企業内的私有雲環境，用戶端無需安裝配置，隻要tester擁有企業内管理測試用例系統的賬号即可（例如本例中的HPQC）。登入時選擇對應的project和test set id，建立charter（可以認為是測試點），ET的記錄活動就可以開始了。
本例中作者模拟輸入了一些簡單的note
· Loginwith non-ASCII user
· Non-ASCIIpwd
· Username’sboundary
以及對應的concern
· Loginfail?
· Supportnon-ASCII pwd?
· Bytesor chars?
Timer欄中的時間是自動記錄的，tester隻需要指明目前ET處在setup抑或charter testing即可。一旦在ET過程中發現了bug，可以點選右下角的Reportan ETR Bug或link一個已存在bug id。
一個ET dash結束後，點選确定送出，所有ET的相關腳印即可存儲到test case的管理系統，即本例中的QC。
當我們擁有了些許這樣的ET result之後，ET是否就演變為了ST呢？我個人的答案是肯定的，雖然ET展現出來的形式更多是腦圖，而ST更多的是結構化步驟。随着ET的推進，tester經驗的逐漸完備，之前的new feature轉變為了legacy，積累起來的ET結果也都可以轉變為詳細的test step和對應的expect result， 以及下一步的automation script。而ET tester又将再一次的對軟體中更陌生、更具挑戰的領域開始新的探索。
另外關于ET的一些測試流程，何時開始進行ET？什麼樣的tester又适合來做ET呢？我将在下文中繼續和大家一起探讨。