當 Covid-19 開始時, 世界充滿者許多的不確定性, 所有人的工作形態也隨之改變. 這其中也延伸及發展出許多軟體工程師必要的硬實力及軟實力. 包含溝通技巧, 遠端 Debug, 遠端測試等技巧. 面對未知的挑戰及巨大的改變, 如果沒做好規劃, 等於就計畫者失敗.
If you fails to plan, you are planning to fails. — Benjamin Franklin
很喜歡東大特訓班2 裡面櫻木老師邀請同學比賽投籃的橋段, 老師邀請同學投十球, 進最多的獲勝. 比賽開始時, 瀨戶同學穩穩地投進前兩球, 但因為緊張越來越不準, 反之, 櫻木老師雖然前面不準, 但後來越來越穩. 最後櫻木老師以 6:5 勝出.
雖然這邊討論的是完美主義與考試的看法, 但更多想探討的是櫻木老師在一開始就規劃只要投進 60% 就能夠拿下勝利. 因此面對比賽的落後, 心情上面仍然不緊張, 只要穩穩的拿下六球, 就贏得勝利.
站穩腳步, 面對衝擊
回到我們的日常專案上, 身為軟體測試人員的我們是不是常常因為突如其來且意料之外的需求與改動, 在團隊都還沒預備好的狀況下, 打亂了測試的節奏, 導致資源需要重新調整, 並且造成品質的下降? 接下來, 我們來看看有哪些情境?
狀況1: 開發中及已開發的任務臨時變動
有時候我們可能會遇到, 已經做到一半或者是接近完成的任務, 被主管或者是老闆來的指令通通翻盤.
謎之音: 這版的設計怪怪的, 可以再調整一下嗎?
通常遇到這類的情境, 也許是主管或老闆對於自己的產出不太滿意, 他們自己也迷航, 如果需求一直更改, 我們的測試也要一直重來, 肯定是一個耗損. 假如一開始談 SPEC 或者開發測試的階段就頻繁的跟他們討論, 溝通並對齊期待, 做好期待管理. 當團隊彼此磨合後越來越少之後, 這類的情境會越來越下降.
狀況 2: 突然提出緊急的需求, 插件.
這類的情況, 源頭可能來自客服團隊, 業務團隊, 抑或是新創公司團隊的老闆.
謎之音 a: 中午客戶回報, 我們主要的功能他不能使用, 可不可以幫我看一下? 多久可以出 Patch 修復?
對於某些 B2C 的產品, 客服團隊每天都會回報使用者來的大小問題, 也許長遠來看對於團隊是有價值的. 但短期來看需求來的太臨時, 若真的答應修復及驗證, 那麼本來手邊的任務可能會延期. 面對這類的情況, 也許我們可以客服回報問題時, 針對 issue 做分類, 並且排上優先次序. 假使真的是很嚴重的 issue, 就請當天值班的同事進去修復及驗證, 並且將問題列入未來的測試案例中, 降低 issue 暴露在客戶的可能.
謎之音 b: 早上我去跟重要的客戶談 C 功能, 他們說 B 公司早就有這個功能,希望下週一就要看到 DEMO, 可以週五早上給我嗎? 如果客戶滿意, 就會跟我們簽約.
對於新創團隊來說, 也許是重要客戶的堅持, 若沒有完成, 公司就會虧損, 或者是業務團隊要拿下新的單, 需要在短期內完成簽約, 也可能來自於老闆的靈機一動, 或者是投資人的一句話. 在沒有明確的需求下要完成開發及測試. 這類的情境通常棘手, 我們無法用正常開發流程去思考, 也許東西沒有完成, 公司明天就不知道在哪裡了.
以終為始, 面對這類的情境, 先瞭解需求的背景, 也許來自於老闆的焦慮, 也許來自競爭對手的壓力. 讓開發測試團隊跟公司的目標對準, 也許這個改變可以讓公司短期獲利, 或者在長期規劃上先踏足業界先機, 何嘗不改變團隊的節奏保持彈性, 彼此有共識.
這篇 Medium 有更多的實際案例:
解決問題, 創造價值
無論在大型企業, 小至新創團隊, 需求的調整或改變都會用不同的行態呈現. 除了以上提到的軟實力, 身為軟體測試工程師我們還能做些什麼創造價值呢?
生活即測試
開測試案例及測試計畫已經是軟體測試工程師必須的技能, 但如果這項技能已經成為一種肌肉記憶, 那麼面段衝擊時, 測試工程師能夠快速產生測試案例及測試計畫, 對於團隊是一個無形的幫助, 也是定心丸.
I came up with a simple task for my teams: write a test plan in 10 minutes. The idea is simple, if test plans have any value at all then let’s get to that value as quickly as possible — James Whittaker
James Whittaker 在幾年前挑戰他的團隊在 10 mins 內要寫完測試計劃, 也就是這篇著名的 10 mins test plan (ACC).
小弟我時常會針對非軟體的項目, 進行測試計劃的研擬, 通稱 One Page Test Plan, 目標訂在 30 mins 完成培養肌肉記憶. 基本上我們可以很有組織地進行規劃:
- Context and Strategy: 說明測試項目的背景及測試的策略.
- In Scope: 說明測試概括的範圍.
- Out of Scope: 說明測試不包含哪些範圍.
- Risks: 風險的評估, 有哪些因素會影響我們的測試計畫.
- Resource / Timeline: 初步的資源跟時程.
- Environment and Tools: 使用到的環境及工具.
以下是針對蘋果做出的一個測試案例, 細節會在 Test Corner #34 跟大家分享.
One Page Test Plan 也可以是不同的形式呈現如:
- Dashboard
- White Boarding
- Mind Map
- Excel / Word
最重要的是容易閱讀. 這份測試計畫會是你的工具, 面對主管, 業務團隊或者是老闆, 一眼就明白測試團隊的範圍, 短期修正的風險, 需要的資源等. 讓團隊做出當下良好的判斷.
可彈性配置的框架
當衝擊來的時候, 自動化測試框架變得非常重要, 倘若前期的設計不夠彈性, 那麼突如其來的需求降臨時, 我們的測試可能就會趕不上開發, 團隊對於自動化測試的信心就會下降, 變成一種惡性循環. 除了測試框架的調整, 也可以將彈性配置的元素考慮進去, 用最短的時間做出測試案例的修正, 確保測試跟開發可以並行.
同場加映:
測試左移及測試右移
測試左移及測試右移近年來已經是個顯學, 當我們的開發流程中, 已經不在是過去的 Waterfall, 當 developer 從 commit code 到 production 的 lead time縮短, 並且在上線後有足夠的 Observability Test, 回報機制等. 面對突如其來且未知的需求, 團隊也能夠透過這類的方法及工具, 讓出貨的功能保持一定的品質及風險控管, 迎接改變.
同場加映:
結尾
讓測試變成生活的一部分, 適時的調整測試框架, 並且在測試流程中導入測試左移及測試右移. 就像日本的每個家庭都會準備 Survival kits, 當地震或海嘯來的時候, 做好預備. 面對突如其來的且意料之外的需求與改動時, 這些撇步會是測試人員的 Survial Kits, 面對衝擊, 站穩腳步, 並且創造價值.
