【課程筆記】不確定時代下的敏捷測試-利用持續測試交付價值
源起
應該是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
如何以探索性作法高效測試
腦中回想到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
筆者正在開始的路上,但也沒有很厲害。先把已經擁有的相關書籍擺出來，激勵自己一下。希望自己能有效地「化輸入為輸出」，持續性寫出相關文章，也徹底檢視自已到底是真的學會？還是只停留在「檢視閱讀」的程度。
敏捷測試真的很難，光擺出相關書籍就這麽費工，也不用再多做解釋了。 與讀者們共勉之 一起加油 😊
