開立有效測試個案的系統性做法

上課心得

前言

作為一位工程師，我一直以來都注重於程式開發的技巧和知識，還有怎麼樣保持好的軟體品質，因為它能夠確保我們的軟體產品品質和使用者體驗。所以，去年我打算參加 David Ko 的課，可惜因為當時沒有線上課程，直到這次我才好不容易上到課，向測試專家面對面的請益。

作為 RD 角度最大的收穫

這堂課真的很吸引我，而且也是線上課程學不到的東西，完成老師的課之後，我很慶幸自己還沒開始學 ISTQB，而是直接透過一天的課程就入門了軟體測試領域。過去我一直以為軟體的測試就是防止被找出 bug，所以我學了怎麼做 Unit tests，怎麼快速做自動化測試的一些技巧，但是我總是覺得哪裡不夠。

直到這次的課程，老師在課堂上講了一個很重要的概念，那就是測試的分類概念，我聽到老師說了這樣的分類之後，我恍然大悟。原來工程師關注的角度在怎麼完成需求，但是測試人員關注的面向卻完全不一樣。難怪身為工程師的我每次加了自動化測試的程式碼，還是會被找出問題，往往覺得是不是自己的案例還鋪的不夠的迷思，也因為這堂課而有更多的理解。

寫測試案例的最大目的是甚麼

老師一直在課程上強調，我們要思考寫這些測試案例的最大目的是要達成什麼工作，或是避免甚麼情況發生。這段話聽起來很抽象，但實際上一點也不。

我們寫測試的最大目的，就是希望可以考量一般情況、極端情況，還有就是我們想要確認邏輯間的轉換到底有沒有被涵蓋到，舉例來說要計算 nextDate，這是一個輸入今天的日期，會得到明天的一個程式。所以當我輸入 2023/03/21，系統要 print 2023/03/22。

我們除了要注意閏年的邏輯以外，比如 2022/02/28，因為閏年所以不是變成 2022/03/01，而是 2022/02/29。老師在課程中講解了很多不同角度怎麼處理這種測試案例，以及如何去分群分組測試案例。這些上課中提到的測試角度讓我覺得有如神助，可以在工作上好好好思考這樣的案例，是不是可以測試到我想表達的商業邏輯。

上課遊戲化

老師在課堂中，只要有回答問題，就會獲得老師給的一個籌碼。到下課才知道原來是老師發放獎勵的依據。有幸我可以拿到一本看起來很厲害的書，相信老師推薦的書的內容一定也很厲害。

回去公司後我打算做甚麼

在課堂中，老師告訴我們這些學生怎麼分類一個測試案例，以及怎麼樣應付商業的優先順利，其中一個很重要的案例是冒煙測試(Smoke test)。因為目前只有我在寫程式，所以我決定先從完成冒煙測試的案例開始，幫助我遷移公司的舊系統，先用這些測試案例保護好商業邏輯，再接著重構整個程式。