AI晶片價值與複雜度持續攀升，也讓測試與量測從幕後支援走向前台，成為先進製程中左右良率、效能與量產速度的關鍵環節。SEMI國際半導體產業協會今（12）日首度舉辦「AI時代半導體測試與量測產業洞察暨倡議記者會」，由SEMI全球行銷長暨台灣區總裁曹世綸主持，並邀請致茂電子執行長兼總經理暨SEMI檢測與計量委員會主席曾一士、京元電子總經理張高薰，從量測設備與測試服務角度分享產業觀察。記者黃仁杰／台北報導

SEMI國際半導體產業協會今（12）日首度舉辦「AI時代半導體測試與量測產業洞察暨倡議記者會」，針對橫跨IC設計、晶圓製造、測試服務、量檢測設備等半導體全產業鏈的企業進行問卷調查結果顯示，業界對於專項政策、學程接軌測試人才、共用先進測試設備三大方向已形成高度一致的共識，並期盼政府進一步將測試量測納入策略布局，共同把握AI帶來的產業契機。

[caption id="attachment_252702" align="aligncenter" width="1477"] 曹世綸表示，台灣在先進製程與先進封裝已具領先優勢，測試與量測已成為決定良率、成本與量產效率的關鍵環節。（圖／記者黃仁杰攝）[/caption]

全球測試設備2026年估增31% 台灣量測產值同步創高

測試與量測的價值重估，正反映在市場成長曲線上。SEMI預測，全球半導體設備銷售額將由2025年的1,350億美元增至2028年近2,300億美元；其中測試設備成長尤為強勁，2026年銷售額預估大增31%至153億美元，2028年更將進一步攀升至208億美元。台灣市場同樣展現成長動能。經濟部統計處最新數據顯示，去年量測產業產值達新台幣1,936億元、創歷史新高，今 （2026）年前五個月更年增32.8%。這波成長動能主要來自先進邏輯、HBM與高效能運算推升測試強度，帶動記憶體測試、系統級測試（SLT）、老化測試與可靠度篩選的需求持續升溫。

執行力世界級 產業盼從實力領先走向標準參與

完整且高度整合的半導體產業聚落，為測試與量測業者帶來供應鏈協作、量產效率與快速應變的優勢。SEMI問卷顯示，相較美、日、韓、歐，業者高度認同台灣在與晶圓廠、封測廠緊密整合（96.4%）、量產測試效率與成本控制（71.4%），以及快速客製化與交期彈性（67.9%）等面向的競爭力，共同形塑出「快速、整合、可靠」的世界級定位。然而，面對AI帶來的新一波成長機會，產業也正尋求進一步升級。

「AI履歷健檢」看見自己優勢：https://campaign.1111.com.tw/resume-review/

更多科技工作請上科技專區：https://techplus.1111.com.tw/

SEMI全球行銷長暨台灣區總裁曹世綸表示，台灣在先進製程與先進封裝已具領先優勢，測試與量測已成為決定良率、成本與量產效率的關鍵環節。台灣擁有世界級的供應鏈整合與量產實力，下一步更需要產業與政府攜手，讓這項優勢持續深化並被全球看見。SEMI將持續扮演產業連結者，凝聚共識、搭建對話平台，攜手產業布局未來、掌握AI時代的新機會。

測試、量測角色前移 系統級測試與矽光子分居兩大重點布局

SEMI調查顯示，AI已成為測試與量測業務的主要成長動能，逾九成業者預期相關業務將於未來三年持續成長。隨著AI晶片對效能的要求提高，業界對量測精度與測試速度的要求同步大幅提升，測試角色也從後段品管向前段研發延伸，半數受訪者認為測試需更早介入設計與可製造性驗證（DFT/DFM）流程。在技術布局上，業者優先方向一致，先進封裝測試（CoWoS/SoIC）與光電量測（矽光子）分居前兩大重點。

致茂電子執行長兼總經理暨SEMI檢測與計量委員會主席曾一士表示，沒有量測，就沒有驗證；沒有驗證，再好的技術都無法落地量產。台灣若要進一步邁向技術創新中心，更需掌握先進製程背後的關鍵量測與驗證能力。期待凝聚產業界的技術能量，推動測試量測更早介入前段的設計與研發階段，共同打造AI時代所需的可靠基礎。

人才斷鏈浮現 跨域整合成最大缺口

SEMI調查顯示，人才是調查中最一致、也最急迫的訊號。全體受訪業者均面臨不同程度的人才缺口，超過六成將人才議題列為四大產業課題中最優先。最難招募的三類人才，分別為光學量測、跨領域系統整合與先進封裝測試，共同特點是高度跨域，而這正是現行學校培育體系最缺乏的複合型訓練。

京元電子總經理張高薰表示，過去測試被視為半導體供應鏈中的附屬環節，如今已是整個製程不可或缺的一環。尤其在先進封裝與高價值AI晶片普及後，測試不再只是挑出壞晶片，而是篩選出高價值的好晶片。AI晶片單顆價值動輒數萬美元，高階測試能力將直接影響整體良率與供應鏈競爭力。

產業共識化為三大政策訴求 SEMICON Taiwan搭建深化平台

綜整調查結果，業者凝聚為三項具體訴求。在政策支持上，業界呼籲政府設立「測試與量測」專項政策，賦予其獨立的政策定位與專責資源，驅動技術研發與設備升級的實質投入。在人才培育上，業界期待推動大學課程改革、設立測試與量測學程，從教育源頭系統性培養，根本解決人才斷層。在基礎建設上，業界呼籲建立產業共用的先進測試設備平台，降低投資門檻、加速技術應用，整體提升產業競爭力。

在九月將盛大開展的SEMICON Taiwan 2026中，聚焦「精密測試與良率驗證」的測試專區，將涵蓋人工智慧晶片測試、系統級封裝、類比與混合訊號IC測試、記憶體測試等領域，集結量測設備端與測試服務端的產業能量。展會同期舉辦「矽光子國際論壇」、「3DIC全球高峰論壇」與「異質整合國際高峰論壇」，深入探討驅動下一代AI基礎設施的關鍵技術。

這篇文章 測試與量測升格AI競爭力關鍵要角 SEMI偕產業提三大訴求 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

一個新的系統、產品上線之前，需要經過多個版本的效能、功能測試及錯誤修正，擔任這樣角色的「自動化測試開發工程師」（有的又稱自動化測試工程師、軟體自動化測試工程師、自動化工程師），並透過自動化測試工具、撰寫程式語言、腳本來監測並減少潛在錯誤，進而提升服務及產品品質。

記者／孫敬 Archer Sun

一個新的系統、產品上線之前，需要經過多個版本的效能、功能測試及錯誤修正，擔任這樣角色的「自動化測試開發工程師」（有的又稱自動化測試工程師、軟體自動化測試工程師、自動化工程師），並透過自動化測試工具、撰寫程式語言、腳本來監測並減少潛在錯誤，進而提升服務及產品品質。

自動化測試開發工程師對每一個產業、公司來說都是不可或缺的角色，需要不斷摸索，嘗試排除未知問題，如果有意求職、轉職踏入這個職位，有哪些需要具備的專業能力，未來又能藉此轉職、挑戰什麼新的機會？

延伸閱讀：雲端自動化工程師　藉程式碼實現企業運營的革命

目錄

自動化測試開發工程師日常工作

自動化測試開發工程師平常工作內容占用最多時間的部分，便是思考接下來受測的功能或產品，如何去測試（ Ex：人工黑箱測試）、用哪個工具測試，功能面或非功能面（性能及負載）的測試都要兼顧到，像是API、前端的驗證，特別是未曾接觸到的新功能、效能測試也要一併考慮進去。

每個研發工程團隊，大多都會碰到產品監測跟效能評估，從意見回饋跟log去檢查產品運作，即便上線上之後也是要持續追蹤。

硬實力專業能力需求

建議從測試理論開始學習，有了測試理論基礎後，比較能快速了解公司、團隊開發產品與系統架構設計，未來在需求、規格、開發團隊討論，比較不會出現因為對專有名詞認知不同，造成溝通落差的問題。

自動化測試中的效能測試工具，包含最多人使用的開源工具；相對易學的Selenium（Python版）、Jenkins或Appium，程式語言則多使用Python、Java或C#（至少要熟練使用其中一種，建議從Python下手）。

最困難的部分，還是在自動化測試的「腳本」，測試情境要清楚描述，像是操作網站過程的執行步驟。

軟實力專業能力需求

「溝通力」、「創造力」、「思考力」，自動化測試開發工程師每日工作會花大量時間跟不同部門溝通，PM、RD、利害關係人釐清問題；創造力建立在了解特定產品，該如何找出測試的方法、案例跟情境，「該用哪什麼測試案例來測試功能。」；思考力看重的是預防未來產品上線前後，分析與蒐集可能導致Bug的條件，並將這些資訊提交給開發團隊修復。

學習資源方向參考

若是完全沒有經驗，可參考《Pragmatic Software Testing》測試理論說明的一本書，另外圈內的大神也可多關注，Dave Haeffner（Selenium社群開發者之一）的部落格跟影片、Kent C.Dodds、David Khourshid也會特別分享測試的技術。

想看文章類的心法分享，推薦Applitools、TestBash兩個社群網站，擁有多個國家的開發者投稿，測試的管理與技術都能在這邊找到乾貨。

實體交流活動，兩個月會舉辦一次的Test Corner測試社群，直接面對互動也能擦出不少火花。

對英文不好的開發者，台灣有「LINE Taiwan Engineering Blog」蒐集了很多台灣工程團隊的心得，測試相關的心得也能來晃晃。

薪資區間

根據1111人力銀行公開招募的職缺顯示，自動化測試開發工程師每月薪資大約介於30,000至60,000不等，多數常態性薪資皆大於40,000元以上，從傳產、電腦PC、電子五哥等科技大廠，都能看到自動化測試開發工程師相關職缺。

未來職涯發展

自動化測試開發工程師因為工作內容接觸範圍廣，負責產品監測與改良、修正，也對公司未來營運方向有一定程度認識，在未來職涯發展選擇，還能橫跨「測試專家」、「測試架構師」職缺，亦或是轉職成「PM」、「前端工程師」、「UIUX」。

想了解更多的科技業職缺嗎？由科技島與1111人力銀行攜手合作、透視上百種科技工作內容與薪資行情的「職缺百科」正等著您前往探索！

這篇文章 自動化測試開發工程師　聰明工作與聰明賺錢的好機會 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

敏捷測試多年前有了兩本相關書籍 Agile Testing 、More Agile Testing，剛好退伍時購入這兩本簡中版本，那時內心的水還沒倒空，心裡還是個土炮RD Lead 兼 PM的角色， 趁Trendmicro on board前1~2個禮拜隨意地翻閱，大約使用「檢視閱讀」的力氣去了解，當時還沒當過真正的QA,所以沒什麽共鳴之處，就這樣兩本書被晾在書架上4年多的時光，直到近期從Trendmicro畢業後，才又拿起來「分析閱讀」，但看完後總覺得不是那麼踏實，剛好看到David Ko 資深Trender大前輩開這門「敏捷測試」的課程，恰巧當做經過Trend traning 4年後，檢驗自己火候成長到那的關卡。

文／榮民叔叔轉職攻城獅的藏書筆記

應該是11月左右的某的凌晨，哄女兒入睡後，獨自在書桌前進行每日關機儀式，review 當天看到的 James Bach -Testing vs Checking 後感覺意猶未盡，順手上網找Exploratory Testing(ET)相關的資訊，發現到David Ko 所開的3門課程，就直接立馬報名，最後只報名到前2門課，ET可能最近較熱門吧，通知已額滿只好等明年(2022)的梯次~殘念。

不確定時代下的敏捷測試
https://kojenchieh.pixnet.net/blog/post/560778601

開立有效測試個案的系統性做法
https://kojenchieh.pixnet.net/blog/post/560777349

如何以探索性作法高效測試
https://kojenchieh.pixnet.net/blog/post/560357013

腦中回想到2～3年前在Trend University所參加「看版 Kanban內部教育訓練訓」，總結時播放 李小龍 Be Water , My Friend 這麼魔性影片 讓我記憶猶新,課後也自己查了一下相關資料，所留下的這段話讓我銘記在心。

Empty your cup, can fill any. To not for some, with infinite for limited. If knowledge with the traditional mode to walk, you can only live in the traditional shadow, Understanding is the old way, you don’t know yourself.

清空你的杯子，方能再行注滿。 以無法為有法，以無限為有限。 如果知識隨著傳統模式走，你就只能生存在傳統的陰影下， 了解的只是老路子，你並不了解你自己。

敏捷測試多年前有了兩本相關書籍 Agile Testing 、More Agile Testing，剛好退伍時購入這兩本簡中版本，那時內心的水還沒倒空，心裡還是個土炮RD Lead 兼 PM的角色， 趁Trendmicro on board前1~2個禮拜隨意地翻閱，大約使用「檢視閱讀」的力氣去了解，當時還沒當過真正的QA,所以沒什麽共鳴之處，就這樣兩本書被晾在書架上4年多的時光，直到近期從Trendmicro畢業後，才又拿起來「分析閱讀」，但看完後總覺得不是那麼踏實，剛好看到David Ko 資深Trender大前輩開這門「敏捷測試」的課程，恰巧當做經過Trend traning 4年後，檢驗自己火候成長到那的關卡。

一些感想與反思

課程相當精彩，每個分組的workshop練習，都能得到一些反饋，為了不要讓心得筆記變成劇透課程的文章，儘量以最小限度透露課程內容，多一點心得感想。

傳統測試 v.s 敏捷測試

第一個workshop 就是要分組討論一下，傳統測試與敏捷測試有那裡不同呢? 經過討論後，如下一張照片為本組歸納結果。

當然都來上課還是要上台講一下、因為是第一組，讓其它組別笑一下(誤)，剛好也有被錄影下來，其中比較有印象的是說出「最後出事~都是QA的錯」好像在場的員都會心一笑，似乎這刻版印象還留存於眾人心中。

事後回想這段笑聲時，也同時起2~3年前在facebook 上寫了一篇有關入伍訓被剝奪說你、我、他的小故事，其中所衍伸出來的「團隊協同指數」，就可以知道，當下這個團隊發生大災難時，會不會搶著指責彼此都是They的錯。

課後看了幾次講義上條列的敏捷測試宣言、ThoughtWorks 敏捷測試宣言與原則，對照workshop討論出來的結果，自已也規納出什麼是敏捷測試的一段話:

全程測試、全員參與、儘早測試、

持續性的精準自動化測試 Scripted Testing for checking what we know

持續性開放性探索測試 Exploratory Testing for learning what we need to know

當然這只是現階段自己給定的最佳解釋，隨著時間的演進、看了更多知識，再回來推翻也不一定。

講了這麼多，到底團隊如何安排這些測試呢?

大約到了課程的中後段，突然David問了一個題目，學了這麼多敏捷測試相關的東西，你怎麼去安排這些測試？ 小弟突然腦袋一片空白？

再來打出了一個表格 !!

Sprint N-1

Sprint Planning Part 1

Sprint Planning Part 2

Sprint N

Sprint Exec->Sprint Review->Sprint Retro

Sprint N+1

同時也列了一大堆之前討論過各式各樣的測試字眼，開始討論10分鐘，剛好上圖拍到小弟一臉疑惑、不知所措的樣子！？

Agile Testing Quadrants 片刻神遊與事後回響

那時我心裡先想到了一個東西好像叫做「測試矩陣 or 象限」，分成 X軸 (Left Dev <-> Product Right)、Y軸 (Top Business Facing <-> Tech Facing Bottom)……，正要想這4個象限裡面各自有什麼東西，此時提醒聲音「還剩下5分鐘!!」打斷了我緩慢地胡思亂想，看眼前強者我組員們，已經貼了好幾張便利貼上去，才跟上討論的步調，把這想一半的問題放在心裡，回家再找答案。

就在開始寫這篇心得的頭1～2天，在Yoube上看到 Lisa Crispin An Agile Thinking Tool for Building a DevOps Culture 影片，想起了課堂上小插曲。

前半段講者回顧了敏捷測試象限(Agile Testing Quadrants)的歷史及變化過程。起源是出自 Brian Marick 2003年提出 (原始出處)。

後來Lisa Crispin 和 Janet Gregory 在Agile Testing (2009年) 書中提出了敏捷測試象限的概念。

另在 More Agile Testing(2014)書中改版的一次，把左側的 ‘Support The Team ’改成’Guide Development’，外側另人產生錯誤的解讀的四朵雲(Automated&Manual, Automated, Manual, Tools)也拿掉了。

最新版本則是在Agile Testing Condensed (2019)一書中，也在 Q3象限加入了Monitoring and Observability 、Q4象限加入了 Recoverability，嗅到了一點 The Three Ways 中 AMPLIFY FEEDBACK LOOPS 的味道。

此篇文章並不打算深入去探討每個版本之間的變化與演化故事，可以留到後續的主題文章再咬文嚼字。

比較讓我想分享的是，當初要Lisa Crispin 提出 Agile Testing Quadrants 概念，並不是希望每個人把它當作準則、規則去強制執行，而是把 Testing Quadrants 當作是一種 Thinking Tool ，提供team member相互溝通時的common language ，協助各種測試檢驗不同層次的Done。

下次可以試著使用這方式，在各種Planning的場合，問以下3個問題，團隊將會往更全面地方向去思考。

What/How Test for ‘Story Done’ ?

What/How Test for ‘Feature Done’?

What/How Test for ‘Release Done’?

寫到這裡也想起課堂講師說的一句話，Agile Testing 要做的好，就是在比誰的 Devops Pipleline 又快又穩，而Lisa Crispin影片中後半段也提到，如何用 Testing Quadrants 當做 Thinking Tool 與團隊去討論出 pipeline 各個環節可做那些測試，這裡再自行解讀一下求穩、求快的含義:

「求穩」(Test the right things) 想當然爾，每個環節都要有對的測試 (Test everywhere )

「求快」(Test the things right) 則是精準地拿捏每個節點的測試力道，分散測試的風險，那些事早點做可以花較少的effort (Shift Left)；那些事提早做也沒用、因為根本遇不到、模擬不出來 (Shit Right)。

當然如何在前期階段時，把「容易測試」特質帶入產品之中，並且在每次的改變都維持「容易測試」的特質，又是另外一段故事了 (難以測試的程壞味道 Hard-to-Test Code)

Workshop討論的結果與自我反思

再把焦點放回課堂上workshop討論，柯P說：「政治必須落實在人民生活每一天」，偷過來使用~打造又快又穩的Devops Pipleline必須落實在iteration的每一天。

BVT (Smoke testing) Regression testing Stress testing Performance testing Acceptance testing Test automation Unit testing Static testing Integration testing Functional testing Specification by example Load testing Exploratory testing Chaos engineering ………..

如果把測試左移到極致，我也認為Impact Mapping Story Mapping 也算在其中

在上面條列各式各樣的測試活動之中，下圖為本組所討論出來的答案(非正確解答)，自行選定2個項目、簡單地講一下心得(最低限度透露課程原則)，欲知詳情趕快去上課就對了！!

Specification by Example 如何安排呢？

先假定大家跟筆者一樣有概略地認識Specification by Example(SBE)，如果不知道什麼是SBE可以去買書、也可以去上優質的課程。

https://en.wikipedia.org/wiki/Specification_by_example

[書] Specification by Example (英文/中文)
https://gojko.net/books/specification-by-example/

[課程]如何寫出人人有共識的需求 — 範例描述需求篇
https://kojenchieh.pixnet.net/blog/post/558923197-specbyexamplecourse

恰巧2017年參加 Odd-e 呂毅 CSM CSPO 開腦課程時，記得有張圖說明這件事情，恰好就是我想說2時間點，跟以下要講的不謀而合。再次感嘆~知識早在過去時機點出現過，只是個體不經心，浪費許多提早學習的機會。

第一時機點-Product Backlog refinement

在scrum like的開發流程中，有一個名為 Product Backlog refinement 活動，在Scrum Guide-Product Backlog Section， 中英文描述如下:

Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.

產品待辦清單精煉是將產品待辦清單項目拆解並進一步定義，使其變得更小、更精確的活動。這是一項持續進行的活動，加入更多描述、順序與大小之類的細節。這些屬性通常隨工作領域而不同。

一般來說此活動大約會安排在目前Sprint 大約過一半之後的時機，PO 與 Team開始要討論、釐清Next Sprint要做那些項目，這時候就可以排入SBE workshop，先挑出較關鍵的Story先行討論。

第二時機點-Sprint Planning-Part 1 (SP1)

隨著時間點前進，Team 的關注點，會從上一個Sprint 漸漸地往下個Sprint 轉移，直到 Sprint Planning-Part 1 (SP1) 是焦點凝聚的高峰，依照(Scrum Guide-Sprint Planning Section )所定義，SP1 主軸為以下2個Topics:

Topic One: Why is this Sprint valuable?

PO解釋為何有價值. Team依據價值定出目標

Topic Two: What can be Done this Sprint?

Team依據目標選擇出要做那些事，透過PO與Team的討論出有 INVEST特性的Story

INVEST 特性中 ’T’ 代表Testable(可測試的)，使用SBE workshop方式,可讓成員透過充分討論(Conversation)後，達成共識、確認(Confirmation) Story的驗收標準(acceptance criteria , AC)，而支撐或補充AC的眾多examples，自然地就達到了Testable的特性。

課堂上提點 SBE Tips

• 針對Story 去舉例，不是比賽誰舉例的比較多！ 不需要窮舉！
• 列足夠多的 examples 就可以，如:主要情境(key examples)、模糊不清的規則、Error handling
• 主要是要釐清全貌，不要過早跳入細節之中，更不要開始幻想寫Code
• 重要的是達成PO與Team之間的共識(shared understanding)
• 如果按照上述原則列舉 examples，還是太多、太複雜時，代表事情沒有那麼簡單，Story大太了，拆解變成較小的Story。

Test Automation or Automation Testing 如何安排呢？

測試的認知差異

前陣子看 James Bach -Testing vs Checking 影片時，所提到的 The Formality Continuum (自我翻譯成’確定性光譜’)如下圖:

左側為對SUT一無所知；右側則代表百分之百了解SUT，而日常各式各樣的測試活動就落在相對應區間。

每項事情的進入點可能都不同，但隨著測試的過程中，自己會累積一些知識，慢慢地降低不確定性，index 會由左側慢慢地向右側移動，最終才會把確定的事情寫成自動化測試，交由Machine Checking。

反思自已常從 RD 與 PO拿到已經存在的Spec，依賴它讀完後就以為可按表操課、寫成Test Case與Test Steps，再轉化成Automation Script 去執行，那終究只能攔截到已知的錯誤，也失去了 Testing to learn 、Testing to search for problems的機會。

當然也不是每種測試都要這麼費工，如James Bach在演講中用的這張投影片(看到時會心一笑)，端看你所處在的環境去決定，環境上所給的認知偏差會導致某件事情，有人覺得很難(遠洋深海區)；有人覺得簡單(淺灘區)。

筆者試著把近期測試職位工作內容，放入The Formality Continuum進行比較。首先A社與T社職位所要防守範圍的不同，會讓事情進入範圍有了明顯上的異差，另外每件測試走向比例(向左/向右)也造成第二層次差異。

幸運地每次所拿到Prior Knowledge/Spec ，經過測試時可以順順地往光譜右側邁進，最後將可以自動化的測試 Automation；

也有可能拿到的Code/Product實際測試起來，完成不一樣，甚至連背景知識都沒有，無從參照任何的規則，只能往光譜左側移動，藉由測試去學習、找尋問題點。

有幸能找到一些線索、答案再尋著feedback loop努力地向左推進；不幸地一直找不到任何線索，那就可能停留在某一個點，尋求該階段最佳測試策略。

Workshop中的一些討論

經過上一段落簡單地介紹，了解並不是所有測試(一開始)都能自動化，而自動化也不是唯一的最佳解答。但是如果你沒有(嘗試)做自動化，那你的敏捷絕對是死路一條！！因為每次的release，你的Devops Pipleline上一定存在著瓶頸點，讓你想快也快不起來，更別談可以多穩定了。

起因於「自動化測試」該擺在那裡，因為’它’一直被放在Current Sprint 當中沒有被移動，我忍不住問了一下，這件事情可能再同個Sprint完成嗎？ 有人回答可以、有人沒有出聲…..我心裡想怎麼可能、新的feature code 熱騰騰剛出爐，就可以 Make Test Automation then do automation testing這兩個階段的事情，在同個Sprint完成，實在太讓我驚嘆了!!

以過往在T社 RD:QA將近 1:1的情況，最多可在同一個Sprint完成大部份的手動驗證、以及少部份關鍵重要情境的Test Case Automation。

幾乎會在 Sprint N+1時，才會完成 Sprint N feature test automation(API +E2E)，做到這樣都覺得很追的很辛苦、超強！！ -> 這就是最佳解答

後來回家想想，可能是對測試的認知差異吧？每個人所處的環境不同，看待事情的角度、深度當然不一樣，自己何嘗不是也是一樣呢。

總結

參加這門課，我得到了什麼？

得到了一本書，沒錯就是免費的一本課程相關書籍 (敏捷測試 : 以持續測試促進持續交付)。

以筆者過往的經驗，參加ODD-E相關的課程(David Ko,Joey Chen)，只要是拿的是個人發票的學員，都會拿到與課程相關免費的書，作為鼓勵自我學習的獎勵，無形地這樣的推力，也陪伴我許多地出來充電的時光。

回到課程上，用課程最後一張投影片敏捷測試包含‘端到端的過程的測試活動’，其中包含測試左移、iteration中的持續CI/CD、iteration中的持續測試、測試右移，每個階段的箱子把它打開來看，其實都是一天的課程內容，能把這龐大議題的主軸放在一天裡說完，而且安排的各個workshop環環相扣，緊湊但又能點出重點，燃起我更想往下深入的好奇心。

真的很不簡單，敏捷三叔公 David Ko 名不虛傳，還在Trend時就喜歡參加David的內訓課程，離開Trend還有機會再聽到、真是太幸福了~感恩。

課程結束後還可以做什麼呢？分享在許多課程裡，都聽到的一句話：

You don’t have to be great to start,but you have to start to be great.

你不需要很厲害才能開始，但你要開始才能很厲害。

－吉格‧金克拉 Zig Ziglar

筆者正在開始的路上,但也沒有很厲害。先把已經擁有的相關書籍擺出來，激勵自己一下。希望自己能有效地「化輸入為輸出」，持續性寫出相關文章，也徹底檢視自已到底是真的學會？還是只停留在「檢視閱讀」的程度。

敏捷測試真的很難，光擺出相關書籍就這麽費工，也不用再多做解釋了。 與讀者們共勉之 一起加油 ?

這篇文章 【課程筆記】不確定時代下的敏捷測試-利用持續測試交付價值 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。