沒有辦法中的辦法

今年如風暴的度過，其實在前面幾天談的部分，規劃與設計整個SDLC，打通金融業所有要走的前置作業，除了沒有去跟主管機關面報外，大概已經把我所有的工作時數投入進去了。

原本有關於測試的部分，在公司內公開的前幾次分享的時候，我其實已經大概有宣告：如果Test plan 真的來不及設計進去，很不好意思，請就先將就在User Story 下面，我多開兩個mutiline text，一格叫做開發人員測試報告，一格叫做使用者測試報告。

到時候status就會變成 New->Active->開發者測試(填寫開發人員測試報告欄位)->開發者主管同意交付測試(Review 開發人員測試報告)->使用者測試(填寫使用者測試報告欄位)->使用者主管同意驗收->Closed。

畢竟在以前，我們的流程中，在測試報告這份文件的繳交，也是寫寫文字貼貼圖，然後把流程指過來指過去。所以我相信，這也是一種SDLC的使用者同意的驗收方式，儘管很粗糙，可能會被大量抱怨，但也不能完全說是錯的。

上圖是我用chatGPT隨意產出一份測試報告的敘述，並且動手抓了幾張圖，資訊量雖然是GPT掰的，但是絕對充足到開發人員沒有興趣看文字，還是只想看看圖到底發生了甚麼事情。

所以這種形式雖說可以驗收，但是到底測試過程發生了甚麼事情，還是停留在鬼打牆的階段。

Test Plan

幸好，在七八月的時候，在爭取之下，我們有位聰明能幹的同事認真的把這個功能好好的研究了一遍，所以這次算是把他的研究成果用文章重新詮釋出來，也把我們一起發現到的一些問題做一個整理與釐清。

這個功能其實非常的貴，相較於Basic Plan，每個人一個月才收6美元來看，這個Basic + Test Plan 的方案竟然高達52美元。也可能是因為他非常貴，所以相較之下用的人也比較少，網路上分享的文章相對來說也少很多，因此這次打算要多花一點篇幅來說這個章節。

首先要先介紹一下Test Plan的各個組成，如下圖：

Test Plan、Test Suit以及Test Case有著上下的關係，分別介紹如下：

• Test Plan：用來將測試套件分組，把他想成最上層的資料夾，包含了應該要做那些套件的計畫。
• Test Suite：翻譯叫做測試套件，主要用來管理Test Case，能確保測試結構性(關聯)和相依性(順序)，並執行多個Test Case，他又分成三個類別：
  • Static test suites：用來儲存Test Case的地方，分類用。
  • Requirement-based suites：基於需求的套件，這是用最多的，因為這個類別在Query的時候，會直接以User Story 作為搜尋的基底，之前有提及，User Story 就是使用者的願望，而這個類別的套件，就是跟需求(願望)有直接的關係。
  • Query-based suites：基於查詢的套件，就是可以依據條件的不同，將需要的Test Case篩選進這個套件組中，例如可以用priority或是credit來進行篩選。
    
• Test Case：定義用來測試程式碼或應用程式以進行部署的步驟。這裡可以注意到Test Case 其實在最中間的位置，算是整個測試的核心元素。他可以直接跟User Story 建立關聯，下面也有以協助Test Case為目的的Shared Steps 以及Shared Parameter。
• Share step：有一些重複的步驟，可以拿來被Test case之間重複利用。舉例來說，假設我們Test Case 的前三步驟一直都是1.連結到網址http://www.xxxooo.com.tw/login 2.輸入帳號 3.輸入密碼，我們可以利用這個share step來群組起來，這樣在多個Test case之間，在需要時，就可以重複利用。
• Share parameter：用來分享參數使用，例如我們在點餐系統中，我們在a測試個案中，有一個下拉選單可以設定parameter選擇中餐、西餐、日本料理，如果其他的測試個案也常常會用到這三個參數，那就可以設定為分享參數來相互使用。

回到上面的圖，其實會發現到，整個Test 組成元件中，Test case居於最重要的位置，user story 是為了完成使用者心中的場景，而test case 就是直接來驗證使用者心中的場景是否有達到驗收標準，而如果沒有完成，user story 就可以直接被開一個他右側的Bug。另外就是，Test Case 與Test Suite之間，會發現其實是虛線的，這個我們內部在研究的時候，有發現其實這表示可以沒有Test Suite，也可以有Test Case的，這個在後面會稍微說明到。

開發難、讓開發人員做測試更難。